uuid (uuidjs) CVE-2026-41907

Exploitation requires the target application to invoke uuid library v3, v5, or v6 UUID generation methods (not the more commonly used v1 or v4 methods) with caller-provided output buffers and explicitly specified offset parameters-features typically used only in performance-critical code paths that reuse pre-allocated buffers rather than accepting default return values. The application must also fail to independently validate that buffer size minus offset is at least 16 bytes before passing to uuid functions. Remote network access (AV:N) assumes the application exposes an API or interface where attackers can influence buffer allocation patterns or offset calculations through input manipulation, which is not the default usage pattern. Exploitation is further limited by JavaScript's managed memory model-unlike C/C++ buffer overflows, arbitrary code execution is improbable, restricting impact primarily to data corruption and information disclosure within the same JavaScript heap. Applications using default uuid function invocation patterns (no custom buffers) or exclusively using v1/v4 methods are not vulnerable despite running affected library versions.

Real-world risk assessment presents conflicting signals requiring careful interpretation. CVSS 4.0 base score of 8.1 with vector AV:N/AC:L/PR:N/UI:N suggests remotely exploitable without authentication, indicating high theoretical severity. The confidentiality and integrity impacts are rated High (VC:H/VI:H), consistent with memory corruption vulnerabilities. However, the Exploit Maturity metric shows E:U (unproven), meaning no functional exploit has been publicly demonstrated. The attack complexity is Low (AC:L), yet successful exploitation requires the calling application to: (1) use v3/v5/v6 UUID functions rather than the more common v1/v4, (2) provide custom output buffers instead of accepting default return values, and (3) fail to validate buffer sizes independently. This significantly narrows the attack surface compared to what AV:N/PR:N suggests at first glance. The vulnerability is tagged for both Information Disclosure and Memory Corruption, but JavaScript's managed memory model limits exploitation compared to C/C++ buffer overflows-arbitrary code execution is unlikely, while data corruption and information leakage are plausible outcomes. No EPSS score provided, but the GitHub-reported nature and lack of KEV status suggest this is a supply chain hygiene issue rather than an actively targeted vulnerability. Priority should be medium for organizations using uuid library with custom buffer patterns, low for standard default-usage deployments.

An attacker targets a web application API endpoint that generates namespace-based UUIDs (v5) from user-supplied input and uses a pre-allocated buffer pool for performance optimization. The attacker crafts malicious input that causes the application to request UUID generation with a buffer offset calculated from attacker-controlled data. Because the uuid library does not validate the offset parameter, the resulting UUID bytes are written beyond the buffer boundary into adjacent memory containing sensitive session tokens or cryptographic keys. The attacker then triggers a subsequent API call that reads from the corrupted memory region, leaking the overwritten sensitive data in the response. Alternatively, the attacker corrupts application state variables in adjacent memory to bypass authentication checks or alter business logic flow, achieving unauthorized access or privilege escalation.