CVE-2026-111751: Npm/@angular/router vulnerability

A denial of service (DoS) vulnerability was identified in @angular/router when Server-Side Rendering (SSR) is enabled on Node.js (V8) and RouterLink directives are rendered with queryParamsHandling: 'merge' or 'preserve', configured either per link or globally via defaultQueryParamsHandling.

Starting in v21.2.0 (angular/angular#66181), RouterLink internals were refactored to use signals, introducing a computed signal (urlTree) that cached the returned UrlTree instance on the directive. Because each rendered link maintains an active RouterLink instance for the entire duration of the request lifecycle, the computed signal permanently pinned the UrlTree and its associated query parameter dictionary in the heap until the SSR response completed.

When query parameter handling is set to 'merge' or 'preserve', each link copies the incoming request's query parameters into its own UrlTree. During SSR, memory consumption scales multiplicatively:

$$\text{Heap Retention} \approx (\text{Number of affected links}) \times (\text{Size of parsed query parameter map})$$

Because parsed JavaScript objects and property dictionaries require substantially more heap space than the raw query string—particularly when property names trigger dense array allocations under V8 property-storage heuristics—an attacker can supply oversized query strings to amplify heap consumption by orders of magnitude per in-flight request.

Impact

Successful exploitation allows an unauthenticated remote attacker to exhaust the Node.js old-space heap with modest concurrent request volume, terminating the SSR worker with an unrecoverable JavaScript heap out of memory fatal crash.

Numeric Names Not Required: Numeric query parameter names trigger larger V8 property-storage allocations (~558 KB per parsed dictionary in tests vs. ~197 KB for non-numeric equivalents), lowering the concurrency threshold needed for a crash. However, non-numeric query parameters also produce significant heap amplification and can exhaust worker memory with proportionally higher concurrency. Client-side SPAs Unaffected: Pure client-side Angular applications (Single Page Applications without SSR) are not vulnerable, as local browser memory consumption does not cross a security boundary.

Attack Preconditions & Vulnerable Configurations

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

1. SSR Enabled: The application runs in a Server-Side Rendering environment powered by Node.js / V8. 2. Merged or Preserved Query Parameters: RouterLink elements rendered during SSR use queryParamsHandling: 'merge' or 'preserve', either bound explicitly on links or configured application-wide via withRouterConfig({ defaultQueryParamsHandling: 'merge' }). 3. Upstream Proxy Forwards Long Request Lines: Reverse proxies or load balancers (e.g., Nginx, AWS ALB, Cloudflare) forward long query strings to the Node.js application rather than rejecting them at the edge. (For example, Nginx's default 8 KB largeclientheaderbuffers limit rejects 16 KB request lines unless explicitly increased). 4. Overlapping Renders: Because retained memory is freed once each request completes, multiple concurrent requests must be processed simultaneously in the same Node.js worker instance (such as pages awaiting asynchronous data fetching, route resolvers, or external API calls during SSR).

Exploit Payload Example

An attacker issues concurrent HTTP requests containing dense query parameters to an SSR page that renders multiple merged links:

http GET /products?0&17&34&51&68&85&...&48042 HTTP/1.1 Host: example.com

Patches

The issue is resolved by removing persistent UrlTree retention from RouterLink (angular/angular#70953). RouterLink now tracks route dependencies directly in reactiveHref and discards intermediate UrlTree instances immediately after computing the serialized href string. The urlTree getter and click handlers compute UrlTree instances on demand.

As a result, intermediate query parameter maps are short-lived allocations collected during young-generation GC scavenges rather than remaining pinned in the heap for the lifetime of the request, restoring the memory profile of Angular 21.1 and earlier.

Patched versions: 22.2.1 21.2.25

Versions prior to 21.2.0 (including Angular 20.x LTS and 21.1.x) do not retain UrlTree instances in RouterLink and are not vulnerable to this issue.

Workarounds & Mitigations

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

1. Avoid 'merge' and 'preserve' on Server-Rendered Links: Remove defaultQueryParamsHandling: 'merge' (or 'preserve') from global configuration. Explicitly bind only the specific query parameters each link requires (e.g., [queryParams]="{ filter: filter() }"). Even on patched versions, this practice prevents unnecessary request-derived parameter propagation into generated DOM markup.

2. Limit Query String Length at Reverse Proxy or Middleware: Configure your edge proxy, web application firewall (WAF), or reverse proxy to reject requests with excessively long query strings (e.g., exceeding 2,048 bytes).

Alternatively, reject oversized query strings in Node.js before Angular SSR handles the request: ts // server.ts (before Angular SSR handler) app.use((req, res, next) => { const queryIndex = req.url.indexOf('?'); if (queryIndex !== -1 && req.url.length - queryIndex > 2048) { res.status(414).send('URI Too Long'); return; } next(); });

3. Increase Node.js Old Space: Increasing --max-old-space-size (e.g., to 2048 MB or 4096 MB) increases the memory headroom and the concurrency threshold required to exhaust memory, though it does not fully eliminate vulnerability under sustained traffic.