CVE-2026-27739: Angular SSR is vulnerable to SSRF and Header Injection via request handling pipeline
A Server-Side Request Forgery (SSRF) vulnerability has been identified 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.
Published Feb 25, 2026
Affected packages
@angular/ssr
- Ecosystem
- npm
- Affected
- >= 21.2.0-next.0, < 21.2.0-rc.0
- Fixed in
- 21.2.0-rc.1
- Check
npm ls @angular/ssr
@angular/ssr
- Ecosystem
- npm
- Affected
- >= 21.0.0-next.0, < 21.1.5
- Fixed in
- 21.1.5
- Check
npm ls @angular/ssr
@angular/ssr
- Ecosystem
- npm
- Affected
- >= 20.0.0-next.0, < 20.3.17
- Fixed in
- 20.3.17
- Check
npm ls @angular/ssr
@angular/ssr
- Ecosystem
- npm
- Affected
- < 19.2.21
- Fixed in
- 19.2.21
- Check
npm ls @angular/ssr
@nguniversal/common
- Ecosystem
- npm
- Affected
- <= 16.2.0
- Fixed in
- No patched version yet
- Check
npm ls @nguniversal/common
@nguniversal/express-engine
- Ecosystem
- npm
- Affected
- <= 16.2.0
- Fixed in
- No patched version yet
- Check
npm ls @nguniversal/express-engine
Advisory details
From the GitHub Advisory Database (CC BY 4.0).
A Server-Side Request Forgery (SSRF) vulnerability has been identified 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 following:
- Host Domain: The
HostandX-Forwarded-Hostheaders were not checked to belong to a trusted origin. This allows an attacker to redefine the "base" of the application to an arbitrary external domain. - Path & Character Sanitization: The
X-Forwarded-Hostheader was not checked for path segments or special characters, allowing manipulation of the base path for all resolved relative URLs. - Port Validation: The
X-Forwarded-Portheader was not verified as numeric, leading to malformed URI construction or injection attacks.
This vulnerability manifests in two primary ways:
- Implicit Relative URL Resolution: Angular's
HttpClientresolves relative URLs against this unvalidated and potentially malformed base origin. An attacker can "steer" these requests to an external server or internal service. - Explicit Manual Construction: Developers injecting the
REQUESTobject to manually construct URLs (for fetch or third-party SDKs) directly inherit these unsanitized values. By accessing theHost/X-Forwarded-*headers, the application logic may perform requests to attacker-controlled destinations or malformed endpoints.
Impact
When successfully exploited, this vulnerability allows for arbitrary internal request steering. This can lead to:
- Credential Exfiltration: Stealing sensitive
Authorizationheaders or session cookies by redirecting them to an attacker's server. - Internal Network Probing: Accessing and transmitting data from internal services, databases, or cloud metadata endpoints (e.g.,
169.254.169.254) not exposed to the public internet. - Confidentiality Breach: Accessing sensitive information processed within the application's server-side context.
Attack Preconditions
- The victim application must use Angular SSR (Server-Side Rendering).
- The application must perform
HttpClientrequests using relative URLs OR manually construct URLs using the unvalidatedHost/X-Forwarded-*headers using theREQUESTobject. - Direct Header Access: The application server is reachable by an attacker who can influence these headers without strict validation from a front-facing proxy.
- Lack of Upstream Validation: The infrastructure (Cloud, CDN, or Load Balancer) does not sanitize or validate incoming headers.
Patches
- 21.2.0-rc.1
- 21.1.5
- 20.3.17
- 19.2.21
Workarounds
- Use Absolute URLs: Avoid using
req.headersfor URL construction. Instead, use trusted variables for your base API paths. - Implement Strict Header Validation (Middleware): If you cannot upgrade immediately, implement a middleware in your
server.tsto enforce numeric ports and validated hostnames.
const ALLOWED_HOSTS = new Set(['your-domain.com']);
app.use((req, res, next) => {
const hostHeader = (req.headers['x-forwarded-host'] ?? req.headers['host'])?.toString();
const portHeader = req.headers['x-forwarded-port']?.toString();
if (hostHeader) {
const hostname = hostHeader.split(':')[0];
// Reject if hostname contains path separators or is not in allowlist
if (/^[a-z0-9.:-]+$/i.test(hostname) ||
(!ALLOWED_HOSTS.has(hostname) && hostname !== 'localhost')) {
return res.status(400).send('Invalid Hostname');
}
}
// Ensure port is strictly numeric if provided
if (portHeader && !/^\d+$/.test(portHeader)) {
return res.status(400).send('Invalid Port');
}
next();
});References
Credited to Yenya030, alan-agius4, securityMB, AndrewKushnir, josephperrott, dgp1130.
References
- https://github.com/angular/angular-cli/security/advisories/GHSA-x288-3778-4hhx
- https://nvd.nist.gov/vuln/detail/CVE-2026-27739
- https://github.com/angular/angular-cli/pull/32516
- https://angular.dev/best-practices/security#preventing-server-side-request-forgery-ssrf
- https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF
- https://github.com/advisories/GHSA-x288-3778-4hhx
How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology
