Official Revision Date: 20-10-2025

Preface: A 3rd Gen AMD EPYC processor uses an integrated memory controller within its System on a Chip (SoC) to connect to DDR4 DRAM modules, rather than having a separate memory controller component. The memory controller is part of the I/O Die (IOD) which is connected to the Core Complex Dies (CCDs) via the Infinity Fabric. Each processor has up to eight memory channels, each capable of supporting up to two DIMM slots, for a maximum of 4TB of memory per socket.

Background: The secure memory area for the RMP (Reverse Map Table) on a 3rd Gen AMD EPYC processor is a protected region within the DDR4 DRAM modules themselves, managed by the processor’s security features. It is not located inside the SoC but is in a secure area of the system’s main RAM, making it part of the dedicated system memory rather than the processor’s on-chip memory.

In a 3rd Gen AMD EPYC processor, the secure memory area for the Reverse Map Table (RMP) is a protected region within the DDR4 DRAM modules themselves, not a separate “hidden area” on the SoC. The secure memory is managed by the processor’s security features, such as the AMD Secure Processor (ASP), to protect the RMP and prevent attacks that could manipulate it.

Vulnerability details: Researchers reported a cache-based side-channel that could allow an unprivileged user process on AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) systems to leak up to six bits of physical address information. The researchers also noted that this leakage does not have an immediate security impact.

AMD has determined that the leakage results from Reverse Map Table (RMP) entries being cached in the L1D and L2 caches. Given that at most six physical address bits are exposed, AMD concurs with the researchers that this leakage does not have an immediate security impact.

Ref: In the absence of an immediate fix from AMD, the only way to reduce the risk of cache-based side-channel attacks in SEV-SNP environments is to follow secure memory handling and system-level best practices.

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

Official Revision Date: 17-10-2025

Preface: SEV-SNP is a security technology for confidential computing that encrypts virtual machine memory. SEV-SNP protects memory contents and integrity, and its security model does not depend on the cache indexing method.

Background: While SEV-SNP provides strong memory encryption and integrity protections, it does not offer built-in hardware protections specifically for PIPT cachesagainst all forms of side-channel attacks. However, AMD has introduced optional mitigations and best practices to reduce exposure:

• SEV-SNP includes optional features to mitigate indirect branch predictor poisoning, which is a form of side-channel attack. This helps protect against speculative execution vulnerabilities like Spectre.
• SEV-ES and SEV-SNP encrypt CPU register states during VM exits, preventing leakage of sensitive data through register inspection.
• The Reverse Map Table (RMP) ensures that only the owner of a memory page can write to it. This prevents memory aliasing and replay attacks, which could otherwise be exploited via cache-based side channels.
• SEV-SNP uses Page Validation to ensure that guest pages map to only one physical memory page at a time, reducing the risk of inconsistent memory views that could be exploited.

Vulnerability details: Researchers have shared with AMD a paper titled “GhostFetch: Uncovering and Exploiting the Physical-Address-Indexed Prefetcher to Break AMD SEV-SNP” which describes a prefetcher-based hardware side channel attack.

In their paper the researchers describe a method of using shared prefetcher state to determine whether the virtual address of a load matches the expected address, or whether a load access pattern matches an expected stride.  Either check requires multiple runs but potentially results in loss of confidentiality if the targeted code has either a secret dependent branch or a load access pattern that is secret dependent.

AMD’s response:

AMD believes that the researchers have not identified any AMD prefetchers that have not already been disclosed in the Software Optimization Guide and did not identify any new security implications with AMD prefetchers.

Official announcement: Please see the link for details –

https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7047.html

Preface: SSO isn’t completely secure; in fact, it depends on the design of the entire system. This month, a YouTuber, known for his camera skills, posted a video about his experience, which resulted in him losing all his miles redeemed in February 2025. He contacted airline customer service, but received no reasonable response. The airline strictly adhered to SSO certification regulations. The truth later came to light this month (July 2025).

Background: node-saml is a specific library for implementing SAML 2.0 authentication in Node.js applications. The node-saml is designed for Node.js, meaning its API and integration patterns are tailored for the JavaScript ecosystem. Other SAML libraries exist for different programming languages (e.g., Java, Python, .NET), each with its own conventions and dependencies.

A SAML response or assertion signed with the Identity Provider’s (IdP) private key is considered a validly signed document. This digital signature ensures the integrity and authenticity of the SAML message, confirming it hasn’t been tampered with and originates from a trusted IdP.

SAML relies on digital signatures to ensure the integrity and authenticity of messages exchanged between the Identity Provider (IdP) and the Service Provider (SP). The IdP digitally signs SAML responses and assertions using its private key. The SP then uses the corresponding public key (obtained from the IdP’s signing certificate) to verify the signature, ensuring the message hasn’t been tampered with and originates from a trusted IdP.

Vulnerability details: A SAML library not dependent on any frameworks that runs in Node. In version 5.0.1, Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature. This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username. To conduct the attack an attacker would need a validly signed document from the identity provider (IdP). This is fixed in version 5.1.0.

Official announcement: Please refer to the link for details – https://www.tenable.com/cve/CVE-2025-54419

Preface: Investment bank use Spring Boot for developing microservices and REST APIs. Hospitality utilizes Spring Boot for various backend services. Automotive company Uses Spring Boot for configuration management and service discovery.

Background: IKUN_Library 1.0 is a library management system developed using SpringBoot and MyBatis. It provides functionalities for managing books, readers, and borrowing records. The system includes features like:

• Basic CRUD operations (Create, Read, Update, Delete)
• Login validation with interceptors
• RESTful API for interface design
• Database management using MySQL

Spring Boot is a popular framework that can be used to build a wide variety of Java applications, including: Web applications: Spring Boot is commonly used to build web applications, including REST APIs, web services, and MVC-based applications.

Vulnerability details: A vulnerability has been found in 1902756969/code-projects IKUN_Library 1.0 and classified as problematic. This vulnerability affects the function addInterceptors of the file MvcConfig[.]java of the component Borrow Handler. The manipulation leads to improper access controls. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

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