Category Archives: Potential Risk of CVE

AMD Fixed CVE-2024-21969 (23rd June 2025)

CVE-2024-21969: Whispering Pixels: Exploiting Uninitialized Register Accesses in Modern GPUs.

Preface: How to Enable Secure GPU Mode (Register Clearing)

  • This mode is supported on the following AMD GPUs:
  • Radeon RX 5000, 6000, 7000, 9000 series
  • Radeon PRO W5000, W6000, W7000 series
  • Radeon AI PRO 9000 series
  • Radeon VII, RX Vega
  • Instinct MI210, MI250, MI300X, etc.

Background: The proliferation of graphics processing units (GPUs) has brought unprecedented computing power.

Multiple register-based vulnerabilities found across different GPU implementations.

So-called whisper pixels. The vulnerability poses unique challenges to an adversary due to opaque scheduling and register remapping algorithms present in the GPU firmware, complicating the reconstruction of leaked data.

GPU Programming: An application has to use vendor- provided libraries in order to translate a shader from its high-level source code to an architecture-dependent binary code. Vendors provide these libraries for a variety of high-level languages.

Vulnerability details: Improper clearing of GPU registers could allow a malicious shader to read left-over pixel data leading to loss of confidentiality.

Mitigation (13th Aug 2024): AMD plans to create a new operating mode designed to prevent processes from running in parallel on the GPU, and to clear registers between processes on supported products.

Last Updated Date (23-06-2025): AMD has created a new operating mode designed to prevent processes from running in parallel on the GPU, and to clear registers between processes on supported products.  This mode is not enabled by default and needs to be set by an administrator. AMD expects performance impacts if the new mode is enabled in environments where multiple processes would have been running simultaneously on the GPU.  The performance impact will be related to the number of processes that would have been running in parallel.  Additionally, a lesser performance impact may arise due to the additional clearing of registers between processes.

Instructions for enabling the new mode can be found in the relevant release notes and/or product documentation.

AMD started rolling out mitigation options beginning in May 2024 through applicable driver updates.

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

About Veeam Backup (CVE-2025-23120 and CVE-2025-23121) – 23-06-2025

CVE-2025-23121

NVD Published Date: 06/18/2025

NVD Last Modified: 06/18/2025

Preface: Veeam introduced a custom serialization formatter to protect against unsafe deserialization vulnerabilities (see below):

-They override the default .NET deserialization behavior.

-They validate or restrict which types can be deserialized.

-This is a security hardening measure to prevent attackers from exploiting deserialization to execute arbitrary code.

Background: A BinaryFormatter is a class in .NET used for serializing and deserializing objects into a binary format. Serialization converts an object’s state into a byte stream, allowing it to be stored (e.g., in a file) or transmitted. Deserialization is the reverse process, reconstructing the object from the byte stream. The BinaryFormatter provides a compact binary representation, making it relatively fast for serialization and deserialization.

Veeam introduced a custom formatter that prevents insecure deserialization through a whitelist-like mechanism.

The Veeam.Backup.Model.CDbCryptoKeyInfo class is marked as [Serializable] and is explicitly allowed for deserialization within Veeam’s implementation. According to a detailed vulnerability analysis, this class:

  • Is part of the whitelist of types that Veeam permits for deserialization.
  • Has a “magic constructor” (a constructor that can be invoked during deserialization) that can be reached via .NET Remoting or other deserialization mechanisms.
  • Was involved in a Remote Code Execution (RCE) vulnerability (CVE-2025-23120), where the deserialization of this class could be exploited due to insufficient validation and reliance on a blacklist rather than a strict whitelist.

This vulnerability highlights the risks of allowing deserialization of complex or sensitive types, especially when relying on blacklist-based filtering, which can be bypassed.

Vulnerability details: A vulnerability allowing remote code execution (RCE) on the Backup Server by an authenticated domain user.

Official announcement: For details, please see the reference link – https://nvd.nist.gov/vuln/detail/CVE-2025-23121

CVE-2025-52556: Insufficient verification of timestamp response signatures. Users should immediately upgrade to rfc3161-client 1.0.3 or later. (23-06-2025)

Preface: rfc3161-client version 1.0.3 is not designed to be installed on the server side. It’s a Python library, specifically a client-side tool, for interacting with RFC 3161 Time-Stamp Protocol (TSP) servers. It’s used to create timestamp requests and process timestamp responses, which is a client-side function of interacting with a time-stamping authority.

Background: The primary design objective of the Python Time-Stamp Protocol (TSP) library is to enable trusted timestamping of digital data. This means providing a secure and verifiable way to associate a specific point in time with electronic documents or signatures. The library allows users to request a timestamp token from a Time-Stamp Authority (TSA), which then attests to the existence of the data at that time.

The Time-Stamp Protocol (TSP), defined in RFC 3161, is a cryptographic protocol used for trusted timestamping of electronic data. It involves a Time-Stamp Authority (TSA) that provides a digitally signed timestamp, proving that a specific piece of data existed before a certain point in time. This is achieved by hashing the data, sending the hash to the TSA, and receiving a timestamp token containing the hash, a unique serial number, a timestamp, and the TSA’s digital signature.

Ref: TSR (Trust Store Repository) embedded certificates up to the trusted root(s) form the foundation of a chain of trust, allowing devices and systems to verify the authenticity and trustworthiness of other certificates. These embedded certificates, often root certificates, act as the ultimate authority, establishing a baseline for trust within the system.

Vulnerability details: rfc3161-client is a Python library implementing the Time-Stamp Protocol (TSP) described in RFC 3161. Prior to version 1.0.3, there is a flaw in the timestamp response signature verification logic. In particular, chain verification is performed against the TSR’s embedded certificates up to the trusted root(s), but fails to verify the TSR’s own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce any TSR signature so long as the embedded leaf chains up to some root TSA.

Official announcement: For details, please see the reference website – https://nvd.nist.gov/vuln/detail/CVE-2025-52556

CVE-2025-44952: About Open5GS (19-6-2025)

Preface: Open5GS is a popular open-source 5G core network (5GC) implementation, particularly among researchers and those building private 5G networks. It’s recognized as one of the leading open-source 5GC projects. Open5GS is known for its adherence to 3GPP standards and its mature development, making it suitable for various applications like testbeds, research, and even some deployments

Background: The PFCP library refers to a software component, often implemented in programming languages like Go, designed to support the Packet Forwarding Control Protocol (PFCP). PFCP is a signaling protocol used in mobile core networks, particularly in the context of Control and User Plane Separation (CUPS) within 4G and 5G architectures. It enables communication between control plane elements (like the Session Management Function or SMF) and user plane elements (like the User Plane Function or UPF). PFCP is used by network equipment (like 5G base stations and core network elements) to manage data forwarding.

Vulnerability details: A missing length check in `ogs_pfcp_subnet_add` function from PFCP library, used by both smf and upf in open5gs 2.7.2 and earlier, allows a local attacker to cause a Buffer Overflow by changing the `session.dnn` field with a value with length greater than 101.

Comment: The developer added the strcpy block as a new logic to handle the DNN field. If the patch doesn’t include bounds checking, it introduces a new vulnerability.

Suggestion: the strcpy should be replaced with a safe alternative.

Official announcement: Please refer to the supplier announcement –

https://nvd.nist.gov/vuln/detail/CVE-2025-44952

CVE-2025-23252 – NVIDIA has released a software update for NVIDIA® NVDebug tool to address the security issue.(18-06-2025)

Preface: The NVdebug tool, used for NVIDIA GPU debugging, relies on the NVIDIA Data Center GPU Manager (DCGM) library. Specifically, it utilizes DCGM version 2.2.x or later. DCGM is a suite of tools for managing and monitoring NVIDIA GPUs in data center and cluster environments.

Background: The NV Debug Tool is part of the NVIDIA Nsight Systems and Nsight Graphics development tools. These tools are designed for debugging and profiling GPU-accelerated applications, including those using CUDA and other graphics APIs. It’s useful for debugging both CPU and GPU code, especially for CUDA applications.

Nsight Systems can collect logs for both Nsight Compute and Nsight Graphics. Nsight Systems is a system-wide performance analysis tool, while Nsight Compute focuses on kernel-level profiling and Nsight Graphics specializes in graphics application debugging and profiling. Nsight Systems can gather data that is relevant to both, and the collected data can be analyzed within the respective tools.

Vulnerability details: The NVIDIA NVDebug tool contains a vulnerability that may allow an actor to gain access to restricted components. A successful exploit of this vulnerability may lead to information disclosure.

Ref: CVE-2021-34398: NVIDIA DCGM, all versions prior to 2.2.9, contains a vulnerability in the DIAG module where any user can inject shared libraries into the DCGM server, which is usually running as root, which may lead to privilege escalation, total loss of confidentiality and integrity, and complete denial of service. (Public on May 29, 2025)

Point of view: In attached diagram description, if your system uses NVDebug, it’s very likely that it also includes or interacts with a version of the DCGM library, and therefore could be affected by vulnerabilities in DCGM versions prior to 2.2.9.

Official announcement: Please refer to the supplier announcement –

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

CVE-2025-6087: About @opennextjs/cloudflare package (16-6-2025)

Preface: Next.js is a powerful React framework that simplifies web development by providing features like server-side rendering (SSR), static site generation (SSG), and API routes, all while offering built-in optimizations and a great developer experience. It’s essentially a framework built on top of React, adding extra functionality to create high-performance, SEO-friendly web applications.

Background: The @opennextjs/cloudflare package is a Cloudflare-specific adapter that allows you to deploy Next.js applications to Cloudflare’s developer platform. It essentially transforms a Next.js application, built using next build in standalone mode, to run within the Cloudflare’s workerd runtime using the Workers Node.js compatibility layer. This enables features like server-side rendering (SSR) and serving static assets directly from Cloudflare’s edge network.

Vulnerability details: A Server-Side Request Forgery (SSRF) vulnerability was identified in the @opennextjs/cloudflare package. The vulnerability stems from an unimplemented feature in the Cloudflare adapter for Open Next, which allowed unauthenticated users to proxy arbitrary remote content via the /_next/image endpoint. This issue allowed attackers to load remote resources from arbitrary hosts under the victim site’s domain for any site deployed using the Cloudflare adapter for Open Next.

Impact:

* SSRF via unrestricted remote URL loading

* Arbitrary remote content loading

* Potential internal service exposure or phishing risks through domain abuse

Mitigation: The following mitigations have been put in place:

* Server side updates to Cloudflare’s platform to restrict the content loaded via the /_next/image endpoint to images.

The update automatically mitigates the issue for all existing and any future sites deployed to Cloudflare using the affected version of the Cloudflare adapter for Open Next

* Root cause fix https://github.com/opennextjs/opennextjs-cloudflare/pull/727  to the Cloudflare adapter for Open Next.

Official announcement: Please see the link for details – https://nvd.nist.gov/vuln/detail/CVE-2025-6087

CVE-2024-55567: A vulnerability in the UsbCoreDxe driver of the InsydeH2O UEFI firmware, specifically due to improper input validation. (16-6-2025)

NVD Published Date: 06/12/2025

NVD Last Modified: 06/12/2025

Preface: InsydeH2O is a UEFI firmware developed by Insyde Software, used in a wide range of devices from servers to AI PCs. It’s known for its modular architecture, which allows for flexibility and faster development cycles. The kernel likely refers to the core components of this firmware, responsible for low-level hardware interaction and system initialization.

Background: Both CVEs involve UsbCoreDxe and SMRAM interaction.

CVE-2022-30283 is about unsafe memory placement (outside SMRAM).

If a UEFI driver registers an SMI handler but does not properly isolateits memory region, it might place the handler outside SMRAM. This can happen due to incorrect use of SmmInstallProtocolInterface() or similar APIs.

CVE-2024-55567 is about unsafe memory access (inside SMRAM) due to input validation flaws.

CVE-2024-55567 is a vulnerability in the UsbCoreDxe driver of the InsydeH2O UEFI firmware, specifically due to improper input validation. This flaw allows an attacker to write arbitrary memory inside SMRAM, leading to arbitrary code execution at the SMM (System Management Mode).

Vulnerability details: Improper input validation was discovered in UsbCoreDxe in Insyde InsydeH2O kernel 5.4 before 05.47.01, 5.5 before 05.55.01, 5.6 before 05.62.01, and 5.7 before 05.71.01. The SMM module has an SMM call out vulnerability which can be used to write arbitrary memory inside SMRAM and execute arbitrary code at SMM level.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2024-55567

CVE-2025-41234: In specifics condition, Spring Framework vulnerable to reflected file download (RFD) attack. (16-06-2025)

Preface: The Spring Framework is a popular, open-source, Java-based framework that simplifies enterprise application development by providing a comprehensive set of tools and libraries for building robust, scalable, and maintainable applications. It’s known for its core features like dependency injection (DI) and aspect-oriented programming (AOP), and it offers support for various technologies like JDBC, Hibernate, and more. The Spring Framework is a fundamental component of SAP Commerce (formerly known as SAP Hybris). It serves as the foundation for many aspects of the platform, including the Service Layer and the Accelerator storefront.

Ref:  SAP products leverage both Dependency Injection (DI) and Aspect-Oriented Programming (AOP) through the Spring framework, which is heavily integrated into SAP Commerce (formerly Hybris). Spring’s DI allows for managing object dependencies, while AOP provides a way to modularize cross-cutting concerns like logging, security, and transaction management. SAP Commerce (formerly Hybris) licenses can expire. Specifically, the on-premise version of SAP Commerce will reach its End of Mainstream Maintenance (EoMM) on July 31, 2026.

Oracle does not have a direct replacement for SAP Commerce (formerly Hybris) in the same way that SAP replaced Hybris with SAP Commerce Cloud. However, Oracle offers a suite of cloud applications, including Oracle CX Commerce, which serves a similar purpose for B2B and B2C e-commerce and can be considered an alternative. Oracle also provides a broader platform, Oracle Fusion Cloud Applications, which includes various SaaS applications that can be integrated to create a comprehensive business solution, including e-commerce capabilities.

Background: Oracle CX Commerce (formerly known as Oracle Commerce Cloud) utilizes the Spring framework. Specifically, the Oracle Commerce Platform integrates with Spring-based applications. Additionally, the toolkit uses Spring to load objects that represent an EAC (Endeca Application Controller) application. Spring Boot, an extension of the Spring framework, is also used to simplify development, particularly for microservices and web applications.

Vulnerability details: In Spring Framework, versions 6.0.x as of 6.0.5, versions 6.1.x and 6.2.x, an application is vulnerable to a reflected file download (RFD) attack when it sets a “Content-Disposition” header with a non-ASCII charset, where the filename attribute is derived from user-supplied input. Specifically, an application is vulnerable when all the following are true:

* The header is prepared with org.springframework.http.ContentDisposition.

* The filename is set via ContentDisposition.Builder#filename(String, Charset).

* The value for the filename is derived from user-supplied input.

* The application does not sanitize the user-supplied input.

* The downloaded content of the response is injected with malicious commands by the attacker (see RFD paper reference for details). An application is not vulnerable if any of the following is true:

* The application does not set a “Content-Disposition” response header.

* The header is not prepared with org.springframework.http.ContentDisposition.

* The filename is set via one of: * ContentDisposition.Builder#filename(String), or

* ContentDisposition.Builder#filename(String, ASCII)

* The filename is not derived from user-supplied input.

* The filename is derived from user-supplied input but sanitized by the application.

* The attacker cannot inject malicious content in the downloaded content of the response.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2025-41234

CVE-2025-36852: “first-to-cache wins” jeopardizes Bucket-based object storage! (12th June 2025)

Preface: Cloud service providers use “first-to-cache wins” (also known as “cache hit”) for improved performance and efficiency. By caching frequently accessed data, they can quickly retrieve it without needing to access the slower underlying storage layer. This reduces latency, enhances user experience, and can also lower costs associated with accessing and processing data.

Background: In a “first-to-cache wins” scenario, the winning location is in CPU embedded memory, specifically the L1 and L2 caches, which are located directly on the processor chip. The L1 cache is the fastest and smallest, while the L2 cache is slower but larger. Both are much faster than accessing physical memory (RAM).

Do well-known cloud service providers implement the concept of “first-to-cache wins”?

Example 1: S3 is designed to store and manage data objects (files, images, etc.) in the cloud. While S3 itself doesn’t have a “first-to-cache wins” mechanism, it can be used as a layer of caching, especially when combined with other caching services like Amazon ElastiCache for Redis.

Example 2: Google Cloud Storage does not operate on a strict “first-to-cache wins” theory. Instead, it uses a more nuanced caching system that considers factors like the Cache-Control metadata, object type, and the location of the read operation.

Is the Vulnerability Valid?

Yes, it’s valid and serious in the context of build systems that:

-Use remote caching with object storage.

-Allow untrusted contributors (e.g., via pull requests).

-Do not enforce cache validation or isolation between trusted and untrusted environments.

Vulnerability details: A critical security vulnerability exists in remote cache extensions for common build systems utilizing bucket-based remote cache (such as those using Amazon S3, Google Cloud Storage, or similar object storage) that allows any contributor with pull request privileges to inject compromised artifacts from an untrusted environment into trusted production environments without detection. The vulnerability exploits a fundamental design flaw in the “first-to-cache wins” principle, where artifacts built in untrusted environments (feature branches, pull requests) can poison the cache used by trusted environments (protected branches, production deployments). This attack bypasses all traditional security measures including encryption, access controls, and checksum validation because the poisoning occurs during the artifact construction phase, before any security measures are applied.

Official announcement: Please refer to the link for details –

https://www.tenable.com/cve/CVE-2025-36852

https://nx.app/files/cve-2025-06

CVE-2025-2884 – Design weakness in the Trusted Platform Module (TPM) 2.0 reference implementation code. (11th June 2025)

Preface: The main difference between AMD’s Trusted Platform Module (TPM) and those from other manufacturers , how it’s implemented: AMD offers a firmware TPM (fTPM), while many other manufacturers, including Intel, also offer a dedicated hardware TPM (dTPM).

Background: TPM refers to a Trusted Platform Module, which is a specialized chip that securely stores cryptographic keys used for encryption and decryption, enhancing overall system security. AMD’s approach often involves Firmware TPM (fTPM), also known as Intel’s Platform Trust Technology (PTT), which implements TPM functionality within the system’s firmware rather than using a dedicated physical chip.

The AMD Ryzen Embedded 7000 series processors indeed integrate advanced security features, including:

  • AMD Secure Processor (ASP): A dedicated security co-processor embedded directly into the CPU die.
  • Firmware TPM (fTPM): Implemented in firmware and runs on the ASP.
  • Microsoft Pluton: A hardware-based security processor integrated into the silicon, designed to work alongside ASP and fTPM for enhanced protection.

Ref: The most common TPM is the TPM function supported by the Trusted Execution Environment (TEE) of Intel Core i series or AMD Ryzen series CPU in the motherboard UEFI firmware. fTPM can be used in all processors after Intel Broadwell (5th generation) and AMD Ryzen series. This is the most common method because you can easily use the TPM function without purchasing a separate module.

Vulnerability details: An out-of-bounds read vulnerability exists in TPM2.0’s Module Library allowing a read past the end of a TPM2.0 routine as described above. An attacker who can successfully exploit this vulnerability can read sensitive data stored in the TPM and/or impact the availability of the TPM.

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