Angular @angular/router SSR enables Node.js heap exhaustion

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.32, 21.2.24, and 22.2.0, the @angular/router URL parser stores numeric matrix parameter names and numeric outlet names as properties on initially empty JavaScript objects during Node.js server-side rendering. V8 can interpret these URL-derived keys as array indices and allocate dense backing stores sized to high numeric values, so repeated small path segments cause disproportionate per-segment heap consumption. An unauthenticated attacker can send overlapping requests containing repeated numeric matrix parameters when SSR is enabled, the router directly parses the request URL, and upstream proxies allow semicolons and multiple path segments, eventually exhausting the Node.js old-space heap and terminating the SSR worker. Pure client-side Angular applications are not affected. This issue is fixed in versions 20.3.32, 21.2.24, and 22.2.0.

• @angular/router and Angular deployments using it are affected when Node.js SSR is enabled and request URLs are parsed directly by the router.
• The <= 19.2.25 branch is affected. The CNA/vendor source states that this branch is end of support and will not be patched.
• The >= 20.0.0, < 20.3.32 branch is affected; the corresponding fix is 20.3.32.
• The >= 21.0.0, < 21.2.24 branch is affected; the corresponding fix is 21.2.24.
• The >= 22.0.0, < 22.2.0 branch is affected; the corresponding fix is 22.2.0.
• Pure client-side Angular applications without SSR are outside the affected scope described here.

During Node.js server-side rendering, @angular/router parses request URLs and stores matrix parameter names, outlet names, and per-segment data in ordinary JavaScript objects. When URL-controlled names are numeric strings, V8 can interpret them as array indices and allocate a dense backing store sized to a high index instead of using dictionary storage. Each path segment creates its own parameter object, so repeated small segments across overlapping requests can consume substantially more heap than the URL size suggests. The required conditions are Node.js/V8 SSR, direct parsing of attacker-controlled request URLs by the router, and an upstream proxy that permits semicolons and multiple path segments; this does not apply to pure client-side Angular applications.

The flaw is remotely reachable over the network without authentication or user interaction, but only when the stated SSR and proxy conditions are present. An attacker sends overlapping requests containing repeated numeric matrix parameters across multiple path segments to increase V8 heap consumption rapidly. The supplied assessment describes low attack complexity, while an attack requirement remains because the application must use SSR, the router must directly process the URL, and the proxy must forward the relevant characters and path structure. Once the old-space heap is exhausted, the SSR worker can terminate with JavaScript heap out of memory. The supplied record does not identify observed exploitation or a public exploit.

The technical outcome is uncontrolled resource consumption in the V8 heap, with the main effect on availability. Numeric URL-derived names can be treated as array indices, causing each segment's parameter object to receive a dense backing store much larger than the input data. Overlapping requests can exhaust old-space and terminate the SSR worker.

• No account or separate user interaction is required from the attacker.
• The impact is constrained by deployment conditions: Node.js SSR must be enabled, the router must parse the URL directly, and the proxy must forward the relevant request structure.
• The record provides no evidence of data disclosure, data modification, privilege escalation, or impact to confidentiality and integrity.
• Pure client-side Angular applications do not expose the described SSR path.

The primary business risk is availability for Angular SSR services. A relatively small burst of overlapping requests can cause an SSR worker to hit an out-of-memory failure and terminate, resulting in server-rendering interruptions, elevated request failures, or repeated restarts when the environment automatically replaces the worker.

• The affected scope is the SSR process and services depending on it, not browser memory in pure client-side applications.
• Adding workers or enabling automatic restarts may reduce symptoms temporarily, but can also increase resource consumption and repeat the interruption while malicious requests continue to pass through.
• The record does not establish an effect on confidentiality or integrity.

1. Upgrade @angular/router to the fixed release for the deployed branch: 20.3.32, 21.2.24, or 22.2.0. Verify that the lockfile, build artifact, and runtime all use the fixed package.
2. If the deployment uses the <= 19.2.25 branch, note that the branch is end of support and will not receive a patch. Plan migration to a supported branch with a fixed release after checking application compatibility.
3. If an upgrade cannot be completed immediately, block or strip semicolons from request paths at the reverse proxy or WAF before forwarding requests to the SSR service. Also enforce a strict path-depth limit to reduce the number of segments processed by the router.
4. Increasing the Node.js old-space limit can provide temporary headroom, but it only raises the exhaustion threshold and does not remove the flaw under sustained traffic.
5. After changes, recheck SSR routing, proxy handling of semicolons and multiple path segments, and worker health during rollout. Continue monitoring for heap exhaustion and worker restarts.

1. Inventory deployments that include @angular/router, then compare their installed versions with the affected and fixed branches in affected_summary.
2. Confirm whether each application runs Angular SSR on Node.js/V8 or is a pure client-side application. Pure client-side applications are outside the affected scope described here.
3. Trace request handling to determine whether user-controlled URLs are parsed directly by @angular/router, and check whether the reverse proxy permits semicolons and paths with many segments.
4. As a precaution, review request logs for paths with many segments, repeated matrix parameters, and numeric parameter names. These patterns require investigation but are not confirmed IOCs.
5. Correlate JavaScript heap out of memory, SSR worker exits or restarts, rising latency, and HTTP errors over the same period. The absence of these events does not prove that a deployment is safe.