SvelteKit Remote Functions: Death by Type Coercion

In the world of web frameworks, 'experimental' is often just a polite synonym for 'un-audited.' SvelteKit, the darling of the modern frontend world, introduced a feature called remote functions to handle server-side logic invoked directly from the client. To make this efficient, they cooked up a custom content type: application/x-svelte-binary-form.

Whenever a developer sees a custom binary protocol being parsed by a high-level language like JavaScript, their ears should perk up. It means the framework is taking raw bytes and trying to turn them into structured objects. And as we all know, if you don't strictly validate what those bytes represent before you start casting them to types, you're asking for trouble.

This vulnerability is a classic case of trusting the input. The parser assumes it's getting a nice, orderly list of numbers. Instead, we're going to feed it a recursive nightmare.

The vulnerability lives in src/runtime/form-utils.js, specifically within the deserialize_binary_form function. This function is responsible for unpacking that custom binary format. Part of this format includes a file offset table—essentially a map telling the server where file data begins and ends in the byte stream.

To parse this table, SvelteKit did something incredibly simple. Too simple:

// The vulnerable code
file_offsets = /** @type {Array<number>} */ (
  JSON.parse(text_decoder.decode(file_offsets_buffer))
);

See the problem? They run JSON.parse() and then immediately cast it to Array<number> via JSDoc comments. But JSDoc is a build-time lie; it doesn't exist at runtime. JSON.parse() will happily parse anything valid JSON—strings, objects, or, most critically, nested arrays.

The code assumes file_offsets is a flat array of integers. It does not check. It just blindly passes this data downstream to the logic that constructs file objects.

Let's look at the diff. The fix is a textbook example of "oops, we forgot to check the types."

Before the fix, the code was cowboy-style:

file_offsets = JSON.parse(text_decoder.decode(file_offsets_buffer));

After the fix (Commit f47c01bd8100328c24fdb8522fe35913b0735f35), sanity is restored:

const parsed_offsets = JSON.parse(text_decoder.decode(file_offsets_buffer));
 
if (
  !Array.isArray(parsed_offsets) ||
  parsed_offsets.some((n) => typeof n !== 'number' || !Number.isInteger(n) || n < 0)
) {
  throw deserialize_error('invalid file offset table');
}
 
file_offsets = parsed_offsets;

The patch explicitly validates that:

1. The result is actually an Array.
2. Every single element is a number.
3. Every number is an integer and non-negative.

Without this check, file_offsets could contain [[1e20, 1e20]], which is syntactically valid JSON but disastrous for the logic that follows.

So, how do we turn a wrong type into a server crash? Welcome to the horrors of JavaScript type coercion.

When the SvelteKit runtime tries to use these "offsets" to initialize File or Blob objects, it inadvertently performs operations that trigger string conversion. If you pass a nested array (e.g., [1e20, 1e20]) into a context expecting a primitive, JavaScript often calls .toString() on it.

Here is the attack flow:

1. Payload Construction: We create a binary form where the offset table is a JSON string of a nested array: [[1e20, 1e20, ...]]. We fill this inner array with massive numbers.
2. The Trigger: We send this to an endpoint with remote functions enabled.
3. The Boom: The server parses the JSON. When it tries to use the inner array as an offset (or part of a file descriptor), JS attempts to coerce it. Array.toString() joins elements with commas.

A relatively small payload (1MB) containing a dense array of these numbers converts into a string representation that is gigabytes in size. The Node.js heap, which usually defaults to a few GBs, fills up instantly.

> [!NOTE] > A 1MB payload was observed to spike memory usage to 14.7 GB before the process died. This is an amplification factor of roughly 14,000x.

The console will spit out Fatal error: Ineffective mark-compacts near heap limit Allocation failed, and the process dies. If you don't have an auto-restarter (or if the attacker puts this in a loop), your service is effectively dead.

The remediation is straightforward: Update to @sveltejs/kit 2.52.2.

If you cannot update immediately, you have two options:

1. Disable Remote Functions: Since this feature is experimental anyway, verify if you are actually using it. If not, turn it off.
2. WAF Filtering: You could theoretically inspect the body of application/x-svelte-binary-form requests. The JSON offset table is usually near the start of the body. If you see nested brackets [[ inside the JSON structure, drop the packet.

But seriously, just patch it. This is a logic error in the runtime, and no amount of firewall rules will be as effective as code that actually checks its inputs.