Preface: While it’s technically possible to update UEFI firmware from within a Linux user space environment, it’s not a common or recommended practice. Most UEFI updates are designed to be installed through specific utilities provided by the motherboard manufacturer, often requiring a bootable medium or a dedicated Windows application.

Background: EDK II, also known as EDK2, is an open-source firmware development environment for the Unified Extensible Firmware Interface (UEFI) and Platform Initialization (PI) specifications. It’s a modern, feature-rich, and cross-platform environment developed by the Tianocore project. Think of it as the official development environment for UEFI applications and a core component of many platforms’ firmware

TianoCore is an open-source community focused on developing and promoting the Unified Extensible Firmware Interface (UEFI). It provides a firmware development environment, primarily known as EDK II, which is used for building UEFI firmware, drivers, and applications. TianoCore is a reference implementation of UEFI and is widely adopted by the industry.

Technical details: A researcher reported a bug in the open source EDK2 system management interrupt (SMI) entry code when an MCE occurs near the start of the SMI handler.  An attacker who can inject a machine check exception (MCE) could cause execution to jump to an attacker-controlled interrupt handler, leading to arbitration code execution.

Ref: On AMD EPYC processors, the System Management Mode (SMM) functionality is indeed implemented within the System Management Unit (SMU), which is a distinct block of logic on the processor die.

The System Management Unit (SMU) contains a mailbox function to facilitate communication between the SMU and other system components, including the CPU and operating system. This mailbox acts as a communication channel for sending commands and data, and receiving responses, enabling the SMU to perform its tasks related to system management, power management, and hardware control.

Official announcement: Please refer to the following link for detailshttps://www.amd.com/en/resources/product-security/bulletin/amd-sb-7043.html

NVD Published Date: 08/01/2025

NVD Last Modified: 08/01/2025

Preface: While HTTP/1.0 is largely obsolete, HTTP/1.1 remains in widespread use, despite the newer HTTP/2 and HTTP/3 protocols. Though HTTP/1.1 has been updated in recent years, its core functionality is still foundational for much of the web.

Does processing Uniform Resource Names consume memory?

Yes, processing Uniform Resource Names (URNs) can consume memory. While URNs themselves are symbolic names and don’t directly represent the resource’s location or data, they need to be processed to resolve them, which often involves memory allocation for parsing, data storage, and potential redirection handling.

Background: Squid Proxy is a caching proxy, and that’s a key aspect of how it functions. It’s not just a proxy that forwards requests; it also stores copies of frequently accessed web content locally. This caching behavior significantly speeds up subsequent requests for the same content, making it faster and more efficient than a simple forwarding proxy.

A “Trivial-HTTP response,” often abbreviated as THTTP, refers to a convention for encoding resolution service requests and responses using the HTTP/1.0 or HTTP/1.1 protocols, as defined in RFC 2169.

Squid Proxy is primarily developed using C++. While it utilizes some C language components and libraries, the dominant language in its codebase is C++.

Ref: STCB, in the context of Squid cache, refers to the StoreEntry data structure, which is a key component of how Squid caches web content in memory. It’s a relatively small amount of metadata associated with each cached object, stored in memory to speed up access and retrieval

Vulnerability details: Squid is a caching proxy for the Web. In versions 6.3 and below, Squid is vulnerable to a heap buffer overflow and possible remote code execution attack when processing URN due to incorrect buffer management. This has been fixed in version 6.4. To work around this issue, disable URN access permissions.

Official announcement: Please see the link for details –

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

Preface: Regular Expressions are efficient in that one line of code can save you writing hundreds of lines. But they’re normally slower (even pre-compiled) than thoughtful hand written code simply due to the overhead. Generally the simpler the objective the worse Regular Expressions are. They’re better for complex operations.

Background: OAuth2 Proxy is used to add authentication to applications that don’t natively support it, acting as a reverse proxy that handles authentication using OAuth2 providers like Google, GitHub, or Okta. It simplifies the process of adding authentication to existing applications by separating the authentication logic from the application code. This allows developers to focus on building their core application logic without needing to implement complex authentication workflows.

Vulnerability details: In versions 7.10.0 and below, oauth2-proxy deployments are vulnerable when using the skip_auth_routes configuration option with regex patterns. Attackers can bypass authentication by crafting URLs with query parameters that satisfy configured regex patterns, allowing unauthorized access to protected resources. The issue stems from skip_auth_routes matching against the full request URI. Deployments using skip_auth_routes with regex patterns containing wildcards or broad matching patterns are most at risk.

Resolution: This issue is fixed in version 7.11.0

Workarounds include: auditing all skip_auth_routes configurations for overly permissive patterns, replacing wildcard patterns with exact path matches where possible, ensuring regex patterns are properly anchored (starting with ^ and ending with $), or implementing custom validation that strips query parameters before regex matching.

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