CVE-2026-101896

Overview

Angular is a TypeScript-based web development platform for building scalable single-page and server-side rendered applications. It provides a modular architecture, powerful dependency injection, and built-in tools for building modern, performant, and maintainable applications across web, mobile, and desktop environments.

A denial of service vulnerability (CVE-2026-101896) has been identified in the @angular/router URL parser, which allows unauthenticated remote attackers to exhaust the heap of a Node.js server-side rendering (SSR) process with URLs that contain numeric matrix parameter or outlet names. Once the heap is exhausted, the SSR worker terminates with a fatal out-of-memory error.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. If a service receives a very large number of requests, it may cease to be available to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources it uses.

This issue affects multiple versions of Angular.

Details

Module Info

• Product: Angular
• Affected packages: @angular/router
• Affected versions:
  • >=22.0.0-next.0 <22.2.0
  • >=21.0.0-next.0 <21.2.24
  • >=20.0.0-next.0 <20.3.32
  • <=19.2.25
• GitHub repository: https://github.com/angular/angular
• Published packages: https://www.npmjs.com/package/@angular/router
• Package manager: npm
• Fixed in:
  • OSS Angular 20.3.32, 21.2.24, 22.2.0
  • NES for Angular v19.2.32, v18.2.28, v17.3.28, v16.2.28, v15.2.26, v14.3.17, v13.4.19, v12.3.12, v11.2.30, v10.2.22, v9.1.28, v8.2.28, v7.2.29, v6.1.24, v5.2.23, v4.4.17

Vulnerability Info

This High-severity vulnerability is found in the @angular/router package in multiple versions of Angular. When an application renders on the server, @angular/router parses each incoming request URL with UrlParser, which stores matrix parameters, child outlets, and squashed segment groups in plain JavaScript objects keyed by names taken directly from the URL:

private parseParam(params: {[key: string]: string}): void {
  const key = matchMatrixKeySegments(this.remaining);
  if (!key) {
    return;
  }
  this.capture(key);
  let value: any = '';
  if (this.consumeOptional('=')) {
    const valueMatch = matchSegments(this.remaining);
    if (valueMatch) {
      value = valueMatch;
      this.capture(value);
    }
  }

  params[decode(key)] = decode(value);
}

The same pattern appears in parseParens, which assigns segments[outletName ?? PRIMARY_OUTLET] using the outlet name from the URL, and in squashSegmentGroup, which copies those outlet names into a new newChildren object.

When a matrix parameter name or outlet name is a numeric string, V8 treats it as an array index rather than a named property. Assigning moderately large numeric keys to an empty object, such as 990 followed by 2522 in the segment /a;990;2522, causes V8 to allocate a dense element backing store sized to the largest index instead of switching to sparse dictionary storage. A single 11-byte segment therefore consumes roughly 20 KB to 25 KB of heap. Every path segment gets its own parameters object, so an attacker can repeat the segment (/a;990;2522/a;990;2522/...) to reach an amplification factor of about 350x. With request paths of about 8 KB, which fit within common reverse-proxy limits, as few as 12 to 22 concurrent requests can exhaust a 256 MiB to 512 MiB Node.js SSR worker, which then crashes with JavaScript heap out of memory. Exploitation requires that the application runs SSR on Node.js and that any reverse proxy in front of it forwards paths containing semicolons. Client-side-only applications are not affected, because the memory is consumed in the user's own browser.

Mitigation

Angular versions prior to 20 were already End-of-Life when this CVE was published and will not receive any updates to address this issue. For more information see here.

Users of the affected components should apply one of the following mitigations:

• Migrate affected applications to a patched version of Angular.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.