Preface: Due to the need for high-security, compliance (HIPAA, GDPR), and transaction reliability, many banks and financial firms use ASP[.]NET. The primary difference is that ASP[.]NET (often called “ASP[.]NET Framework”) is the original, Windows-only version, while ASP[.]NET Core is a modern, cross-platform includes Windows, macOS, and Linux.

Background: The Microsoft 365 ecosystem relies heavily on ASP[.]NET Core for its modern, high-traffic web components:

Microsoft Teams: The backend for Teams is built on ASP[.]NET Core to handle the massive, real-time demands of millions of concurrent users.

Office Web Apps: Core parts of the web-based versions of Word, Excel, and Outlook utilize the[.]NET architecture for cross-platform stability.

 Bing & SharePoint: These services are frequently cited as being “proven at hyperscale” using the ASP[.]NET Core framework.

ASP[.]NET Core’s Kestrel server can handle over 7 million requests per second.

Ref: When you use an official Microsoft [.]NET Docker image, Kestrel is already there. When your container starts, it runs dotnet Myapp[.]dll, which immediately fires up Kestrel to listen for requests.

# Kestrel (Inside Container) → Receives the “cleaned” request from the proxy and runs your ASP[.]NET Core logic.

In Kubernetes, your “Pod” runs that Docker container. Kestrel handles the traffic inside that Pod. 

Vulnerability details: Improper verification of cryptographic signature in ASP[.]NET Core allows an unauthorized attacker to elevate privileges over a network.

Official announcement: Please refer to the link for details – https://nvd.nist.gov/vuln/detail/CVE-2026-40372

Preface: In modern processor design, the Floating Point Unit (FPU) is no longer a separate co-processor that needs to be installed; it is now an integrated, standard component built directly into every CPU core.

Background: Unlike early processors that used slow software to mimic math, modern chips like the AMD EPYC use dedicated physical logic to handle numbers instantly. 

When you ask a CPU to add two floating-point numbers, it follows a high-speed “assembly line” process:

1.      Alignment: The CPU compares the exponents of the two numbers. It shifts the mantissa of the smaller number until their decimal points align.

2.      Calculation: Dedicated hardware—like a Floating-point Adder or Multiplier—performs the binary math on the mantissas.

3.      Normalization: The result is shifted so that it starts with a single non-zero digit (e.g., changing 0.011 x (2 to power 5) to 1.1 x (2 to power 3)).

4.      Rounding: Since binary cannot represent every decimal perfectly, the FPU applies rounding rules to fit the result into the standard bit size (32-bit or 64-bit).

Technical details: Researchers shared with AMD a report titled “TREVEX: A Black-Box Detection Framework For Data-Flow Transient Execution Vulnerabilities.”

The researchers’ paper introduced a Floating-Point Value Injection (FPVI) variant, which could allow an attacker with a deep understanding of microarchitectural behavior to inject values into vector registers during transient execution. Although they noted similarities with FPVI, they initially reported the finding as a new issue due to its capability to be triggered without denormal values as inputs.

Official announcement: AMD believes that their FPVI variant falls within the existing scope of CVE-2021-26314 (FPVI) as existing descriptions of FPVI do not specifically require denormal inputs. Additionally, AMD believes that existing mitigation guidance for FPVI remains valid.

Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7050.html

Preface: FortiSandbox sends analyzed threat logs (including malicious file behavior, risk ratings, etc.) to FortiSIEM.

FortiSIEM obtains threat intelligence from FortiSandbox via API, correlates and analyzes it with logs from other devices to enrich alert content and improve detection accuracy.

Background: In the Fortinet ecosystem, the filedir parameter is specifically used in the FortiSIEM Integration API, rather than the standard FortiManager JRPC configuration API. It is used during Lookup Table operations to specify the directory path for CSV file imports.

Key Difference: FortiManager vs. FortiSIEM

• FortiManager/FortiOS: Uses the url and data structure for almost all JRPC tasks. File operations (like backups) are usually handled by exec commands that return the file content directly in the JSON response, without requiring a local filedir on the appliance.
• FortiSIEM: Uses explicit path parameters like fileDir and fileName for bulk data ingestion and system-level integrations.

Vulnerability details: A Path Traversal vulnerability [CWE-24] in FortiSandbox JRPC API may allow an unauthenticated attacker to bypass authentication via specially crafted HTTP requests.

Official announcement: Please refer to the links for details:

https://nvd.nist.gov/vuln/detail/CVE-2026-39813

https://fortiguard.fortinet.com/psirt/FG-IR-26-112

Preface: Does the cloud service provider use KubeVirt to support the operation of customer-supplied VMware images?

Yes, service providers do use KubeVirt to allow customers to provide and run VMware images within a Kubernetes environment. This is a common strategy for “lifting and shifting” legacy workloads to the cloud without undergoing immediate containerization.

Background: In the KubeVirt ecosystem, service providers use the Containerized Data Importer (CDI) to handle the import and conversion of .vmdk files. Regarding on permission isolation and conversion, KubeVirt ensures security through RBAC (Role-Based Access Control) and the DataVolume resource.

1. Isolation and Permission Protection Mechanism

•       RBAC Isolation: The import process is executed by a specific ServiceAccount (e.g., cdi-sa). This account’s permissions are strictly separated from the permissions used to actually run the VM, ensuring the import environment is sandboxed.

•       Permission Preservation: When CDI imports a .vmdk, it converts it to a raw or qcow2 format within a PersistentVolume (PV). KubeVirt applies specific ownership (usually UID 107) to the resulting image file. This ensures that while the VM can read the disk, other users in the cluster cannot access the underlying data, maintaining strict isolation.

•       Role Distinction: The role performing the conversion is different from the owner of the original .vmdk. This “privileged importer” role handles the conversion logic and then hands off the finalized, isolated volume to the user’s VM.

Vulnerability details: A flaw was found in KubeVirt’s Role-Based Access Control (RBAC) evaluation logic. The authorization mechanism improperly truncates subresource names, leading to incorrect permission evaluations. This allows authenticated users with specific custom roles to gain unauthorized access to subresources, potentially disclosing sensitive information or performing actions they are not permitted to do. Additionally, legitimate users may be denied access to resources.

Official announcement: Please refer to link for details – https://nvd.nist.gov/vuln/detail/CVE-2026-6383

Preface: Zen 2 is still utilized in industrial-grade embedded computers and edge applications where stability and power efficiency are required, often as a reliable legacy option.

Background: Because AMD-SB-7060 actually “does not” affect Zen 4 and Zen 5. Here’s a detailed explanation:

Scope of Affected AMD-SB-7060 (Zenbleed)

AMD’s official announcement (AMD-SB-7060) clearly states that this vulnerability (CVE-2023-20593) only affects Zen 2 architecture processors. This includes:

• Ryzen 3000 series desktop processors.

• Ryzen 4000 series mobile processors.

• EPYC “Rome” server processors.

Zenbleed (CVE-2023-20593) is a critical hardware vulnerability discovered in AMD’s Zen 2 processor architecture that allows unauthorized access to sensitive data. By exploiting a flaw in how the CPU handles speculative execution and register recovery, an attacker can potentially leak information—such as encryption keys or passwords—from other processes running on the same CPU.

Vulnerability details: Researchers reported a microarchitectural side channel via the AMD bug bounty program.

The researchers describe a microarchitectural timing side‑channel in AMD Ryzen™ processors resulting from contention in mishandling resources. By triggering secret‑dependent memory accesses during speculative execution and measuring timing differences after speculation is squashed, an attacker operating within the same process may be able to infer sensitive data.

Official announcement: Please refer to the link for details – https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7060.html