GHSA-62VG-58RM-QFF7
Vulnerability from github – Published: 2026-10-20 14:36 – Updated: 2026-10-20 14:36A 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:
- SSR Enabled: The application renders on demand on a Node.js / V8 server.
- 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}]}). - 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.
- 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:
GET /shop/(a:/()//b:/()//c:/()//...)?param1=value¶m2=value... HTTP/1.1
Host: example.com
Against a configuration with named-outlet or sibling routes:
GET /dashboard/(detail:1//x:/(detail:1//x:/(...)//y:/(...))//y:/(...)) HTTP/1.1
Host: example.com
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:
-
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:
```typescript // 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();
}); ```
-
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.
-
Increase Node.js Old Space: Increasing
--max-old-space-sizeraises the request size and concurrency required to exhaust memory, though it does not eliminate the issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@angular/router"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0"
},
{
"fixed": "22.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/router"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0"
},
{
"fixed": "21.2.25"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/router"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0"
},
{
"fixed": "20.3.33"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/router"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "19.2.25"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-111752"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-405"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-20T14:36:39Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "A denial of service (DoS) vulnerability was identified in `@angular/router` when Server-Side Rendering (SSR) is enabled on Node.js (V8).\n\nDuring 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.\n\nWhen 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.\n\nAn 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.\n\n### Impact\n\nSuccessful 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.\n\n* **Transient Allocation:** Memory is released once route recognition completes; there is no persistent memory leak. The primary impact is process termination.\n* **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.\n* **Prerendering (SSG) Unaffected:** Build-time prerendering does not process attacker-supplied request URLs.\n\n### Attack Preconditions \u0026 Vulnerable Configurations\n\nAn application is affected only if all of the following conditions are met:\n\n1. **SSR Enabled:** The application renders on demand on a Node.js / V8 server.\n2. **Susceptible Route Configuration:** At least one level of the route configuration contains either:\n * an empty-path (`path: \"\"`) route (e.g., `{path: \"\", component: ShopPage}`), or\n * a route assigned to a named outlet (e.g., `{path: \"dashboard\", children: [{path: \":id\", outlet: \"detail\", component: DetailPanel}]}`).\n3. **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.\n4. **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\u20131 GiB).\n\n### Exploit Payload Examples\n\nAgainst a configuration with empty-path (`path: \"\"`) routes and query parameters:\n\n```http\nGET /shop/(a:/()//b:/()//c:/()//...)?param1=value\u0026param2=value... HTTP/1.1\nHost: example.com\n```\n\nAgainst a configuration with named-outlet or sibling routes:\n\n```http\nGET /dashboard/(detail:1//x:/(detail:1//x:/(...)//y:/(...))//y:/(...)) HTTP/1.1\nHost: example.com\n```\n\n### Patches\n\nThe issue is resolved in [angular/angular#71055](https://github.com/angular/angular/pull/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.\n\nPatched versions:\n* `22.2.1`\n* `21.2.25`\n* `20.3.33`\n\nVersions prior to v20 are also affected but are no longer supported and will not receive a patch.\n\n### Workarounds \u0026 Mitigations\n\nIf you cannot immediately upgrade to a patched version, apply one or more of the following mitigations:\n\n1. **Reject Parenthesized or Empty-Path Outlet URLs in Middleware or WAF (Recommended):**\n 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 `///( `.\n\n * If your application does **not** use named (auxiliary) outlets in URLs, reject requests whose path contains `(` or `)` before Angular SSR handles the request.\n * If your application does use named outlets, reject requests whose path contains empty-path outlet sequences (`:/( `, `(/ `, or `///( `).\n\n Unlike URL length limits, this completely blocks both heap exhaustion and short-URL guard/resolver amplification:\n\n ```typescript\n // server.ts (placed before Angular SSR handler)\n app.use((req, res, next) =\u003e {\n let pathname: string;\n try {\n pathname = decodeURI(req.url.split(/[?#]/, 1)[0]);\n } catch {\n res.status(400).send(\"Bad Request\");\n return;\n }\n\n // Option A: If the app does not use named outlets in URLs, block all parenthesized groups:\n if (/[()]/.test(pathname)) {\n res.status(400).send(\"Bad Request\");\n return;\n }\n\n // Option B: If the app uses named outlets, block only empty-path outlet groups:\n if (/:\\/\\(|\\(\\//\\(|\\/\\/\\/\\(/.test(pathname)) {\n res.status(400).send(\"Bad Request\");\n return;\n }\n\n next();\n });\n ```\n\n2. **Limit URL Length at Reverse Proxy or Middleware:**\n 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.\n\n3. **Increase Node.js Old Space:**\n Increasing `--max-old-space-size` raises the request size and concurrency required to exhaust memory, though it does not eliminate the issue.",
"id": "GHSA-62vg-58rm-qff7",
"modified": "2026-10-20T14:36:39Z",
"published": "2026-10-20T14:36:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-62vg-58rm-qff7"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/issues/70997"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/71055"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/a83f8119acd466b524ae0113096ed188358d6d6c"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/b0d2ba0f54e21cb57ea5a0ca0d8e6065f28e23a0"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/b6bf6504adab1a78cc62ad8402f6bed229e620bd"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/commit/e9bf52aa03a3b9b302c33ffbc967ef0e1de5fb79"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "@angular/router: Denial of Service via Unmatched Empty-Path Outlet Route Matching in Server-Side Rendering (SSR)"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.