Header-trust SSRF in Angular @angular/ssr enables internal request steering

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.

• @angular/ssr: The Angular vendor advisory identifies affected branches as >= 21.2.0-next.0, < 21.2.0-rc.1, >= 21.0.0-next.0, < 21.1.5, >= 20.0.0-next.0, < 20.3.17, >= 19.0.0-next.0, < 19.2.21, and <= 18.2.21. The listed patched releases are 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21; no patched release is listed for the <= 18.2.21 branch.
• @nguniversal/common: Versions <= 16.2.0 are affected; no patched release is listed.
• @nguniversal/express-engine: Versions <= 16.2.0 are affected; no patched release is listed.

These boundaries follow the Angular advisory, which identifies the vulnerable runtime package as @angular/ssr. The normalized record's angular-cli product label should not replace checking the actual runtime package.

Angular SSR reconstructs the application's base origin from client-controlled HTTP headers, especially Host and the X-Forwarded-* family, without sufficient validation of the destination domain, path, special characters, or port. In the internal URL handling path, this can change the origin used to resolve relative URLs or influence URLs that application code constructs from REQUEST. The two documented paths are relative HttpClient requests and application code that builds URLs for fetch or third-party SDKs from unvalidated headers. A project issue identifies the relevant logic as createRequestUrl() in packages/angular/ssr/node/src/request.ts and describes the affected context as the production SSR server; the report distinguishes it from the ng serve development server, which has separate host checking. Exploitation requires Angular SSR, attacker influence over the relevant headers, insufficient validation by the front-facing proxy, and infrastructure that does not sanitize or validate incoming headers. The precise request sites and downstream targets remain deployment-specific and depend on application code.

The vulnerability can be reached over the network when the SSR server accepts requests from an attacker. The advisory and supplied record indicate that no attacker authentication or user interaction is required, and that exploitation has low complexity once the necessary deployment conditions exist. The attacker must be able to place chosen values in Host or X-Forwarded-*, either directly or through a proxy that is configured not to validate them. The supplied record sets known_exploited to null and public_exploit to false; those fields do not establish that exploitation is absent in the wild.

When the deployment conditions are present, an attacker can control the base origin that Angular SSR uses for URL resolution. Subsequent server-side requests may then be sent to an attacker-selected server or an internal resource, depending on the URLs generated by the application and the credentials carried by those requests. The primary technical consequence is loss of confidentiality in the SSR context, including exposure of credentials, internal service responses, and cloud metadata; the advisory also describes limited integrity consequences through changes to request destinations or rendered data. The flaw does not automatically grant access to every internal network because the result still depends on the server's network permissions, application request logic, and upstream filtering. A separate technical issue report describes possible cache poisoning in some CDN configurations, but that consequence is deployment-dependent rather than required in every case.

The vulnerability can create the following operational and data risks:

• Data and credential exposure: Redirected requests may disclose Authorization headers, session cookies, or data handled by SSR.
• Expansion of internal network visibility: The SSR server may be used to probe internal services, databases, or cloud metadata endpoints that are not directly reachable from the Internet.
• Trust-boundary risk: A request from the application server to an unintended destination may bypass network controls that assume the server only contacts approved internal resources.
• Limited scope: Not every Angular application is affected. Angular SSR, the relevant URL or header usage, and an unvalidated header path through the proxy or infrastructure must all be present.

1. Upgrade @angular/ssr on the appropriate release branch: use 21.2.0-rc.1 for the 21.2 branch, 21.1.5 for the 21.1 branch, 20.3.17 for the 20 branch, and 19.2.21 for the 19 branch. Do not infer that every later or parallel branch is safe unless the advisory confirms that branch.
2. For affected @nguniversal/common and @nguniversal/express-engine deployments, no specific patched release is listed in the advisory. Apply the mitigations below, evaluate a supported migration path, and obtain vendor guidance before treating an upgrade of another package as a complete fix.
3. Do not use req.headers to construct URLs. Use trusted variables for the base API path or preconfigured absolute URLs instead of deriving the origin from Host or X-Forwarded-*.
4. If an upgrade is not immediately possible, add middleware in server.ts before the Angular engine that permits only allowlisted hostnames, rejects invalid path or character content in host values, and requires X-Forwarded-Port to be numeric.
5. Configure the reverse proxy, CDN, load balancer, or ingress to validate, overwrite, or remove forwarding headers supplied by untrusted clients. Recheck this behavior after infrastructure changes because the product name of a proxy is not evidence that its header handling is safe.

1. Inventory dependency manifests, lockfiles, and deployed artifacts for @angular/ssr, @nguniversal/common, and @nguniversal/express-engine, then compare each installed version with the affected branches in the advisory.
2. Review server and application code for REQUEST, req.headers, Host, X-Forwarded-Host, X-Forwarded-Proto, or X-Forwarded-Port being used to construct URLs, and for relative HttpClient requests executed during SSR.
3. Identify deployments running production SSR rather than only the development server, and map how forwarding headers travel through reverse proxies, CDNs, load balancers, and ingress components.
4. Review proxy and application telemetry for unusual host, path, or port values and for SSR requests rejected after validation is enabled. Treat these as defensive signals, not as vendor-confirmed indicators of compromise.
5. The advisory does not define a reliable IOC specific to this vulnerability. Absence of suspicious log evidence should not be treated as proof that a deployment is safe.