GHSA-j22f-vq7h-c4qm: Infoleak
Impact
stringify and uneval serialize a typed array by emitting its backing ArrayBuffer, not just the view. In the case of a Node Buffer object, the backing buffer is a process-wide shared pool, meaning unrelated memory can be serialized into a response that is then sent to the client. For a Node Buffer the backing store is Node's process-wide shared pool, so serializing a small Buffer copies up to 64 KB of unrelated process memory — including bytes from other in-flight requests — into the output. In an SSR framework (SvelteKit, Nuxt) a public page whose load() returns a 2-byte Buffer, or a small file read with readFileSync, ships another user's request body / Authorization header in its HTML. Unauthenticated, silent, ~43,000× amplification.
This is serialization-side, so the parse/unflatten prototype-pollution and DoS guards do not apply — it fires on every SSR render, not only when parsing untrusted input.
Workarounds
Convert Node Buffer objects to Uint8Array:
diff payload = { - buffer + buffer: new Uint8Array(buffer) }
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/devalueto a version that resolves this vulnerability.Fixed in 5.9.3 - Compensating control
Convert Node Buffer objects to Uint8Array before serialization, for example with `new Uint8Array(buffer)`, instead of serializing the Buffer directly.
Event History
Frequently Asked Questions
Who is most exposed to this issue?
Applications using devalue in server-side rendering are exposed when a public page serializes a Node Buffer, including a Buffer returned from a load() function or produced by a small readFileSync call. The serialized response can disclose unrelated memory from the Node process-wide Buffer pool to the client.
Does exploitation require authentication or attacker interaction?
No. The issue is described as unauthenticated and silent: it occurs whenever an affected SSR render serializes a Node Buffer, without relying on parsing attacker-controlled input.
Why do existing devalue parsing protections not prevent this leak?
The leak occurs during serialization, not during parse or unflatten processing. Prototype-pollution and denial-of-service guards in those parsing paths therefore do not apply.
What can be done if patching is not immediately possible?
Avoid serializing Node Buffer objects through devalue. Convert each Buffer to a Uint8Array before placing it in the serialized payload, for example: buffer: new Uint8Array(buffer).