CVE-2026-92708

Under very specific circumstances, parse could create massive ArrayBuffers with very small input. This required a malformed ArrayBuffer custom reviver.

Evaluating legitimate uneval output for a sparse array can allocate memory proportional to its declared length. A tiny serialized value can therefore cause large memory allocation in a consuming browser/runtime. This occurs during evaluation of generated code, not in default parse sparse-array construction.

You would only be affected by this if you were serializing very large sparse arrays and then evaluating the results. In the general use case for uneval of sending data to the client, the worst that could happen is the browser tab running out of memory.

When serializing multiple promises, a later promise can reject before an earlier one settles. An internal rejected promise remains unhandled even if the caller catches the returned stringifyAsync promise. Under Node's default unhandled-rejection behavior this can terminate the process. Applications whose asynchronous failures/timing can be influenced by requests are potentially exposed.

This is essentially impossible to exploit, and is much more likely to surface as a developer-introduced bug.

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.

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.

This is another instance of https://github.com/sveltejs/devalue/security/advisories/GHSA-mwv9-gp5h-frr4, where some payloads could cause parse to create objects with a __proto__ own property. This on its own is not enough to cause prototype pollution, and indeed this is actually how JSON.parse works, but we decided to be a little more defensive here and not allow the creation of objects with __proto__ own-properties. It is very unlikely for this to cause any issues.

uneval performs synchronous work proportional to a sparse array's declared length. An application that passes attacker-influenced sparse values to uneval can suffer event-loop blocking. Since attacker-controlled creation of sparse arrays is so difficult, this vulnerability is very difficult to exploit.

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:

payload = {
- buffer
+ buffer: new Uint8Array(buffer)
}

Under very constrained circumstances, data that was parsed and then passed to uneval could turn a small payload into a very large serialized string.

Under very specific circumstances, parse could create massive ArrayBuffers with very small input. This required a malformed ArrayBuffer custom reviver.

Evaluating legitimate uneval output for a sparse array can allocate memory proportional to its declared length. A tiny serialized value can therefore cause large memory allocation in a consuming browser/runtime. This occurs during evaluation of generated code, not in default parse sparse-array construction.

You would only be affected by this if you were serializing very large sparse arrays and then evaluating the results. In the general use case for uneval of sending data to the client, the worst that could happen is the browser tab running out of memory.

When serializing multiple promises, a later promise can reject before an earlier one settles. An internal rejected promise remains unhandled even if the caller catches the returned stringifyAsync promise. Under Node's default unhandled-rejection behavior this can terminate the process. Applications whose asynchronous failures/timing can be influenced by requests are potentially exposed.

This is essentially impossible to exploit, and is much more likely to surface as a developer-introduced bug.

TuxCare rebuilt devalue to address 5 CVEs. Fixed in 5.9.2-tuxcare.1.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 5.9.0-tuxcare.1.

TuxCare rebuilt devalue to address 4 CVEs. Fixed in 5.9.1-tuxcare.1.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 5.9.0-tuxcare.2.

TuxCare rebuilt devalue to address 3 CVEs. Fixed in 5.9.0-tuxcare.3.

TuxCare rebuilt devalue to address 3 CVEs. Fixed in 4.3.0-tuxcare.4.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 4.3.1-tuxcare.3.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 2.0.1-tuxcare.5.

TuxCare rebuilt devalue to address 3 CVEs. Fixed in 4.3.2-tuxcare.4.

TuxCare rebuilt devalue to address 3 CVEs. Fixed in 4.3.1-tuxcare.4.

TuxCare rebuilt devalue to address 3 CVEs. Fixed in 4.3.3-tuxcare.6.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 5.9.0-tuxcare.4.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 4.3.0-tuxcare.5.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 4.3.2-tuxcare.5.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 4.3.3-tuxcare.7.

TuxCare rebuilt devalue to address 7 CVEs. Fixed in 5.8.2-tuxcare.1.

TuxCare rebuilt devalue to address 6 CVEs. Fixed in 5.8.1-tuxcare.1.

TuxCare rebuilt devalue to address 1 CVE. Fixed in 5.8.2-tuxcare.2.

TuxCare rebuilt devalue to address 2 CVEs. Fixed in 5.8.1-tuxcare.2.