CVE-2026-92708: devalue: Cross-request process memory disclosure in devalue when `stringify` / `uneval` serialize Node Buffers
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) }
Other sources
Svelte devalue is a JavaScript library that serializes values into strings when JSON.stringify isn't sufficient for the job. In versions 5.1.0 through 5.9.2, stringify and uneval functions serialize a typed array by emitting its entire backing ArrayBuffer rather than only the view, so serializing a Node Buffer, whose backing store is a process-wide shared pool, discloses up to 64 KB of unrelated process memory, including bytes from other in-flight requests. In a server-side-rendered framework such as SvelteKit or Nuxt, a public page whose load() returns a small Buffer, or that reads a small file, can therefore ship another user's request body or Authorization header in its HTML without authentication. Because this occurs during serialization, it fires on every such render and is not mitigated by the parse/unflatten prototype-pollution and denial-of-service guards, which only apply when parsing untrusted input. As a workaround, convert Node Buffer objects to Uint8Array before serialization. This issue has been fixed in version 5.9.3.
— MITRE
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 - Upgrade
Upgrade
devalueto a version that resolves this vulnerability.Fixed in 5.9.3 - Compensating control
Convert Node Buffer objects to Uint8Array before serialization.
Event History
Frequently Asked Questions
Which deployments are realistically exposed to cross-request data leakage?
Server-side applications that use affected devalue versions and serialize Node Buffer values with stringify or uneval are exposed. This is especially consequential in SSR frameworks such as SvelteKit or Nuxt when a public render returns a small Buffer or reads a small file, because the serialized output can be sent in page HTML without authentication.
Does exploitation require an attacker to submit specially crafted input or authenticate?
No. The issue occurs whenever an affected application serializes a Node Buffer, and the described SSR scenario can expose data through a public page without authentication. The disclosed memory may include data from other in-flight requests, such as request bodies or Authorization headers.
Are parser-side prototype-pollution or denial-of-service protections relevant to this issue?
No. Those guards apply when parsing untrusted input, while this disclosure occurs during serialization. They do not prevent memory exposure caused by stringify or uneval serializing a Buffer's full backing ArrayBuffer.
What can be done if upgrading cannot happen immediately?
Convert Node Buffer objects to Uint8Array before passing values to stringify or uneval. Upgrading devalue to version 5.9.3 fixes the issue.