CVE-2026-56669: Remote Denial of Service via Algorithmic Complexity and Interpretation Conflict in Elysia

Elysia is an ergonomic web framework designed primarily for the Bun runtime environment. When parsing incoming HTTP POST requests with structured payloads, Elysia normalizes form keys to resolve nested objects and array representations. This normalization mechanism is accessible to unauthenticated remote users on any endpoint that parses form data.

This vulnerability, tracked as CVE-2026-56669, involves a combination of algorithmic complexity mismatch and an HTTP header interpretation conflict. These weaknesses allow a remote attacker to force the server's process into a long-running CPU loop, blocking the runtime's single-threaded event loop and causing a complete denial of service.

The underlying cause is an algorithmic mismatch where the server-side runtime implements key validation in linear time while the framework iterates over keys sequentially. This combination yields quadratic execution time relative to the number of submitted parameters. An attacker can exploit this behavior with minimal network resources.

The root cause of this vulnerability lies in the combination of two security weaknesses. The first is Inefficient Algorithmic Complexity (CWE-407) in the form-data normalization process. The second is an Interpretation Conflict (CWE-436) in the handling of the HTTP Content-Type header.

During body parsing, Elysia iterates over keys returned by the form.keys() method. Within this iteration, the code invokes form.getAll(key) to extract the associated values. Standard JavaScript runtimes, including Bun and Node.js, implement standard FormData lookups as a linear scan over an internal sequential array, resulting in an O(N) complexity for each individual lookup.

Because the normalization loop executes N times and calls an O(N) function during each iteration, the total execution cost scales quadratically to O(N^2). A request containing 500,000 unique keys will require approximately 250 billion operations, blocking the main thread indefinitely.

To exploit this efficiently, an attacker uses an interpretation conflict. By setting the Content-Type header to multipart/form-data;(, application/x-www-form-urlencoded, Elysia recognizes the multipart/form-data substring and routes the request to its form-data parser. However, the underlying runtime's native parser rejects the malformed token and falls back to URL-encoded parsing, allowing the attacker to bundle half a million parameters into a compact body under 2 megabytes.

The vulnerability is located in the key normalization loops within src/dynamic-handle.ts and src/adapter/web-standard/index.ts. Below is a comparison of the vulnerable and patched code patterns.

// Vulnerable: Nested loop logic executing O(N^2) operations
body = {}
const form = await request.formData()
for (const key of form.keys()) {
    if (body[key]) continue
 
    // form.getAll(key) performs an O(N) linear scan over the internal array
    const value = form.getAll(key)
    const finalValue = normalizeFormValue(value)
 
    if (key.includes('.') || key.includes('['))
    // ... nested object handling ...
}

The fix modifies the normalization iteration logic by replacing the multiple $O(N)$ linear scans with a single-pass grouping operation.

// Patched: Linear O(N) grouping logic using Map
body = {}
const form = await request.formData()
const grouped = new Map<string, any[]>()
 
// Iterate exactly once over the form elements: O(N) complexity
form.forEach((v, k) => {
    const list = grouped.get(k)
    if (list) list.push(v)
    else grouped.set(k, [v])
})
 
// Iterate over unique Map entries in linear time
for (const [key, value] of grouped) {
    if (body[key]) continue
 
    const finalValue = normalizeFormValue(value)
 
    if (key.includes('.') || key.includes('['))
    // ... nested object handling ...
}

The patched version replaces the nested iteration with a single pass grouping phase using an ES6 Map. Key lookups and insertions within the Map occur in constant $O(1)$ time, reducing the total computation complexity to linear $O(N)$ and preventing CPU starvation.

Exploitation of this vulnerability requires only a single, well-crafted HTTP POST request containing a large volume of unique query keys. The exploit can be initiated with standard command-line tools.

The attacker crafts an HTTP request body containing 500,000 distinct URL-encoded key-value pairs separated by ampersands. The attacker then assigns a malformed Content-Type header: multipart/form-data;(, application/x-www-form-urlencoded. This ensures the request bypasses standard multipart boundary size checks while still invoking the vulnerable form-data normalization logic.

Once the Elysia server receives the request, the native parser populates the FormData interface in linear time. The framework then initiates its key normalization loop, which attempts to run 250 billion operations on the single thread. This locks the CPU core at 100% capacity and stalls all subsequent HTTP connections until the process is restarted.

The primary impact of CVE-2026-56669 is complete denial of service. Because the Bun and Node.js runtimes run on a single-threaded event loop, blocking the main thread prevents the server from processing any other incoming connections.

No administrative privileges or special configurations are required to execute this attack. Any public endpoint that accepts incoming form submissions can be used as an entry point for exploitation.

This vulnerability does not lead to remote code execution, unauthorized data modification, or information disclosure. The impact is limited entirely to service availability, with a CVSS v3.1 base score of 7.5.

The recommended resolution is to upgrade the elysia dependency to version 1.4.29 or higher. This version updates the normalization logic to use the linear-time Map grouping mechanism.

# Upgrade Elysia using Bun package manager
bun add elysia@1.4.29

If patching is not immediately feasible, deploy a Web Application Firewall rule or reverse proxy rule to filter malformed Content-Type headers. Reject any request where the Content-Type header contains commas, parentheses, or multiple media type declarations.

Additionally, configure rate-limiting rules and enforce limits on the maximum allowed form keys or request body sizes. Restricting the maximum number of unique form parameters to a reasonable threshold (e.g., 1000 fields) prevents attackers from achieving the payload density required to exhaust CPU resources.