CVE-2026-41907: Out-of-Bounds Write in uuid npm Package via Missing Boundary Checks

The uuid package is a foundational component within the Node.js ecosystem, tasked with generating universally unique identifiers across various standard versions. Many applications rely on this library to create predictable or time-based identifiers for database records, session keys, and distributed system tracing.

CVE-2026-41907 represents an out-of-bounds write vulnerability (CWE-787) specifically affecting the v3, v5, and v6 generation routines. These specific functions expose an API allowing developers to supply an optional target buffer and a starting offset index. This feature is intended to optimize memory allocations by writing identifiers directly into large pre-allocated storage structures.

Unlike the secure v1 and v4 implementations, the affected functions lack explicit boundary validation for the caller-provided buffers. Consequently, providing an offset that exceeds the remaining capacity of the buffer forces the library to write out-of-bounds data. Because of the behavior of JavaScript typed arrays, this results in a silent failure state rather than terminating the process.

The fundamental flaw lies in the implementation discrepancy between different UUID generation functions within the library. While the v1, v4, and v7 modules incorporated strict length checks to ensure the target buffer could accommodate a full 16-byte write, the v3 (Name-based MD5), v5 (Name-based SHA-1), and v6 (Reordered time-based) routines omitted these crucial validations entirely.

When invoked with a Uint8Array or Node.js Buffer, the vulnerable functions initiate a sequential loop intending to assign exactly 16 bytes starting from the user-defined offset. The codebase assumes the allocated capacity is sufficient. No arithmetic validation computes whether offset + 16 exceeds buf.length before memory writes begin.

JavaScript handles out-of-bounds access on TypedArray objects by silently dropping the writes rather than throwing an explicit memory fault or standard exception. As the library blindly increments the index past the allocated buffer bounds, the underlying engine ignores the operation. This behavior masks the failure from the calling application, which operates under the assumption that a complete 16-byte UUID was successfully initialized.

Prior to the fix introduced in version 14.0.0, the vulnerable logic resided primarily in src/v35.ts and src/v6.ts. The implementation retrieved the computed bytes and assigned them directly into the buffer array without preliminary bounds verification.

The vulnerable code block demonstrates the explicit absence of validation:

if (buf) {
  offset = offset || 0;
  for (let i = 0; i < 16; ++i) {
    buf[offset + i] = bytes[i]; // No check if offset + i < buf.length
  }
}

The project maintainers resolved the issue in commit 3d2c5b0342f0fcb52a5ac681c3d47c13e7444b34 by implementing a strict mathematical guard. The patch calculates the total required byte range and asserts it against the actual buffer length.

The patched implementation enforces a strict failure requirement:

if (offset < 0 || offset + 16 > buf.length) {
  throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`);
}

Exploiting CVE-2026-41907 requires an attacker to exert influence over either the offset parameter or the size of the target buffer passed to a vulnerable generation function. This scenario typically emerges in data processing applications that pre-allocate large buffers to handle batch operations. If the application derives the offset index from external inputs, the attacker can force out-of-bounds writes.

The attack execution phase relies entirely on the silent failure nature of the vulnerability. The attacker submits a malformed request specifying an offset situated fewer than 16 bytes from the end of the buffer. The function executes, writes only a truncated fraction of the UUID, and completes normally without signaling an error to the host application.

The available proof-of-concept demonstrates this behavioral difference unequivocally. Passing an 8-byte array to the secure v4 function immediately halts execution with a RangeError. Conversely, calling v5 or v6 with the identical 8-byte array suppresses the error entirely, leaving the application state compromised with a malformed identifier.

The primary impact of CVE-2026-41907 is degradation of data integrity and subsequent logical errors. Partially written identifiers directly corrupt the internal application state. If an old buffer is reused, the new identifier will consist of a newly written prefix fused with trailing bytes from the previous memory allocation, causing critical discrepancies in session tracking or record identification.

Truncated identifiers severely diminish the mathematical entropy necessary to guarantee identifier uniqueness. A successful attack drastically increases the statistical probability of identifier collisions. In systems leveraging UUIDs as security tokens, authentication tokens, or access keys, predictable identifiers enable authentication bypass mechanisms and authorization failures.

The assigned CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U yields a base score of 8.1. This reflects a high impact on system integrity and availability. However, with an EPSS score of 0.00055, the immediate likelihood of mass exploitation is low, primarily because the vulnerability relies on specific application architecture patterns to be reachable.

The definitive remediation for CVE-2026-41907 is upgrading the uuid package to fixed versions. Organizations operating on the mainline branch must transition to version 14.0.0. The maintainers have provided backported patches for legacy infrastructure, releasing versions 13.0.1, 12.0.1, and 11.1.1 to close the vulnerability across older deployment profiles.

Environments incapable of immediate package updates must implement custom bounds verification routines preceding all calls to v3, v5, and v6. Developers must verify that offset + 16 does not exceed the provided buffer's length property, discarding the operation or throwing an explicit exception if the check fails.

Security teams can identify vulnerable patterns using static analysis platforms like Semgrep or ESLint. Detection rules must flag instances where v3, v5, or v6 are invoked with a minimum of three arguments, specifically matching conditions where the target parameter is classified as a Buffer or Uint8Array. This highlights code paths requiring explicit bounds review.