Preface: When running Windows containers on a Windows host, here’s what happens –

Containers share the host kernel — unlike Linux containers on Linux, Windows containers rely on the Windows kernel and some host services.

Isolation is limited — Windows containers are isolated at the process level, but they can access some host resources, especially if configured with elevated privileges.

Background: DLL Search Order

When an application dynamically loads a DLL using functions like LoadLibrary or LoadLibraryEx without providing a complete path, Windows follows a predefined search order to locate the required DLL. This order typically includes:

• The directory from which the application loaded.
• The system directory (%SystemRoot%\system32).
• The 16-bit system directory.
• The Windows directory (%SystemRoot%).
• The current working directory (CWD).
• The directories listed in the PATH environment variable.

Vulnerability details: NVIDIA Display Driver contains a vulnerability where an uncontrolled DLL loading path might lead to arbitrary denial of service, escalation of privileges, code execution, and data tampering.

Supplement:

If a Windows container is configured to use the GPU and the vulnerable NVIDIA driver is present on the host:

DLL Hijacking Risk: If the container or its processes can influence the DLL search path (e.g., by setting the current working directory or placing files in directories searched first), it might be able to exploit the vulnerability.

Container Escape Potential: If the malicious DLL is loaded by a privileged process (e.g., one running as SYSTEM or with elevated rights), it could lead to privilege escalation or container escape.

Remark: Limited by Container Isolation: If the container is running with strict isolation and without elevated privileges or GPU access, the risk is significantly lower, but not zero — especially if the container can manipulate the environment in which the vulnerable driver operates.

To reduce risk (remedy):

Update the NVIDIA driver — Ensure the host is running a patched version that addresses CVE-2025-23309.

Restrict container privileges — Avoid running containers with elevated privileges or access to host directories.

Use absolute paths in DLL loading — If developing software inside containers, always use secure DLL loading practices.

Monitor container file systems — Prevent unauthorized DLLs from being placed in sensitive directories.

Official announcement: Please see the link for details –

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

Preface: Businesses that deploy Akka with .NET span industries like investment banking, retail, healthcare, and social media, and are often found in sectors requiring high-throughput, low-latency systems such as finance, e-commerce, and online gaming. Companies have used Akka.NET to build microservices, power AI solutions, and create resilient, scalable distributed systems that benefit from its actor-based model for fault tolerance and real-time responsiveness.

Background: Akka.NET is a .NET port of the original Akka project, which originated in the Scala/Java community. It provides an idiomatic .NET implementation of the Actor Model, enabling developers to build highly concurrent, distributed, and fault-tolerant systems using C# and F#.

In C# and F#, “System” typically refers to the System namespace, which is a fundamental part of the .NET Framework and .NET Core. This namespace provides access to core functionality that is essential for almost any .NET application, regardless of whether it’s written in C# or F#.

What Happens Due to the Flaw?

1-Malicious Client connects to the cluster over TLS.

2-Because client certificate validation is not enforced, the cluster accepts the connection.

3-The malicious client can:

Send spoofed messages to actors (e.g., fake orders).

Intercept or manipulate actor responses.

Disrupt trading logic or inject latency.

Official announcement: Please see the link for details –

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

https://getakka.net/articles/remoting/security.html

Preface: Computing technology is advancing rapidly, and software development cycles are shrinking. Furthermore, these shorter-than-expected software development cycles are impacting vulnerability management cycles. Vulnerabilities discovered over a year ago might not be taken seriously. However, nothing in the digital world is completely secure. Therefore, it’s recommended not to ignore outdated CVE records. This topic focuses on a vulnerability discovered in December 2022. The submitter announced this vulnerability in September 2023. CVE-2023-53616 was finally published on October 4, 2025.

This article also contains other perspectives. Please enjoy!

Background: Journaled File System (JFS) is a 64-bit journaling file system created by IBM. There are versions for AIX, OS/2, eComStation, ArcaOS and Linux operating systems.

If diUnmount() writes out the inode map and the filesystem is unmounted, shouldn’t that memory be safe from reuse by attackers? Especially since it’s in kernel space and requires root privileges?

Here’s the key point:

Yes, kernel memory is protected and not directly accessible from user space. However, vulnerabilities like this are dangerous even in kernel space, because:

-Kernel code can be triggered indirectly by user actions (e.g., mounting/unmounting filesystems, accessing files).

-If a stale inode structure remains in memory and is reused without proper reinitialization, it can lead to privilege escalation or data corruption.

-Attackers with some level of access (e.g., via a compromised process or container) might exploit such bugs to gain full root access.

Can ioctl Misuse Lead to Exploitation of This Vulnerability?

Yes, absolutely. Misuse of ioctl (Input/Output Control) calls in kernel modules or drivers can be a vector for exploitation, especially when combined with vulnerabilities like the one in JFS_IP. Please see attached diagram for details.

Official announcement: Please see the link for details –  

https://www.tenable.com/cve/CVE-2023-53616

Preface: AMD does not plan to release any mitigations in response to this report because the reported exploit is outside the scope of the published threat model for SEV-SNP.

Remark: A physical attack is not a cyber attack because “cyber” refers to actions within computer networks and digital systems, whereas a physical attack directly involves the physical world, such as breaking into a building or destroying hardware. While a physical attack can lead to cyber vulnerabilities or data breaches, the act itself is not inherently digital.

Background: SEV-SNP is a TEE that protects the confidentiality and integrity of whole VMs against an attacker with root privileges and physical access to the machine, enabling to run SEV-protected VMs without trusting the infrastructure provider and virtualization layers such as the hypervisor.

A Trusted Execution Environment (TEE) is a secure, isolated area within a device’s main processor, protected from the main operating system and other untrusted software. It uses special hardware to create a trusted space (a “secure world”) to run sensitive code and protect data’s confidentiality and integrity. TEEs are used for security-sensitive operations like biometric authentication, secure payments, and protecting private keys in crypto wallets.

The “probe” for Serial Presence Detect (SPD) data on DDR4 and DDR5 modules is an I2C bus and associated protocols that allow the motherboard’s firmware (BIOS) to read an EEPROM chip on the memory module.

How the Attack Works?

1.Attacker gains physical access to the system and modifies the SPD data.

2.They falsely report a larger memory size than actually exists.

3.This causes the memory controller to use ghost address bits, creating aliasing — multiple physical addresses pointing to the same memory location.

4.The attacker can then:

-Overwrite encrypted guest memory.

-Inject malicious data into memory regions.

-Bypass SEV-SNP’s memory integrity protections, which assume correct physical mappings.

Official announcement: For more details, please refer to the link –

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

Preface: JSON Web Key Sets (JWKS) are a popular and essential component for secure, decentralized authentication systems, particularly in OAuth 2.0 and OpenID Connect (OIDC) flows, where they provide a standardized, interoperable, and scalable method for clients to obtain the public keys needed to verify the digital signatures of JSON Web Tokens (JWTs) without requiring synchronous communication with the identity provider.

Background: Using a JSON Web Key Set (JWKS) eliminates the need for resource servers to resend keys, as they can automatically retrieve new keys from the JWKS endpoint to verify tokens after key rotation, reducing manual effort and downtime. The resource server caches the JWKS document and uses the kid (Key ID) from the token to find the correct public key to validate the signature.

Benefits of using JWKS:

Automated Key Rotation: No manual updates are needed for clients or resource servers when keys are rotated.

Reduced Downtime: Applications can dynamically fetch new keys, minimizing the need for restarts or manual configuration during key rotation.

Simplified Management: A centralized JWKS endpoint simplifies the process of managing public keys across multiple clients and systems.

Enhanced Security: By rotating keys regularly, the window of vulnerability for a compromised key is limited to the time-to-live of the token, minimizing the impact of a potential breach.

Vulnerability details: get-jwks contains fetch utils for JWKS keys. In versions prior to 11.0.2, a vulnerability in get-jwks can lead to cache poisoning in the JWKS key-fetching mechanism. When the iss (issuer) claim is validated only after keys are retrieved from the cache, it is possible for cached keys from an unexpected issuer to be reused, resulting in a bypass of issuer validation. This design flaw enables a potential attack where a malicious actor crafts a pair of JWTs, the first one ensuring that a chosen public key is fetched and stored in the shared JWKS cache, and the second one leveraging that cached key to pass signature validation for a targeted iss value. The vulnerability will work only if the iss validation is done after the use of get-jwks for keys retrieval. This issue has been patched in version 11.0.2.

Official announcement: Please refer to the website for details –

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