GHSA-w5hq-g745-h8pq: 
JavaScript vulnerability analysis and mitigation

Summary

The v3(), v5(), and v6() API methods (not uuid release versions) accept external output buffers but do not reject out-of-range writes (small buf or large offset).
By contrast, v4(), v1(), and v7() API methods 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