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

The relationship between the solar wind and the Earth (14-06-2025)

Preface: Auroras are a visible manifestation of geomagnetic storms. Geomagnetic storms are disturbances in Earth’s magnetosphere caused by the interaction of charged particles from the sun (the solar wind) with Earth’s magnetic field. Auroras typically appear in high latitudes, including northern North America and parts of Asia.

Background: The Sun’s corona and heliosphere, while constantly present, are often unseen. The corona, the Sun’s outermost atmosphere, is extremely hot and extends far into space. This hot gas is flung outwards by the Sun, forming the solar wind, which creates the heliosphere, a bubble surrounding our solar system. In June 2025, NASA’s PUNCH (Polarimeter to the Unseen Corona and Heliosphere) mission has been actively observing coronal mass ejections (CMEs). These observations, including detailed images from the Narrow Field Imager (NFI) and Wide Field Imagers, are providing new insights into the origins and paths of CMEs, helping scientists better understand and predict space weather.

Observation: Due to the high-speed flow of the coronal hole, NASA has issued a G2 (moderate) geomagnetic storm warning on June 14.

Ref: Geomagnetic storms, disturbances in Earth’s magnetic field caused by solar activity, can impact our planet in various ways, primarily affecting technology and infrastructure. While not directly harmful to humans due to our planet’s protective magnetic field and atmosphere, they can disrupt communication systems, navigation, and power grids.

Top Stories: Please see the link for details – https://www.livescience.com/space/the-sun/friday-the-13th-solar-storm-could-bring-auroras-to-18-us-states-this-weekend

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

CVE-2025-38004: An issue related to the automotive industry and Linux was discovered. (10th Jun 2025)

Preface: In the automotive industry, SocketCAN is an open-source implementation of the Controller Area Network (CAN) protocol for Linux. It provides a way for different electronic control units (ECUs) in a vehicle to communicate with each other over the CAN bus. SocketCAN uses the Linux network stack and Berkeley socket API to implement CAN device drivers as network interfaces, allowing multiple applications to access a CAN device simultaneously.

Background: CAN Broadcast Manager (BCM) can send a sequence of CAN frames to an actuator. In fact, a key functionality of the BCM is to handle cyclic transmission of CAN frames, which is commonly used for tasks like sending a sequence of commands or data to control an actuator. Actuators receive signals and respond with specified actions, including changing the air-fuel ratio in the engine, tightening up the suspension, or even applying the brakes. They convert electrical information into mechanical action, directly influencing and controlling a variety of vehicle components.

Vulnerability details: In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the ‘currframe’ counter is then set to zero. Although this appeared to be a safe operation the updates of ‘currframe’ can be triggered from user space and hrtimer context in bcm_can_tx().

Ref: Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the ‘count’ variable has been moved into the protected section as this variable can be modified from both contexts too.

Official announcement: Please see the link for details – https://www.tenable.com/cve/CVE-2025-38004

CVE-2025-0037: About AMD Versal™ Adaptive SoC – Initial publication 2025-06-03

(9th June 2025)

Preface: AMD’s Versal™ Adaptive SoCs are used in a wide range of industries, particularly those requiring high-performance, low-latency processing and flexibility, such as data centers, wireless networking, automotive, aerospace, and defense. Versal chips are also utilized in areas like 5G wireless, advanced driver assist, and even 3D printing.

AMD’s Versal™ Adaptive SoC technology is used in several different chip series, including the Versal AI Edge, Versal AI Core, Versal Prime, Versal Premium, and Versal RF series. These SoCs are designed for a variety of applications, including AI inference, data-intensive workloads, and high-speed communication.

Background: Platform Management Controller (PMC), Platform Loader and Manager (PLM), and boot and configuration are key components in modern embedded systems, especially in Xilinx Versal ACAPs and similar platforms.

Key Steps Illustrated:

1.BootROM loads PL –  Initial boot step from non-volatile memory.

2.PLM starts running – Executes on the MicroBlaze inside the PMC.

3.PLM authenticates and decrypts partitions – Uses hardware accelerators in the PMC for cryptographic operations.

4.PLM configures programmable logic – Loads and configures the Adaptive Engines and other programmable resources.

Remark: To understand the process, please refer to the attached diagram.

Vulnerability details: In Versal™ Adaptive SoC devices, the Platform Loader and Manager (PLM) implements runtime (post-boot) software services that can allow a remote processor to command the PLM to execute cryptographic operations – including AES, SHA3, RSA, ECDSA – using the hardened cryptographic accelerators, eFUSE and BBRAM reads and writes, reloading PDIs, and reading back the FPGA on behalf of the remote processor.

A potential vulnerability exists with commanding these runtime services, in that the memory passed with the command to execute the services is not checked by the PLM to verify that the requesting processor has access to the memory space.

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

CVE-2025-1246: A non-privileged user process can perform valid GPU processing operations (8th June 2025)

Preface: The Valhall family of Mali GPUs uses the same top-level architecture as the previous generation Bifrost GPUs. The Valhall family uses a unified shader core architecture. Arm’s 5th generation GPU architecture, on the other hand, is a type of GPU architecture that is designed for visual computing, especially on mobile devices, and includes features like deferred vertex shading and hardware-based ray tracing. It is a part of the Arm Mali or Immortalis GPU family.

Background: Arm’s Mali GPUs are closely related to the Valhall architecture. Valhall is Arm’s fourth-generation architecture for Mali GPUs, and the Mali-G77 is the first high-end GPU to adopt this architecture. Valhall improves on previous generations of architectures such as Bifrost with a simplified, compiler-friendly instruction set and better compatibility with newer APIs such as Vulkan. The architecture also allows for configuration of the number of shader cores and the size of the L2 cache.

WebGL (Web Graphics Library) and WebGPU (Web Graphics Processing Unit) are both JavaScript APIs that allow web developers to use a computer’s GPU to render 3D graphics and perform computations within a web browser. WebGPU is a newer and more powerful API than WebGL, designed to provide better performance and support for modern GPUs.

Vulnerability details: A non-privileged user process can perform valid GPU processing operations, including via WebGL or WebGPU, to access outside of buffer bounds. This issue has been assigned the identifier CVE-2025-1246.

Affected ProductsBifrost GPU Userspace Driver

CVE-2025-1246: All versions from r18p0-r49p3, r50p0-r51p0 Valhall GPU Userspace Driver

CVE-2025-1246: All versions from r28p0-r49p3, r50p0-r54p0 Arm 5th Gen GPU Architecture Userspace Driver

CVE-2025-1246: All versions from r41p0-r49p3, r50p0-r54p0

Recommendations – These issues have been fixed in the following versions:

Bifrost GPU Userspace Driver – CVE-2025-1246: r49p4, r54p1

Valhall GPU Userspace Driver – CVE-2025-1246: r49p4, r54p1

Arm 5th Gen GPU Architecture Userspace Driver – CVE-2025-1246: r49p4, r54p1

Official announcement: Please see the link for – detailshttps://developer.arm.com/documentation/110466/1-0

CVE-2024-53010 – Improper Access Control in Core (5th Jun 2025)

Preface: Android HLOS –

-Runs on the Application Processor (main CPU)    

-Main Android OS (Linux kernel, system services, apps)

Background: The Snapdragon 8 application processor (including variants like Snapdragon 8 Gen 3 and Snapdragon 8 Elite) uses the Adreno GPU. The Adreno GPU is a core component of Qualcomm’s Snapdragon mobile platforms and is responsible for handling graphics processing and rendering.

HLOS stands for High-Level Operating System, and in Qualcomm’s terminology, it refers to the Android OS running on the Application Processor (AP) of Snapdragon SoCs. This includes:

  • The Android framework
  • System services
  • Linux kernel
  • HALs (Hardware Abstraction Layers)
  • Drivers and other user-space components

In Snapdragon and ARM-based systems, a VM (Virtual Machine) typically refers to a virtualized environment managed by a hypervisor. Qualcomm platforms may use Type-1 hypervisors (like Qualcomm’s own hypervisor or ARM’s KVM/EL2) to isolate different OS environments.

Vulnerability details: Memory corruption may occur while attaching VM when the HLOS retains access to VM.

Official Announcement: Please see the link for details – https://nvd.nist.gov/vuln/detail/CVE-2024-53010