Category Archives: Potential Risk of CVE

CVE-2026-40372: ASP.NET Core Vulnerable to Privilege Elevation (28th Apr 2026)

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

The “ghost data” issue has been fixed in iOS 18.7.8 and iPadOS 18.7.8, as well as iOS 26.4.2 and iPadOS 26.4.2. (24th Apr 2026)

Preface: To be or not to be! Fixing this “bug” makes it easier for criminals to destroy evidence. However, leaving it unpatched leaves billions of innocent users vulnerable to forensic data theft if their phones are ever lost or stolen.

Background: Internally, iOS manages notifications through a system service called bulletinboard. The actual data is typically stored in a SQLite database file named deliverednotifications[.]sqlite, located in a protected system directory (usually /private/var/mobile/Library/BulletinBoard/).

The Freelist Mechanism: When iOS deletes a notification, SQLite does not immediately erase the data from the hard drive; instead, it marks the block as “Freelist.”

Fundamental Problem: The original binary data still exists in these blocks before they are overwritten by new data.

• Forensic Principle: Forensic tools can scan these unallocated spaces and directly extract the message content.

Vulnerability details: A logging issue was addressed with improved data redaction. This issue is fixed in iOS 18.7.8 and iPadOS 18.7.8, iOS 26.4.2 and iPadOS 26.4.2. Notifications marked for deletion could be unexpectedly retained on the device.

Official announcement: Please refer to the link for details –

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

CVE-2026-24176: NVIDIA KAI Scheduler contains a vulnerability (24th Apr 2026)

Preface: When a Pod’s spec[.]schedulerName is set to kai-scheduler, the default scheduler will completely ignore the Pod, and only the KAI Scheduler’s ServiceAccount permissions will intervene to handle the scheduling and resource binding of the task.

Background: The vulnerability stems from how the scheduler tracks and authorizes GPU resources across different namespaces when using the Reservation Pod mechanism .

1.Improper Isolation: In a multi-tenant environment, the scheduler is supposed to enforce strict isolation between namespaces .

2.Cross-Namespace References: The flaw allows an attacker with access to one namespace to craft a pod definition (such as by manipulating annotations or references) that points to or impacts a PodGroup or reservation in a different, unauthorized namespace .

3.Data/Resource Tampering: By setting nvidia[.]com/gpu (an integer resource) while KAI is managing the same physical card via fractional annotations (like gpu-fraction: “0.5”), you could cause the scheduler to miscalculate or “lose track” of the actual hardware state .

Exploitation: An attacker could use these cross-namespace references to “poach” GPUs reserved for other tenants, leading to data tampering (modifying scheduling state) or unauthorized resource access .

Vulnerability details:  NVIDIA KAI Scheduler contains a vulnerability where an attacker could cause improper authorization through cross-namespace pod references. A successful exploit of this vulnerability might lead to data tampering.

Remedy: To mitigate this risk, you should immediately update to NVIDIA KAI Scheduler v0.13.0 or later .

Official announcement: Please refer to link for details –  https://nvidia.custhelp.com/app/answers/detail/a_id/5818

About CVE-2026-24189: NVIDIA CUDA-Q  (23rd Apr 2026)

Preface: NVIDIA CUDA-Q is an open-source, hybrid quantum-classical computing platform designed for simulating and controlling quantum processors (QPUs) using GPU acceleration. It acts as a unified programming model, allowing developers to write code in C++ or Python that seamlessly integrates CPUs, GPUs, and various QPU hardware.

Background: The Relationship: Client API vs. Kernel

1. CUDA-Q Client API (The “Host”)

•       Where it runs: On the CPU (Host).

•       What it does: It manages the overall application logic, classical data processing, and the orchestration of quantum tasks. It “calls” the quantum kernels and handles the results.

•       Language: Typically Python or standard C++.

2. CUDA-Q Kernel (The “Device”)

•       Where it runs: On the QPU (Quantum Processing Unit) or a GPU/CPU Simulator.

•       What it does: This is the code marked with __qpu__ (in C++) or @cudaq.kernel (in Python). It contains the actual quantum circuit instructions (Hadamard gates, CNOTs, measurements).

•       Execution: It is compiled into a specific intermediate representation (like QIR) that the backend target understands.

Vulnerability details: NVIDIA CUDA-Q contains a vulnerability in an endpoint where an unauthenticated attacker may cause an out-of-bounds read by sending a maliciously crafted request. A successful exploit of this vulnerability may lead to denial of service and information disclosure.

Official announcement: Please refer to link for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5820

Ref: To securely manage API keys and mitigate the risk of development environment theft in CUDA-Q projects, consider the following industry-standard practices. This prevents keys from being leaked in the code and provides a buffer in case the laptop environment is compromised.

1. Use Environment Variables This is the most basic and important rule: Never write API keys directly in the code.

• Local development: Edit your [.]bashrc or [.]zshrc file on your system (such as Linux or macOS):

bash export NVQC_API_KEY=”your_secret_key_here”

AMD-SB-7050:  Floating Point Value Injection (FPVI) Variant in AMD CPUs. AMD believes that existing mitigation guidance for FPVI remains valid (22nd Apr 2026)

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

CVE-2026-39813: FortiSandbox 5.2 and 4.2 not affected by JRPC API design weakness. Please staying alert! (21st Apr 2026)

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

CVE-2026-6383: A flaw was found in KubeVirt’s Role-Based Access Control (RBAC) evaluation logic (20-04-2026)

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

Presumably this vulnerability (CVE-2023-20593) will only affect processors based on the Zen 2 architecture (April 17, 2026)

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

About CVE-2026-6231: MongoDB, the bson_validate function may return early on specific inputs and incorrectly report success. (16th Apr 2026)

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

CVE-2025-47389: About Qualcomm – Buffer Copy Without Checking Size of Input in Automotive Platform (15th Apr 2026)

Preface: Qualcomm provides the Snapdragon Auto 5G Modem-RF (such as the Gen 2 platform) specifically for the automotive industry. For the automotive and EV sector, Qualcomm offers a dedicated platform called the Snapdragon Auto 5G Modem-RF Gen 2. Qualcomm developed the Snapdragon Auto 5G Modem-RF platform (specifically the Gen 2 version) to address the rigorous demands of safety, precise positioning, and integrated computing in the era of Software-Defined Vehicles (SDV).

Background: Snapdragon Auto 5G Modem-RF (Gen 2) supports mission-critical vehicle features such as:

  • C-V2X (Cellular Vehicle-to-Everything): Direct communication between vehicles and roadside infrastructure for safety.
  • Advanced Positioning: High-accuracy GNSS for autonomous driving and HD mapping.
  • Satellite Communications: Support for two-way messaging in remote areas.
  • Telematics Framework (TelAF): A specialized development environment for automakers to build connected services.

Ref: A Software-Defined Vehicle (SDV) is an automobile where core features—such as performance, safety, and infotainment—are primarily managed, upgraded, and enhanced through software rather than fixed hardware. By decoupling hardware from software, SDVs enable over-the-air (OTA) updates to add new features or improve functionality throughout the vehicle’s lifespan, functioning more like a smartphone on wheels than a traditional machine.

Vulnerability details: Memory corruption when buffer copy operation fails due to integer overflow during attestation report generation.

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