CVE-2026-27739: 
JavaScript vulnerability analysis and mitigation

CVE-2026-27739 is a Server-Side Request Forgery (SSRF) and Header Injection vulnerability in Angular SSR (Server-Side Rendering), affecting the @angular/ssr npm package. The flaw was reported via the Google OSS Vulnerability Reward Program and disclosed publicly on February 23–25, 2026. Affected versions include @angular/ssr prior to 19.2.21, 20.3.17, 21.1.5, and 21.2.0-rc.1, as well as @nguniversal/common and @nguniversal/express-engine at version 16.2.0 and below (no patch available for these legacy packages). It carries a CVSS v4.0 base score of 9.2 (Critical) (Github Advisory, Angular Advisory).

The root cause (CWE-918) is Angular SSR's internal URL reconstruction logic unconditionally trusting user-controlled HTTP headers — specifically Host, X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Port — to determine the application's base origin during server-side rendering, without any validation (Angular Advisory). Three specific validation gaps existed: (1) Host and X-Forwarded-Host were not checked against a trusted allowlist, allowing redefinition of the application base to an arbitrary domain; (2) X-Forwarded-Host was not sanitized for path separators or special characters; and (3) X-Forwarded-Port was not verified as numeric, enabling malformed URI construction (Fix PR). The vulnerability manifests in two ways: implicit relative URL resolution, where Angular's HttpClient resolves relative URLs against the attacker-controlled base origin, and explicit manual construction, where developers using the REQUEST object to build URLs inherit the unsanitized header values (Github Advisory). Exploitation requires no authentication and no user interaction, but does require the attacker to be able to send HTTP requests with manipulated headers to the SSR server without strict upstream proxy validation.

Successful exploitation enables arbitrary internal request steering from the Angular SSR server, which typically has broader network access than external clients. Primary impacts include credential exfiltration (stealing Authorization headers or session cookies by redirecting server-side requests to an attacker-controlled host), internal network probing (accessing internal services, databases, or cloud metadata endpoints such as 169.254.169.254), and confidentiality breaches of data processed in the server-side rendering context (Angular Advisory). Availability is not directly impacted, but the confidentiality impact extends to both the vulnerable system and subsequent internal systems reachable from the SSR server.

As of the time of disclosure, there is no public proof-of-concept exploit code and no confirmed evidence of in-the-wild exploitation (Github Advisory). The vulnerability was reported through the Google OSS Vulnerability Reward Program by researcher Yenya030, with multiple independent reports submitted for the same issue (Fix PR). The EPSS score is approximately 0.061% (19th percentile), indicating a low near-term exploitation probability. The CVE is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Despite the lack of active exploitation, the low attack complexity and absence of authentication requirements make this a high-priority patching target for exposed Angular SSR deployments.

1. Reconnaissance: Identify internet-facing Angular SSR applications (e.g., via Shodan, Censys, or manual inspection of HTTP responses for Angular SSR fingerprints) running vulnerable versions of @angular/ssr prior to 19.2.21, 20.3.17, 21.1.5, or 21.2.0-rc.1.
2. Verify header pass-through: Confirm that the target's front-facing proxy (CDN, load balancer) does not strip or validate Host, X-Forwarded-Host, X-Forwarded-Port, or X-Forwarded-Proto headers before they reach the Node.js SSR server.
3. Craft malicious request: Send an HTTP request to the Angular SSR application with a manipulated X-Forwarded-Host header pointing to an attacker-controlled server (e.g., X-Forwarded-Host: attacker.example.com) or an internal service (e.g., X-Forwarded-Host: 169.254.169.254).
4. Trigger relative URL resolution: If the application uses HttpClient with relative URLs during SSR, the framework will resolve those URLs against the attacker-supplied base origin, causing the server to issue requests to the attacker-controlled or internal destination.
5. Capture exfiltrated data: Monitor the attacker-controlled server for incoming requests containing Authorization headers, session tokens, or internal API responses forwarded by the Angular SSR server.
6. Internal network probing: Iterate over internal IP ranges or known cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/) via the X-Forwarded-Host header to enumerate internal services and extract sensitive configuration data (Angular Advisory, Fix PR).

• Network: Outbound HTTP/HTTPS requests from the Angular SSR Node.js process to unexpected external IP addresses or domains not in the application's normal API allowlist; outbound requests to cloud metadata endpoints (e.g., 169.254.169.254, fd00:ec2::254) originating from the SSR server.
• Network: Inbound HTTP requests to the SSR application containing unusual or non-standard Host, X-Forwarded-Host, X-Forwarded-Port, or X-Forwarded-Proto header values (e.g., external domains, non-numeric port values, or headers containing path separators like /).
• Logs: Angular SSR server logs showing requests with X-Forwarded-Host values that differ from the application's configured domain; Node.js process logs indicating fallback to Client-Side Rendering (CSR) due to header validation failures (present in patched versions).
• Logs: Web server or proxy access logs showing repeated requests with manipulated forwarding headers from a single source IP, potentially indicating automated scanning or exploitation attempts.
• Process: Unexpected outbound network connections initiated by the Node.js SSR process to internal RFC-1918 address ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata services.

Upgrade @angular/ssr to one of the patched versions: 19.2.21, 20.3.17, 21.1.5, or 21.2.0-rc.1. After upgrading, configure the allowedHosts option in angular.json (for AngularAppEngine users) or pass it directly to CommonEngine/AngularNodeAppEngine to specify trusted hostnames; the NG_ALLOWED_HOSTS environment variable (comma-separated) is also supported (Fix PR). For @nguniversal/common and @nguniversal/express-engine (≤16.2.0), no patch is available — migrate to @angular/ssr or apply the middleware workaround below. If immediate upgrade is not possible, implement a validation middleware in server.ts:

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];
    if (!ALLOWED_HOSTS.has(hostname) && hostname !== 'localhost') {
      return res.status(400).send('Invalid Hostname');
    }
  }
  if (portHeader && !/^\d+$/.test(portHeader)) {
    return res.status(400).send('Invalid Port');
  }
  next();
});

Additionally, avoid using req.headers for URL construction — use hardcoded trusted base API paths instead (Angular Advisory).

The vulnerability received broad coverage from security news outlets including SecurityOnline, CyberSecurityNews, GBHackers, and The Hacker News (weekly recap), reflecting significant community interest given Angular's widespread use in enterprise web applications (SecurityOnline, CyberSecurityNews). HeroDevs published a detailed technical blog post analyzing the vulnerability and its implications for end-of-life Angular versions, noting that applications on Angular 18 and below using @nguniversal have no patch path (HeroDevs Blog). The Angular team's fix PR discussion revealed that multiple independent researchers reported the same issue via Google's OSS VRP, and the fix was carefully reviewed by multiple Angular core team members before merging (Fix PR). Security Boulevard and Indusface also published analysis pieces urging immediate patching for Angular SSR deployments (Security Boulevard).