CVE-2026-41907

What it actually does

The uuid JavaScript package versions prior to 14.0.0 incorrectly validate caller-provided output buffers for v3, v5, and v6 UUID generation. If an application passes a buffer that is too small, or an offset that places the UUID write outside the intended bounds, the library may silently perform a partial write instead of rejecting the request. At a technical level, this can leave destination buffers containing incomplete UUID data, stale bytes, or mixed old/new values, which may cause identifier corruption, incorrect authorization or object lookup decisions, UUID collisions in application logic, or downstream data integrity failures. Exploitability depends on whether an application exposes control over the buffer, offset, namespace/name inputs, or code path that invokes UUID generation with external buffers.

Why it matters to the business

Applications that rely on uuid-generated values for identifiers, object references, request correlation, tenancy boundaries, idempotency keys, or security-sensitive workflows could produce malformed or partially overwritten identifiers. This may lead to data integrity issues, incorrect record association, failed transactions, broken audit trails, or—in poorly isolated application designs—access to the wrong object or account context. The EPSS score is low and there is no known CISA KEV listing or ransomware association, so broad active exploitation is not currently indicated; however, the package is widely used in the JavaScript ecosystem, so organizations should prioritize inventory and upgrades where UUID output buffers are used in externally reachable application paths.

How an attack unfolds

An attacker would first identify an application endpoint or workflow that triggers UUID v3, v5, or v6 generation through the affected uuid package. The attacker would then attempt to influence parameters that affect the output buffer or offset, either directly through exposed API inputs or indirectly through application logic that derives buffer sizes or offsets from user-controlled values. By causing the application to provide a buffer that is too small or an offset that is outside the intended range, the attacker can make the library perform only a partial UUID write. The resulting value may contain stale or malformed bytes and may be stored, compared, logged, or used by downstream business logic as though it were a valid UUID. Depending on how the application uses the UUID, this could cause object confusion, identifier collisions, corrupted records, failed integrity checks, or unintended authorization outcomes. There is currently no public indication of mature exploit tooling or named threat actor exploitation for this issue.

How to fix it

Upgrade the uuid package to version 14.0.0 or later wherever it is used. If direct upgrade is not immediately possible, avoid passing caller-provided output buffers to v3, v5, or v6 UUID generation, or enforce strict application-side validation before calling the library: the output buffer must be present, must have sufficient length for a full 16-byte UUID write, and the offset must be non-negative and leave at least 16 writable bytes. Treat externally supplied buffer sizes, offsets, or serialization parameters as untrusted. Rebuild and redeploy affected applications after dependency updates, and ensure lockfiles and container images are refreshed so older transitive versions are not retained.

How to confirm the fix worked

Confirm remediation by inspecting package manifests and lockfiles for uuid versions earlier than 14.0.0, including transitive dependencies. Use dependency tooling such as npm ls uuid, yarn why uuid, pnpm why uuid, software composition analysis, or container image scanning to verify the resolved version is 14.0.0 or later. Add or run regression tests that call v3, v5, and v6 UUID generation with too-small buffers and out-of-range offsets and confirm the fixed library rejects invalid writes instead of silently producing partial output. In deployed applications, verify that rebuilt artifacts, serverless bundles, and container images no longer include vulnerable uuid versions.

Typical attack path

1. Identify an application or service using uuid versions prior to 14.0.0.
2. Find a reachable workflow that invokes v3, v5, or v6 UUID generation.
3. Determine whether user-controlled input can influence the output buffer size, output offset, or code path using caller-provided buffers.
4. Send crafted requests that cause a too-small buffer or an out-of-range offset to be supplied to the UUID generation function.
5. Trigger silent partial UUID writes rather than a clean validation failure.
6. Abuse malformed, stale, or partially overwritten UUID values in downstream logic, such as record creation, lookup, correlation, deduplication, authorization, or audit workflows.

How to detect it

There are no universal host, network, or file indicators that prove exploitation because this is a library-level input validation flaw and exploitation effects depend on how each application uses UUIDs. To assess possible prior exploitation, review application logs, API gateway logs, error logs, audit logs, and database integrity or application consistency reports for periods when vulnerable uuid versions were deployed. Look for malformed UUID values, UUIDs with unexpected length or format, repeated UUIDs where uniqueness is expected, sudden increases in identifier collision errors, object lookup mismatches, authorization anomalies involving incorrect object references, validation failures after UUID generation, or application errors around buffer and offset handling. If request logging captures relevant parameters, search for unusual buffer size, offset, length, or serialization values submitted to endpoints that create or transform identifiers. For forensic review, correlate suspicious malformed identifiers with source IPs, user agents, accounts, request paths, and timestamps to determine whether repeated probing or abuse occurred.

What your security team should do

• Inventory all applications, packages, containers, and build artifacts that include the uuid package.
• Prioritize remediation for externally reachable services and systems where UUIDs are used for authorization, object references, idempotency, data partitioning, or audit correlation.
• Upgrade uuid to version 14.0.0 or later and redeploy affected applications from clean builds.
• Review application code for uuid v3, v5, or v6 calls that pass caller-provided buffers or offsets, and add explicit bounds validation even after upgrading.
• Add tests for invalid buffer and offset handling to prevent future regressions.
• Monitor for anomalous malformed UUIDs, unexpected UUID collisions, object lookup failures, or integrity errors in applications that previously used vulnerable versions.
• Because this issue is not currently listed in CISA KEV and has low EPSS, handle it through risk-based dependency patching unless the vulnerable code path is internet-facing or security-sensitive.