Angular @angular/platform-server SSRF and cross-origin credential disclosure through URL resolution

Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.30, 21.2.22, and 22.1.4, Angular Server-Side Rendering in @angular/platform-server processes user-controlled resource or request URLs through HttpClient after application code validates them with WHATWG URL parsing. The resolveUrl and parseUrl utilities called String.prototype.trim(), which removed leading Unicode whitespace such as U+00A0 or U+FEFF after the input passed a same-origin check, converting a relative path into a protocol-relative attacker-controlled URL. In affected applications that attach sensitive server-side credentials such as Authorization headers to approved requests, relativeUrlsTransformerInterceptorFn then dispatched the request to the attacker-controlled origin, causing SSRF and credential disclosure. This issue is fixed in versions 20.3.30, 21.2.22, and 22.1.4.

The affected component is Angular Server-Side Rendering in @angular/platform-server with these confirmed ranges:

• <= 19.2.25: affected. The CNA advisory marks this branch as end of support/LTS expired and states that it will not be patched.
• >= 20.0.0, < 20.3.30: affected; the confirmed fixed release is 20.3.30.
• >= 21.0.0, < 21.2.22: affected; the confirmed fixed release is 21.2.22.
• >= 22.0.0, < 22.1.4: affected; the confirmed fixed release is 22.1.4.

Versions outside these explicitly documented ranges are not assessed by this entry.

The flaw is in URL resolution within @angular/platform-server, specifically the resolveUrl and parseUrl utilities, and is classified as CWE-918. An application may use WHATWG URL parsing to verify that a user-controlled URL remains on a trusted origin, while Angular's use of String.prototype.trim() removes leading Unicode whitespace such as U+00A0 or U+FEFF. That discrepancy can turn a relative path that passed the same-origin check into a protocol-relative URL for an attacker-controlled origin. During SSR, relativeUrlsTransformerInterceptorFn can then dispatch the request through HttpClient to that origin. Exploitation requires user input to influence a resource or request URL, an application-level same-origin check to run before dispatch, and the approved request to receive sensitive server-side credentials such as an API key, Bearer token, or Authorization header. The application's exact routes and the permissions of any exposed credential are deployment-specific and are not established by the record.

The flaw is network-reachable when an Angular SSR application processes user-controlled URLs through the vulnerable flow. The record describes no required prior authentication and low attack complexity, but the SSR request or equivalent processing path must be triggered. User interaction is passive, meaning a separate victim action is not necessarily required beyond the application processing the request. The CNA advisory documents a public proof of concept for bypassing the same-origin check and redirecting the request to another origin. The supplied evidence does not identify a named campaign or specific in-the-wild exploitation.

• The primary technical outcome is a same-origin validation bypass that enables SSRF from the Angular SSR process to an attacker-controlled origin.
• If the request carries a credential, that credential may be disclosed, after which the attacker may use the credential within the permissions accepted by the destination service.
• Confidentiality loss is direct for any credential sent to the unintended destination. Integrity impact is possible if the credential permits data modification or other state-changing actions, but depends on its permissions.
• The record does not describe arbitrary code execution or a direct availability failure. Client-side Angular applications that do not use SSR and deployments without the documented request and credential flow are outside the confirmed scope.

• An SSR server may be induced to send a request to an origin that the application did not intend to contact, weakening application-level outbound request controls and domain allowlists.
• An Authorization header, API key, Bearer token, or similar server-side credential may be sent to an attacker-controlled origin if it is added after the same-origin check.
• A disclosed credential could provide access to data or permit actions within that credential's authority; any integrity consequence depends on the credential's permissions.
• Not every Angular application is necessarily exposed. The relevant risk is concentrated in SSR deployments with the required URL input, same-origin validation, and server-side credential flow.

1. Upgrade @angular/platform-server to the exact fixed release for the branch in use: 20.3.30 for the 20.x branch, 21.2.22 for the 21.x branch, or 22.1.4 for the 22.x branch.
2. For 19.2.25 or earlier, do not wait for a 19.x fix because the advisory marks that branch as end of support and not patchable. Move to a branch with a listed fix and apply the exact fixed release for that branch.
3. If an upgrade cannot be completed immediately, reject or sanitize leading Unicode whitespace such as U+00A0 and U+FEFF before performing origin checks or passing the URL to HttpClient. Do not rely only on new URL(input, trustedOrigin).origin if another utility may normalize whitespace differently.
4. Review SSR requests that attach server-side credentials. If evidence shows that requests were sent to an unauthorized destination, assess and rotate the related credentials under the applicable incident-response process.
5. Do not treat one confirmed fixed release as coverage for later or parallel branches unless those branches have been separately verified.

1. Inventory deployments that enable Angular Server-Side Rendering and record the installed @angular/platform-server version.
2. Compare each version with the affected ranges in affected_summary, rather than checking only the package name.
3. Review code paths where request or resource input reaches HttpClient, especially flows using resolveUrl, parseUrl, or relativeUrlsTransformerInterceptorFn.
4. Identify interceptors or request layers that add Authorization, API keys, Bearer tokens, or other server-side credentials after same-origin validation.
5. If outbound SSR telemetry is available, look for requests whose destination differs from the approved origin and for paths beginning with Unicode whitespace such as U+00A0 or U+FEFF. This is precautionary monitoring based on the failure mechanism, not a published IOC.
6. Add regression tests for leading Unicode whitespace to verify that such inputs remain same-origin relative paths. The absence of suspicious logs does not prove that a deployment is safe.