CVE-2026-88056

What it actually does

Angular Server-Side Rendering in @angular/platform-server mishandles user-controlled resource or request URLs. After application code performs a WHATWG same-origin check, resolveUrl and parseUrl call String.prototype.trim(), which strips leading Unicode whitespace (including U+00A0 and U+FEFF). That transform can turn an apparently relative, same-origin path into a protocol-relative URL. HttpClient then issues the request to an attacker-controlled origin. When relativeUrlsTransformerInterceptorFn attaches server-side credentials such as Authorization headers to approved requests, those secrets are sent off-origin, yielding SSRF and credential disclosure.

Why it matters to the business

Public exploit code is available for a remotely reachable, high-severity SSRF and secret-leak issue in a widely used web framework. Unpatched SSR apps can expose backend tokens, session material, and internal network reachability, enabling account takeover, data theft, and follow-on compromise of internal APIs. The issue has been public for several weeks; delay in upgrading 20.x, 21.x, or 22.x SSR deployments increases the chance of credential theft and unauthorized internal access.

How an attack unfolds

An unauthenticated attacker supplies a resource or request URL that still passes the application's WHATWG same-origin check because leading Unicode whitespace is not treated as changing origin. After validation, Angular trims that whitespace and reinterprets the value as a protocol-relative URL pointing at an origin the attacker controls. The SSR HttpClient, including interceptors that attach server-side Authorization or other sensitive headers to supposedly approved relative requests, then fetches that attacker origin. The attacker observes the outbound request, captures the forwarded credentials, and can use SSRF to probe or invoke internal services reachable from the render node.

How to fix it

Upgrade @angular/platform-server (and matching Angular packages) to 20.3.30, 21.2.22, or 22.1.4 or later. Until the upgrade is complete, do not attach server-side credentials to HttpClient requests whose URLs are influenced by user input; pin allowed hosts with an allowlist after normalization that accounts for Unicode whitespace; disable or tightly restrict SSR fetches to untrusted URLs; and block protocol-relative and unexpected-scheme URLs at the application boundary. Rebuild and redeploy SSR bundles so the patched platform-server code is what actually runs.

How to confirm the fix worked

Confirm installed @angular/core and @angular/platform-server versions are at least 20.3.30 (20.x), 21.2.22 (21.x), or 22.1.4 (22.x) in lockfiles and production images. Review SSR interceptors for credential attachment on user-influenced URLs. In a staging SSR environment, submit previously accepted relative URLs that include leading Unicode whitespace and verify they are no longer rewritten into protocol-relative off-origin requests and that Authorization headers never leave the approved origin. Confirm production Node SSR processes only egress to expected backends.

Typical attack path

1. Identify an Angular SSR application that fetches user-influenced resource or request URLs through HttpClient and attaches server-side credentials to approved relative requests.
2. Submit a URL that remains same-origin under WHATWG parsing but begins with Unicode whitespace such as NO-BREAK SPACE or BOM so that later trim() changes its meaning.
3. Wait for platform-server resolveUrl/parseUrl to trim the value, converting a relative path into a protocol-relative URL under attacker control.
4. Cause SSR rendering or a data fetch so HttpClient and relativeUrlsTransformerInterceptorFn dispatch the request, including Authorization or other secrets, to the attacker origin.
5. Capture disclosed credentials and optionally reuse the SSRF path to reach internal HTTP services from the render host.

How to detect it

Assume possible prior abuse because public exploit material exists. Review Node.js SSR, reverse-proxy, WAF, and egress-proxy logs from before the patch for user-supplied URLs containing leading Unicode whitespace (NO-BREAK SPACE U+00A0, BOM U+FEFF, and other trim()-stripped whitespace) that later appear as protocol-relative or off-origin fetches. Look for HttpClient/SSR worker processes making unexpected outbound HTTP(S) to internet hosts while carrying Authorization, Cookie, or API-key headers normally reserved for first-party backends. Correlate render-request IDs with sudden calls to unknown hosts, 401/403 from internal services initiated by the SSR node, and credential use from unfamiliar IP addresses after the window of exposure. On disk, inspect pre-patch @angular/platform-server builds still containing the trim()-based resolveUrl/parseUrl path.

• U+00A0 (NO-BREAK SPACE) as leading whitespace in SSR resource or request URLs
• U+FEFF (BOM/ZERO WIDTH NO-BREAK SPACE) as leading whitespace in SSR resource or request URLs
• protocol-relative URLs (//attacker-host/...) originating from Angular SSR HttpClient after URL trim
• Node SSR / @angular/platform-server outbound HTTP with Authorization headers to unexpected external hosts
• relativeUrlsTransformerInterceptorFn dispatching off-origin requests from SSR
• String.prototype.trim applied to URLs after WHATWG same-origin checks in platform-server resolveUrl/parseUrl
• SSR worker egress to non-allowlisted origins coinciding with user-controlled resource URL parameters

What your security team should do

• Patch Angular SSR to 20.3.30, 21.2.22, or 22.1.4 immediately; exploit code is already available.
• Inventory all apps using @angular/platform-server and HttpClient interceptors that attach Authorization or other secrets to relative URLs.
• Until patched, deny user-controlled URLs in SSR fetches and stop attaching server credentials to those requests.
• Hunt SSR and reverse-proxy logs for Unicode whitespace in URLs and for unexpected outbound requests from render nodes carrying auth headers.
• Rotate any tokens, API keys, or session secrets that SSR processes may have attached to outbound HttpClient requests.
• Add regression tests that Unicode-whitespace and protocol-relative URLs cannot pass origin checks after trim/normalization.