SvelteKit Binary Form Logical Expansion Denial of Service

SvelteKit, a framework for building web applications with Svelte, includes an experimental feature for handling complex form submissions and remote functions (actions) using a custom binary serialization format. This format is designed to efficiently transmit data types that JSON cannot handle natively, such as Date, Map, Set, and binary File objects.

The vulnerability, identified as GHSA-fpg4-jhqr-589c, resides in the deserialize_binary_form function within the runtime package. This function parses incoming requests with the application/x-sveltekit-binary-form content type. The parser reconstructs the payload by reading a header, a metadata block (encoded using the devalue library), an offset table, and the raw binary body.

The flaw involves a logical expansion issue where the parser trusts the metadata definitions without verifying the physical layout of the binary data. Specifically, the implementation allows multiple File objects defined in the metadata to reference the same byte range in the request body. This permits an "amplification" attack where a small network payload is expanded into a large number of in-memory objects or processing operations, leading to Denial of Service (DoS).

The root cause is a lack of structural validation in the deserialize_binary_form function located in packages/kit/src/runtime/form-utils.js. The binary format separates the logical definition of data from the physical bytes.

The Data Structure

The request body is structured as follows:

1. Header: Defines the size of the metadata and the offset table.
2. Metadata: A stringified representation of the data structure (using devalue), containing placeholders for files.
3. Offset Table: An array of integers defining the start and end positions of file data.
4. Data: The raw bytes.

The Logic Error

When the parser encounters a File in the metadata, it uses an index to look up the corresponding start and end positions in the offset table. It then creates a LazyFile object backed by that slice of the request body.

Prior to the patch, the code did not enforce a one-to-one mapping between metadata entries and physical bytes. An attacker could define an array of 10,000 files in the metadata, all pointing to index 0 in the offset table. If index 0 points to a 1MB block of dummy data, the server logically instantiates 10,000 file objects, each 1MB in size. While the physical memory usage might be deduplicated depending on the specific buffer implementation, any application logic that iterates over these files (e.g., calculating checksums, writing to disk, or validating content) will process 10GB of data from a single 1MB request.

The remediation involves strict validation to ensure the binary payload is well-formed and non-overlapping. The patch was applied in commit faba869db3644077169bf5d7c6e41fd5f3d6c65e.

Vulnerable Logic (Conceptual)

The previous implementation simply looked up the offset and created the file, allowing reuse:

// Pseudo-code of vulnerable logic
const files = metadata.map(entry => {
  const [start, end] = offset_table[entry.index];
  return new File(body.slice(start, end), entry.name);
});

Patched Logic

The fix introduces a rigorous validation step that enforces "contiguous and non-overlapping" file spans. It ensures that every byte in the data section belongs to exactly one file.

// patched version in packages/kit/src/runtime/form-utils.js
 
// 1. Collect all spans (start, end) from the offset table
const spans = [];
// ... loop to populate spans ...
 
// 2. Sort spans by start offset
spans.sort((a, b) => a.start - b.start);
 
// 3. Validate continuity
let expected_start = 0;
for (const span of spans) {
  // CHECK: Gap detection
  if (span.start !== expected_start) {
    throw new Error('Invalid binary form data (gap)');
  }
  
  // CHECK: Overlap detection (implicit via sorting and end check)
  expected_start = span.end;
}
 
// 4. Validate total length
if (expected_start !== total_data_length) {
   throw new Error('Invalid binary form data (trailing data)');
}

> [!NOTE] > The patch also ensures that each index in the offset table is used exactly once, preventing multiple metadata entries from referencing the same offset definition.

To exploit this vulnerability, an attacker acts as a client interacting with a SvelteKit application endpoint that utilizes experimental actions or remote functions accepting binary forms. No authentication is strictly required unless the specific endpoint is protected.

Payload Construction

The attacker constructs a POST request with Content-Type: application/x-sveltekit-binary-form. The body is crafted manually to bypass standard client-side serialization.

1. Header Setup: Specify a large metadata size relative to the actual data.
2. Metadata Injection: Create a devalue payload containing an array of thousands of File objects. All of these objects reference the same index (e.g., 0) in the offset table.
3. Offset Table: Define a single entry at index 0 that covers the entire data segment (e.g., 100 KB).
4. Data Segment: Include 100 KB of random noise.

Execution

When the server receives this request:

1. It parses the metadata and instantiates thousands of File objects.
2. It invokes the application's form action handler.
3. If the handler iterates over formData.values() (a common pattern for file uploads), it processes the 100 KB block thousands of times.
4. This results in CPU spikes and potential Out-Of-Memory (OOM) crashes as the garbage collector struggles to manage the allocation pressure, effectively denying service to legitimate users.

The primary impact of this vulnerability is Denial of Service (DoS). By exhausting server resources, an attacker can render the application unresponsive.

• Availability: High. A single attacker can generate significant load with minimal bandwidth, utilizing the amplification factor of the deserialization logic.
• Confidentiality: None. This vulnerability does not expose internal data or allow memory readout.
• Integrity: None. The attacker cannot modify data on the server or execute arbitrary code beyond the resource exhaustion.

CVSS v3.1 Calculation:

• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
• Score: 7.5 (High)
• Justification: The attack is network-exploitable (AV:N), low complexity (AC:L), requires no privileges (PR:N) or user interaction (UI:N), and has a high impact on availability (A:H).

This issue is specific to the Node.js runtime of SvelteKit where this binary handling is implemented; it may not affect adapter-specific deployments that handle bodies differently, though the core logic is in the framework itself.

The vulnerability is patched in the @sveltejs/kit package. Users should upgrade immediately to the latest version available on the 2.x branch.

Official Fix

Upgrade @sveltejs/kit to the latest version (e.g., 2.5.3 or newer). The fix is contained in commit faba869db3644077169bf5d7c6e41fd5f3d6c65e. Verify the installation:

npm ls @sveltejs/kit

Workarounds

If an immediate upgrade is not feasible, the following mitigations can reduce risk:

1. Disable Experimental Features: If the application does not rely on SvelteKit's experimental remote functions or binary form actions, ensure these features are not invoked.
2. WAF Filtering: Configure a Web Application Firewall (WAF) to block requests with the Content-Type: application/x-sveltekit-binary-form. This effectively neutralizes the attack vector but will break legitimate functionality relying on this specific binary serialization.
3. Request Size Limits: Reduce the maximum allowed body size for incoming requests at the reverse proxy level (e.g., Nginx, AWS ALB) to limit the potential amplification factor, although this does not eliminate the logical recursion issue entirely.