CVE-2026-50168: Angular SSR SSRF Allowlist Bypass via URL Parser Differential in @angular/platform-server

CVE-2026-50168  is a High-severity Server-Side Request Forgery (SSRF) vulnerability in @angular/platform-server that bypasses the allowedHosts protection introduced to remediate the prior Angular SSR SSRF vulnerability. If your team applied the hostname allowlist fix from CVE-2026-46417 and considered that SSRF class of risk resolved, the new vulnerability from CVE-2026-50168  reopens it through a different mechanism. The allowlist is still there. The bypass is in how the URL is evaluated before the allowlist is consulted.

The vulnerability affects @angular/platform-server across Angular 19.x through 22.x pre-release, and all versions at or below 18.2.14. Patches are available for Angular 19 through 22 pre-release. Angular 18 and all earlier versions have no upstream patch. NES for Angular remediates CVE-2026-50168 for all supported end-of-life(EOL) versions as a drop-in replacement.

The GitHub Security Advisory is GHSA-xrxm-cp7j-8xf6.

‍

What Is CVE-2026-50168?

CVE-2026-50168 is an SSRF allowlist bypass in @angular/platform-server caused by a parser differential between two URL parsing implementations used at different stages of the SSR request pipeline.

When CVE-2026-46417 was fixed, Angular's SSR rendering API introduced an allowedHosts validation step. Before initializing the server-side DOM, the engine validates the request URL's hostname against a developer-configured list of trusted hosts. If the hostname is not on the list, the request is rejected.

CVE-2026-50168  breaks that validation through a malformed URL. When a request URL contains a double-port structure, for example http://evil.com:80:80/path, Node's strict WHATWG URL.canParse() returns false. Because the URL fails to parse, the allowlist check is skipped entirely rather than triggering a rejection. The rendering engine then proceeds to the next step, where the Domino DOM emulator parses the same URL using its own lenient parser. Domino successfully resolves the malformed URL, extracts http://evil.com:80 as the origin, and adopts it as the application's current hostname. From that point, every relative HttpClient request made during the server-side render resolves against the attacker-controlled origin.

The attack produces no visible application error. The SSR render completes normally from the server's perspective. The only observable indication is that backend API calls are directed to the wrong host.

Severity: High (sourced from the Angular security advisory, GHSA-xrxm-cp7j-8xf6). NVD enrichment, including a CVSS vector, may be pending at time of reading.

‍

Why CVE-2026-50168 Is Particularly Consequential

Most SSRF vulnerabilities exist because a protection was never in place. CVE-2026-50168  is different: the protection was explicitly added, and this vulnerability bypasses it. That distinction matters for two reasons.

First, teams that responded to CVE-2026-46417 by configuring allowedHosts and upgrading to a patched version may have closed that ticket and moved on. They patched the vulnerability. Their scanner cleared the finding. CVE-2026-50168  means the same class of attack is available again through a path that the fix did not cover, and a scanner that flagged CVE-2026-46417 will now flag CVE-2026-50168  separately. The finding is back.

Second, teams that applied the allowedHosts allowlist as a workaround for older EOL versions, without upgrading the package, are in a worse position than they may realize. The allowlist cannot be trusted to protect against this attack. An allowedHosts configuration that appears to enforce strict host validation can be bypassed by any request containing a double-port URL structure. The only effective remediation is a patched package version.

The practical impact of a successful exploit is the same as CVE-2026-46417: server-side HTTP requests, including those carrying session cookies, authorization tokens, and internal credentials, are redirected to an attacker-controlled server. Cloud metadata endpoints such as the AWS IMDS at 169.254.169.254 and the GCP metadata service are reachable from most SSR servers by design. An attacker who can redirect server-side requests to those endpoints can retrieve instance credentials, service account tokens, and environment configuration without requiring any existing access to the application.

Additionally, because the attacker-controlled server can return arbitrary response payloads, content injected into the SSR render can propagate into the HTML served to end users, creating a response poisoning surface on top of the credential exposure risk.

For organizations subject to SOC 2, PCI DSS, or ISO 27001, an open SSRF finding on a production SSR deployment is a material control gap. Internal remediation SLAs for High-severity vulnerabilities typically run 30 to 90 days. Dependency scanners including Snyk and Tenable will flag CVE-2026-50168 against any @angular/platform-server version in the affected ranges, independently of whether CVE-2026-46417 was previously addressed.

‍

Who Is Affected

CVE-2026-50168 affects applications using @angular/platform-server for server-side rendering where four conditions are all true: SSR is active, the SSR handler passes request URLs derived from client input to renderApplication or renderModule, the application makes relative HttpClient requests during server-side rendering, and the allowedHosts configuration option is in use. Angular applications running entirely in the browser without SSR are not affected.

Note that the fourth condition, using allowedHosts, is specifically what this vulnerability bypasses. Applications that were not using allowedHosts remain vulnerable to CVE-2026-46417. Applications that were using allowedHosts remain vulnerable to CVE-2026-50168. The two advisories represent distinct attack paths against the same package.

Angular 19 reached end-of-life on May 19, 2026. The upstream team published 19.2.23 as part of this advisory. 

‍

Why Upgrading Is Not a Short-Term Fix for EOL Versions

For teams on supported Angular versions, the path is a patch update. The patched packages are available now via npm and require no additional configuration changes beyond the version bump and ensuring allowedHosts remains configured.

For teams on Angular 18 or earlier, there is no upstream fix available and no timeline under which one will be provided. The Angular team's EOL policy is clear: security patches are not issued for versions past end-of-life. That policy does not change based on the severity of the vulnerability or the recency of the EOL date.

A major Angular version upgrade from 17 or 18 to 20 or 21 resolves both CVE-2026-46417 and CVE-2026-50168  and it is the right long-term answer. It is not, however, a fast answer for most production SSR applications. SSR applications in particular carry migration complexity that pure client-side Angular apps do not: the server entry point, the Express or Node integration, the hydration configuration, and the build pipeline all intersect with major Angular version changes in ways that require deliberate, tested work. That is not a complaint about Angular's upgrade tooling. It is an accurate description of how production migrations actually go.

In the interim, the CVE-2026-50168  finding is real, it is scannable, it is auditable, and it is exploitable. Engineering teams planning a migration do not stop running scanner jobs during that planning period.

‍

Technical Breakdown

The vulnerability is a parser differential: two URL parsers are used at different stages of the same pipeline, and they disagree on whether a malformed URL is valid.

Stage one is allowlist validation. When a request URL is passed to renderApplication or renderModule, Angular extracts the hostname from that URL and checks it against the allowedHosts list. To extract the hostname, the engine first calls Node's WHATWG URL.canParse(url). The WHATWG parser is strict: a URL like http://evil.com:80:80/path contains two colons after the host, which is not a valid port structure. URL.canParse() returns false. The hostname extraction fails. Because the URL cannot be parsed, the allowlist check is skipped. The code path that would reject an unauthorized hostname is never reached.

Stage two is DOM initialization. The same malformed URL is then passed to Domino, the server-side DOM emulator used by @angular/platform-server. Domino's URL parser is lenient. It does not enforce strict port syntax. Presented with http://evil.com:80:80/path, Domino parses it successfully, discards the second :80, and resolves the origin as http://evil.com:80. That origin is adopted by ServerPlatformLocation as the application's current hostname.

Stage three is request execution. The SSR HTTP interceptor, relativeUrlsTransformerInterceptorFn, rewrites all relative HttpClient request paths against the adopted base URL. A call to /api/user becomes http://evil.com:80/api/user. The request leaves the server carrying the application's credentials, headers, and network-level trust, directed at the attacker's infrastructure.

The fix in 19.2.23, 20.3.22, 21.2.15, and 22.0.0-rc.2 reconciles the two parsing stages. The allowlist validation path no longer silently passes on URLs that URL.canParse() rejects. A malformed URL that cannot be parsed by the strict parser is treated as an unauthorized host, not as an unchecked URL.

‍

The HeroDevs Solution

NES for Angular remediates CVE-2026-50168  across all supported EOL versions, delivered as a drop-in replacement for the @angular/platform-server package. For teams on Angular 18 or earlier, this resolves both CVE-2026-50168 and CVE-2026-46417 in a single package update, with no server entry point changes, no build configuration changes, and no application code changes required.

The implementation path is the same as any NES Angular update: configure the NES registry token in your project, update the @angular/platform-server reference in your package.json to the corresponding NES version, reinstall and rebuild. The patched NES package is a direct replacement for the EOL OSS package at the same version line. Your Express integration, hydration setup, and deployment pipeline are unchanged.

NES packages are recognized by Snyk, Tenable, and other major dependency scanners. Letters of attestation are available for auditors or customers requiring documented remediation evidence. HeroDevs is a CVE Numbering Authority (CNA) and maintains a public vulnerability directory for all CVEs affecting EOL Angular versions.

NES closes the gap between an open scanner finding and a completed migration, without requiring your engineering team to pause revenue work and execute an unplanned Angular major version upgrade.

‍

Taking Action

Angular 21.x SSR: Update @angular/platform-server to 21.2.15. Confirm that allowedHosts is configured in your render entry point with your application's actual trusted hostnames.

Angular 20.x SSR: Update to 20.3.22. Same allowedHosts configuration guidance applies.

Angular 19.x SSR: Update to 19.2.23. Angular 19 is EOL as of May 2026. Plan your migration to Angular 20 or 21, or engage NES for Angular 19 to receive continued security coverage on your current version.

Angular 18.x and earlier SSR: No upstream patch exists for CVE-2026-50168. The allowedHosts configuration does not protect against this bypass. Contact HeroDevs to access the remediated NES package for your Angular version.

For all versions: if you patched CVE-2026-46417 and have not yet applied the CVE-2026-50168 fix, your allowedHosts configuration is insufficient as a standalone protection. Both fixes are required. The patches for CVE-2026-50168 include the CVE-2026-46417 fix, so upgrading to any of the patched versions above addresses both advisories simultaneously.

Learn more about NES for Angular, or visit the HeroDevs vulnerability directory for the full list of CVEs and advisories affecting EOL Angular versions.