CVE-2026-27739: angular-cli · Server-Side Request Forgery (SSRF)
Affects angular-cliSource CVE Database V5
Not known to be exploited · CVSS 9.2 Critical · fixed in 21.2.0-rc.0 : patch angular-cli as a priority.
Data as of 30 Oct 2026, 06:59 UTC
Contested
Critical score, yet low EPSS after six months- EPSS
- 0.5% chance of exploitation in 30 days – higher than 46% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 21.2.0-rc.0, 21.1.5, 20.3.17 +1
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 25 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: evidence found.
Public exploit code: GitHub proofs of concept
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), GitHub proofs of concept, the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade angular-cli to 21.2.0-rc.0, 21.1.5, 20.3.17 or 19.2.21; angular-cli to 19.2.21.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| angularangular-cli | Affected
| Fixed in
|
| angularangular-cli | Affected
| Fixed in
|
| angularangular-cli | Affected
| Fixed in
|
| angularangular-cli | Affected
| Fixed in
|
| angular@nguniversal/common | Affected
| Fixed in– |
| angular@nguniversal/express-engine | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
To mitigate CVE-2026-27739, organizations should immediately upgrade Angular CLI and Angular SSR to versions 21.2.0-rc.1, 21.1.5, 20.3.17, or 19.2.21 or later, where the vulnerability is patched. If immediate upgrade is not feasible, implement middleware in the server.ts file to strictly validate and sanitize incoming Host and X-Forwarded-* headers, enforcing allowed hostnames and numeric port ranges. Avoid constructing URLs for HttpClient requests using untrusted headers such as req.headers; instead, use hardcoded or environment-configured trusted base URLs. Ensure that front-facing proxies, load balancers, CDNs, or cloud infrastructure sanitize or reject suspicious or malformed headers to prevent attacker-controlled header injection. Conduct thorough code reviews to identify any manual URL constructions relying on unvalidated headers and refactor them accordingly. Employ network segmentation and internal service authentication to limit the impact of SSRF if exploited. Monitor logs for unusual internal requests originating from SSR components. Finally, educate developers about the risks of trusting client-supplied headers in server-side rendering contexts.
Description
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.