Memory amplification: ~350x (Source: GitHub Advisory Database, GHSA-ff3f-86qr-9cv3 (September 30, 2026))
The cheapest attacks on a web service are the lopsided ones. The attacker sends almost nothing, and the server does a great deal of work. A new advisory on Angular's server-side rendering shows how lopsided that can get.
What the advisory reports
The GitHub Advisory Database published GHSA-ff3f-86qr-9cv3 on September 30, 2026. It describes a denial-of-service flaw in @angular/router, the part of Angular that reads page addresses. The flaw applies when server-side rendering (SSR) runs on Node.js. SSR means the server builds each page before sending it to the visitor.
The advisory says an unauthenticated remote attacker can use the flaw to exhaust the Node.js memory heap. The result is a fatal "JavaScript heap out of memory" error that terminates the SSR worker.
How a short URL becomes a large memory bill
Angular's router splits an incoming address into pieces. Some pieces are "matrix parameters", which are extra values attached to a path segment with semicolons. An example is /a;990;2522.
The router stores these values in a plain JavaScript object. When the names are numbers, the V8 engine treats them as array positions. V8 is the JavaScript engine inside Node.js.
The advisory says V8 then reserves a block of memory sized to the largest number, instead of storing the values sparsely. For the key 2522, that is about 2,522 pointers. The advisory puts it at roughly 20 KB to 25 KB for a single 11-byte segment.
Every segment in a path gets its own object. An attacker can therefore repeat the pattern and multiply the cost within one request.
How few requests it takes
One short segment is not enough. The attack chains many of them into a long path and sends several such requests at once.
The advisory gives two test figures. With 8 KB paths of about 740 segments, 12 to 22 concurrent requests crash a worker with 256 MiB to 512 MiB of memory. The 8 KB path size stays within default Nginx buffer limits.
With smaller 1 KB to 2 KB paths of 90 to 180 segments, a burst of 50 to 100 concurrent requests does the same. No login is needed and no large traffic spike is required.
Who is exposed, and who is not
The advisory says an application is affected only if three conditions hold. It runs SSR on Node.js. User-controlled URLs reach @angular/router during rendering. And no reverse proxy strips or rejects semicolons and long paths before the request arrives.
The advisory lists Nginx, Cloudflare and ALB as proxies that can forward such URLs without stripping them, and says they can be configured to reject them. Pure client-side Angular apps without SSR are not vulnerable, because the memory used is the visitor's own.
The advisory excerpt does not list affected or patched version numbers. Teams should read the full advisory for those.
The lesson: the edge is part of the defence
This shows that a framework flaw and a proxy setting can combine into one risk. The bug sits in the router. The exposure depends on whether the layer in front of it passes the request through.
That split matters for ownership. The application team owns the Angular upgrade. Someone else often owns the proxy rules. If neither knows about the other's part, each can assume the other has it covered.
The advisory's fix changes the router to force dictionary-style storage for numeric URL-derived keys at index 32 and above. It says this keeps route matching, parameter values and component inputs working.
How common is Angular?
In WebPulse's September 2026 scan of the Tranco top 10,000 domains, 7,064 sites responded. A platform was detected on 2,491. Angular was detected on 155 of those.
The scan cannot tell whether a given site uses SSR. The figure shows how many sites in the sample run Angular. It does not show how many are affected.
Questions to put to your team
Ask whether any of your Angular applications render on the server. If they do, ask which version each runs and whether it includes the fix from the advisory.
Ask who owns the reverse proxy in front of them. The advisory suggests two interim measures. One is to reject requests with semicolons in the path. The other is to cap path depth at roughly 20 to 30 segments.
The advisory also suggests raising Node's --max-old-space-size to 2048 or 4096 MB. That raises the number of requests needed to exhaust memory. It says this does not fully remove the flaw under sustained traffic.
Last, ask what happens when an SSR worker dies. A small burst of concurrent requests can kill a worker. How long the outage lasts depends on your restart setup. Slow or manual restarts mean a longer one.
The patch fixes this flaw. Edge rules and a restart plan limit the damage of any similar flaw.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
