Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. From 21.2.0 until 21.2.25 and 22.2.1, RouterLink directives rendered during Node.js server-side rendering retain computed UrlTree instances for the lifetime of each request. When queryParamsHandling is set to merge or preserve, either per link or through defaultQueryParamsHandling, every rendered link can retain a copy of attacker-controlled query parameters in its UrlTree. When upstream proxies or load balancers forward oversized query strings without rejecting them at the edge, multiple affected links and overlapping renders can amplify heap use until the Node.js old-space heap is exhausted and the SSR worker terminates. Numeric query-parameter names increase allocation pressure but are not required, memory is released after rendering completes, and pure client-side SPAs are not affected. This issue is fixed in versions 21.2.25 and 22.2.1.

Affected: npm: @angular/router

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](https://github.com/angular/angular/pull/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.

###…