Angular SSR is vulnerable to SSRF and Header Injection via request handling pipeline
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 21.2.0-rc.0, 21.1.5, 20.3.17, 19.2.21, 21.2.0-rc.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 2 proofs of concept on GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
The Angular SSR is a server-rise rendering tool for Angular applications. Versions prior to 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21 have a Server-Side Request Forgery (SSRF) vulnerability in the Angular SSR request handling pipeline. The vulnerability exists because Angular’s internal URL reconstruction logic directly trusts and consumes user-controlled HTTP headers specifically the Host and `X-Forwarded-*` family to determine the application's base origin without any validation of the destination domain. Specifically, the framework didn't have checks for the host domain, path and character sanitization, and port validation. This vulnerability manifests in two primary ways: implicit relative URL resolution and explicit manual construction. When successfully exploited, this vulnerability allows for arbitrary internal request steering. This can lead to credential exfiltration, internal network probing, and a confidentiality breach. In order to be vulnerable, the victim application must use Angular SSR (Server-Side Rendering), the application must perform `HttpClient` requests using relative URLs OR manually construct URLs using the unvalidated `Host` / `X-Forwarded-*` headers using the `REQUEST` object, the application server must be reachable by an attacker who can influence these headers without strict validation from a front-facing proxy, and the infrastructure (Cloud, CDN, or Load Balancer) must not sanitize or validate incoming headers. Versions 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21 contain a patch. Some workarounds are available. Avoid using `req.headers` for URL construction. Instead, use trusted variables for base API paths. Those who cannot upgrade immediately should implement a middleware in their `server.ts` to enforce numeric ports and validated hostnames.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- angular angular-cli
From 21.2.0-next.2 · fixed in 21.2.0-rc.0; From 21.0.0-next.0 · fixed in 21.1.5; From 20.0.0-next.0 · fixed in 20.3.17; fixed in 19.2.21
- angular @nguniversal/common
through 16.2.0
- angular @nguniversal/express-engine
through 16.2.0
- @angular/ssrnpm
From 21.2.0-next.0 · fixed in 21.2.0-rc.1
- @angular/ssrnpm
From 21.0.0-next.0 · fixed in 21.1.5
- @angular/ssrnpm
From 20.0.0-next.0 · fixed in 20.3.17
- @angular/ssrnpm
fixed in 19.2.21
- @nguniversal/commonnpm
through 16.2.0
- @nguniversal/express-enginenpm
through 16.2.0