A denial of service (DoS) vulnerability was identified in @angular/router when Server-Side Rendering (SSR) is enabled on Node.js (V8).

During route recognition, @angular/router fails to validate whether an auxiliary outlet segment in the URL matches a route configured for that specific outlet name. Because unconfigured empty-path outlet groups (such as a:/(), x:/(...), or ///(...)) are not rejected during matching, the router repeatedly re-evaluates the route configuration against each arbitrary outlet segment provided in the URL.

When a request URL contains multiple arbitrary empty-path outlet segments, this improper matching forces the router to instantiate duplicate ActivatedRouteSnapshot trees, repeatedly execute canMatch guards and route resolvers, and allocate separate copies of route parameters and queryParams for each unconfigured outlet.

An unauthenticated remote attacker can exploit this behavior by sending requests with crafted outlet segments to exhaust the Node.js memory heap or overwhelm CPU resources, leading to SSR worker termination and service disruption.

Impact

Successful exploitation allows an unauthenticated remote attacker to exhaust the Node.js heap with a single crafted request or a small number of concurrent requests, terminating the SSR worker process with a fatal JavaScript heap out-of-memory crash. When the matched routes declare canMatch guards or resolvers, a single short request can also trigger repeated guard or resolver executions, increasing load on backend services and holding worker connections open.

• Transient Allocation: Memory is released once route recognition completes; there is no persistent memory leak. The primary impact is process termination.
• Client-side SPAs Unaffected: Client-side Angular applications running in the browser are not vulnerable, as browser memory consumption does not cross a security boundary.
• Prerendering (SSG) Unaffected: Build-time prerendering does not process attacker-supplied request URLs.

Attack Preconditions & Vulnerable Configurations

An application is affected only if all of the following conditions are met:

1. SSR Enabled: The application renders on demand on a Node.js / V8 server.
2. Susceptible Route Configuration: At least one level of the route configuration contains either:
   • an empty-path (path: "") route (e.g., {path: "", component: ShopPage}), or
   • a route assigned to a named outlet (e.g., {path: "dashboard", children: [{path: ":id", outlet: "detail", component: DetailPanel}]}).
3. Upstream Request Line Forwarding: Request lines reach the Node.js process without being rejected upstream by edge proxies. Node.js accepts request headers up to 16 KiB by default. Guard/resolver amplification requires only a short URL.
4. Constrained Heap Size: Worker heaps are sized small enough relative to the request payload and concurrency (e.g., containers or serverless instances configured with 128 MiB–1 GiB).

Exploit Payload Examples

Against a configuration with empty-path (path: "") routes and query parameters:

Against a configuration with named-outlet or sibling routes:

Patches

The issue is resolved in angular/angular#71055. The router now requires every child outlet segment group to match a route configured for its target outlet before unwrapping child segments or completing a match, and prevents unconfigured empty-path outlet groups from matching routes declared for other outlets.

Patched versions:

• 22.2.1
• 21.2.25
• 20.3.33

Versions prior to v20 are also affected but are no longer supported and will not receive a patch.

Workarounds & Mitigations

If you cannot immediately upgrade to a patched version, apply one or more of the following mitigations:

1. Reject Parenthesized or Empty-Path Outlet URLs in Middleware or WAF (Recommended): In @angular/router, auxiliary outlet groups in a URL always use parentheses (...), and empty-path outlet groups in a URL always take the form :/( , (/ , or ///( .

   • If your application does not use named (auxiliary) outlets in URLs, reject requests whose path contains ( or ) before Angular SSR handles the request.
   • If your application does use named outlets, reject requests whose path contains empty-path outlet sequences (:/( , (/ , or ///( ).

   Unlike URL length limits, this completely blocks both heap exhaustion and short-URL guard/resolver amplification:

   // server.ts (placed before Angular SSR handler) app.use((req, res, next) => { let pathname: string; try { pathname = decodeURI(req.url.split(/[?#]/, 1)[0]); } catch { res.status(400).send("Bad Request"); return; } // Option A: If the app does not use named outlets in URLs, block all parenthesized groups: if (/[()]/.test(pathname)) { res.status(400).send("Bad Request"); return; } // Option B: If the app uses named outlets, block only empty-path outlet groups: if (/:\/\(|\(\//\(|\/\/\/\(/.test(pathname)) { res.status(400).send("Bad Request"); return; } next(); });

2. Limit URL Length at Reverse Proxy or Middleware: Configure your edge proxy, web application firewall (WAF), or reverse proxy to reject requests with excessively long URLs (e.g., exceeding 2,048 bytes). The outlet portion of the payload is in the path, so limit the full request target, not only the query string. This reduces, but does not eliminate, guard/resolver amplification, which requires only a short URL.

3. Increase Node.js Old Space: Increasing --max-old-space-size raises the request size and concurrency required to exhaust memory, though it does not eliminate the issue.