Security
Headlines
HeadlinesLatestCVEs

Tag

#vulnerability

GHSA-pvp8-3xj6-8c6x: Apache Commons Configuration Uncontrolled Resource Consumption

Uncontrolled Resource Consumption vulnerability in Apache Commons Configuration 1.x. There are a number of issues in Apache Commons Configuration 1.x that allow excessive resource consumption when loading untrusted configurations or using unexpected usage patterns. The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenarios where you only load trusted configurations. Users that load untrusted configurations or give attackers control over usage patterns are recommended to upgrade to the 2.x version line, which fixes these issues. Apache Commons Configuration 2.x is not a drop-in replacement, but as it uses a separate Maven groupId and Java package namespace they can be loaded side-by-side, making it possible to do a gradual migration.

ghsa
#vulnerability#ios#apache#git#java#maven
Legacy Login in Microsoft Entra ID Exploited to Breach Cloud Accounts

A flaw in Microsoft Entra ID’s legacy login allowed attackers to bypass MFA, targeting admin accounts across finance,…

Beyond Vulnerability Management – Can You CVE What I CVE?

The Vulnerability Treadmill The reactive nature of vulnerability management, combined with delays from policy and process, strains security teams. Capacity is limited and patching everything immediately is a struggle. Our Vulnerability Operation Center (VOC) dataset analysis identified 1,337,797 unique findings (security issues) across 68,500 unique customer assets. 32,585 of them were distinct

GHSA-8m95-fffc-h4c5: libsql-sqlite3-parser crash due to invalid UTF-8 input

dialect/mod.rs in the libsql-sqlite3-parser crate through 0.13.0 before 14f422a for Rust can crash if the input is not valid UTF-8.

GHSA-2w4w-4385-vh4h: wgp race condition in inner::drop

inner::drop in inner.rs in the wgp crate through 0.2.0 for Rust lacks drop_slow thread synchronization.

GHSA-6x45-r4pr-5362: trailer mishandles allocating with a size of zero

lib.rs in the trailer crate through 0.1.2 for Rust mishandles allocating with a size of zero.

CVE-2025-4372: Chromium: CVE-2025-4372 Use after free in WebAudio

**Why is this Chrome CVE included in the Security Update Guide?** The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. **How can I see the version of the browser?** 1. In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window 2. Click on **Help and Feedback** 3. Click on **About Microsoft Edge**

GHSA-889j-63jv-qhr8: Eclipse Jetty HTTP/2 client can force the server to allocate a humongous byte buffer that may lead to OoM and subsequently the JVM to exit

### Original Report In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting. ### Impact Remote peers can cause the JVM to crash or continuously report OOM. ### Patches 12.0.17 ### Workarounds No workarounds. ### References https://github.com/jetty/jetty.project/issues/12690

GHSA-q4rv-gq96-w7c5: **UNSUPPORTED WHEN ASSIGNED** GzipHandler causes part of request body to be seen as request body of a separate request

In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests.

GHSA-q3m2-crgq-5p3q: OpenStack Ironic fails to restrict paths used for file:// image URLs

OpenStack Ironic before 29.0.1 can write unintended files to a target node disk during image handling (if a deployment was performed via the API). A malicious project assigned as a node owner can provide a path to any local file (readable by ironic-conductor), which may then be written to the target node disk. This is difficult to exploit in practice, because a node deployed in this manner should never reach the ACTIVE state, but it still represents a danger in environments running with non-default, insecure configurations such as with automated cleaning disabled. The fixed versions are 24.1.3, 26.1.1, and 29.0.1.