Critical SSRF Vulnerability Patched in Angular Server-Side Rendering
Take action: If you are using Angular, this is important and urgent. Check your package.json for the possibly risky versions of the libraries, and either patch or sanitize the headers. Always validate incoming headers against a strict allowlist and avoid using client-provided data to build internal request URLs.
Learn More
Angular has released security updates to address a critical Server-Side Request Forgery (SSRF) vulnerability in its Server-Side Rendering (SSR) framework. This vulnerability allows unauthenticated remote attackers to manipulate how the server reconstructs request origins, leading to unauthorized outbound requests from the application server.
The vulnerability is tracked as CVE-2026-27739 (CVSS score 9.2) - A Server-Side Request Forgery (SSRF) vulnerability that occurs because Angular SSR directly trusts user-controlled HTTP headers like Host and X-Forwarded-Host to determine the application's base origin. Attackers can supply crafted header values containing external domains or internal IP addresses, which the framework uses without validation to resolve relative URLs. This mechanism allows an attacker to steer internal HttpClient requests or manual URL constructions toward unintended destinations, such as cloud metadata endpoints or private backend APIs, by bypassing host domain allowlists and port validation.
Successful exploitation enables attackers to probe internal networks and exfiltrate sensitive data from services not exposed to the public internet. If the application includes authentication tokens or session cookies in its server-side requests, these credentials can be leaked to attacker-controlled servers. Attackers can access cloud environment metadata to retrieve temporary credentials or configuration details, potentially leading to a full environment compromise.
The vulnerability impacts the following Angular packages, including @angular/ssr, @nguniversal/common, and @nguniversal/express-engine in versions prior to 21.2.0-rc.1, 21.1.5, 20.3.17, and 19.2.21. Legacy versions, such as 18.2.21 and below, are also listed as vulnerable. Organizations should check their package-lock.json files to identify if these specific dependencies are in use.
Organizations should upgrade to patched versions: 21.2.0-rc.1, 21.1.5, 20.3.17, or 19.2.21. If an immediate upgrade is not possible, developers should implement middleware to validate the Host and X-Forwarded-* headers against a strict allowlist of trusted domains. Additionally, switching from relative to absolute URLs for internal API calls prevents the framework from using the manipulated base origin for request resolution.
