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

Preface: MongoDB (specifically via its underlying C library, libbson) uses bson_validate to ensure that data blobs are correctly formatted and safe to process before they are committed to the database or parsed by applications.

Background: An invalid UTF-8 sequence is a series of bytes that does not follow the specific structural rules of the UTF-8 encoding standard.

Why Sequences Become Invalid

UTF-8 is a variable-width encoding where characters use 1 to 4 bytes. To be valid, these bytes must follow a strict bit pattern. Common reasons for invalidity include:

•       Illegal Bytes: Certain bytes, like 0xC0, 0xC1, or anything from 0xF5 to 0xFF, can never appear in valid UTF-8 text.

•       Encoding Mismatch: This is the most common real-world cause. It occurs when a file saved in a different format (like ISO-8859-1/Latin-1) is read as if it were UTF-8.

Vulnerability details: The bson_validate function may return early on specific inputs and incorrectly report success. This behavior could result in skipping validation for BSON data, allowing malformed or invalid UTF-8 sequences to bypass validation and be processed incorrectly. The issue may affect applications that rely on these functions to validate untrusted BSON data before further processing.

Impact: This issue affects MongoDB C Driver versions prior to 1.30.5, MongoDB C Driver version 2.0.0 and MongoDB C Driver version 2.0.1.

Official announcement: Please refer to link for details – https://www.tenable.com/cve/CVE-2026-6231