GHSA-w5hq-g745-h8pq

Summary

v3, v5, and v6 accept external output buffers but do not reject out-of-range writes (small buf or large offset).
By contrast, v4, v1, and v7 explicitly throw RangeError on invalid bounds.

This inconsistency allows silent partial writes into caller-provided buffers.

Affected code

• src/v35.ts (v3/v5 path) writes buf[offset + i] without bounds validation.
• src/v6.ts writes buf[offset + i] without bounds validation.

Reproducible PoC

cd /home/StrawHat/uuid
npm ci
npm run build

node --input-type=module -e "
import {v4,v5,v6} from './dist-node/index.js';
const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8';
for (const [name,fn] of [
  ['v4',()=>v4({},new Uint8Array(8),4)],
  ['v5',()=>v5('x',ns,new Uint8Array(8),4)],
  ['v6',()=>v6({},new Uint8Array(8),4)],
]) {
  try { fn(); console.log(name,'NO_THROW'); }
  catch(e){ console.log(name,'THREW',e.name); }
}"

Observed:

• v4 THREW RangeError
• v5 NO_THROW
• v6 NO_THROW

Example partial overwrite evidence captured during audit:

same true buf [
  170, 170, 170, 170,
   75, 224, 100,  63
]
v6 [
  187, 187, 187, 187,
   31,  19, 185,  64
]

Security impact

• Primary: integrity/robustness issue (silent partial output).
• If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error.
• In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw.

Suggested fix

Add the same guard used by v4/v1/v7:

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

Apply to:

• src/v35.ts (covers v3 and v5)
• src/v6.ts