Orenyomtov

Name of the Vulnerable Software and Affected Versions Rack versions prior to 2.2.23, 3.1.21, and 3.2.6 Description The Rack::Utils.get byte ranges function parses the HTTP Range header without limiting the number of individual byte ranges. While a previous fix for CVE-2024-26141 prevents ranges exceeding the file size, it doesn't restrict the range count. An attacker can send numerous small, overlapping ranges (e.g., '0-0,0-0,0-0,...') to cause excessive CPU, memory, I/O, and bandwidth usage, leading to a denial of service in Rack file-serving paths processing multipart byte range responses. The function `Rack::Utils.get byte ranges` accepts a comma-separated list of byte ranges and validates them based on their aggregate size, but does not impose a limit on how many individual ranges may be supplied. The HTTP `Range` header is the vulnerable component. Recommendations Update to Rack version 2.2.23 or later. Update to Rack version 3.1.21 or later. Update to Rack version 3.2.6 or later.

**Name of the Vulnerable Software and Affected Versions** Cloudreve versions prior to 4.13.0 **Description** Cloudreve is a self-hosted file management and sharing system. Versions prior to 4.13.0 use a weak pseudo-random number generator (`math/rand`) seeded with time to generate critical security secrets, including the `secret key` and `hash id salt`. An attacker can obtain the administrator's account creation time via public API endpoints to narrow the search window for the PRNG seed and use known hashid to validate the seed. By brute-forcing the seed (demonstrated to take less than 3 hours on a general consumer PC), an attacker can predict the `secret key`. This allows them to forge valid JSON Web Tokens (JWTs) for any user, including administrators, leading to full account takeover and privilege escalation. Servers running version 4.10.0 and later are still vulnerable if they were originally installed using an older version, as the weak secrets persist in the configuration. **Recommendations** Upgrade to version 4.13.0 to invalidate the existing `secret key` and regenerate a new, cryptographically secure `secret key` using crypto/rand. If an immediate upgrade is not possible, stop the Cloudreve service, locate the `secret key` setting in the Cloudreve database, replace the value with a long, random string (e.g., generated via `openssl rand -base64 64`), and restart the Cloudreve service. Note that this will log out all currently active users.

**Name of the Vulnerable Software and Affected Versions** ML-DSA crate versions 0.0.4 through 0.1.0-rc.4 **Description** The ML-DSA crate, a Rust implementation of the Module-Lattice-Based Digital Signature Standard (ML-DSA), contains a flaw in its signature verification implementation. Versions starting from 0.0.4 and before 0.1.0-rc.4 incorrectly accept signatures with repeated hint indices. The ML-DSA specification requires hint indices within each polynomial to be strictly increasing, but the implementation uses a non-strict monotonic check, allowing duplicate indices. This is a regression introduced by a change from a strict comparison (`<`) to a non-strict comparison (`<=`) in version 0.0.4. **Recommendations** Update to version 0.1.0-rc.4 or later.

**Name of the Vulnerable Software and Affected Versions** Bun versions prior to 1.3.5 **Description** The default trusted dependencies list in Bun can be manipulated by a non-npm package if the package name matches an existing trusted dependency. This affects dependencies installed via file, link, or git/github sources. **Recommendations** Update to version 1.3.5 or later.