CVE-2026-88056

Overview

Angular is a TypeScript-based web development platform for building scalable single-page and server-side rendered applications. It provides a modular architecture, powerful dependency injection, and built-in tools for building modern, performant, and maintainable applications across web, mobile, and desktop environments.

A Server-Side Request Forgery (SSRF) vulnerability (CVE-2026-88056) has been identified in Angular's Platform Server, which allows attackers to bypass application-level same-origin checks through Unicode whitespace in URLs and can lead to server-side requests being dispatched to an attacker-controlled origin along with any credentials attached to them.

Per OWASP: In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed.

This issue affects multiple versions of Angular.

‍

Details

Module Info

• Product: Angular
• Affected packages: @angular/platform-server
• Affected versions:
  • >=8.0.0-rc.0 <=19.2.25
  • >=20.0.0 <20.3.30
  • >=21.0.0 <21.2.22
  • >=22.0.0 <22.1.4
• GitHub repository: https://github.com/angular/angular
• Published packages: https://www.npmjs.com/package/@angular/platform-server
• Package manager: npm
• Fixed in:
  • OSS Angular v20.3.30, v21.2.22 and v22.1.4
  • NES for Angular v19.2.30, v18.2.26, v17.3.26, v16.2.26, v15.2.24, v14.3.15, v13.4.17, v12.3.11, v11.2.29, v10.2.21, v9.1.27, v8.2.27

Vulnerability Info

This High-severity vulnerability is found in the @angular/platform-server package in multiple published versions of Angular.

A discrepancy between WHATWG URL parsing and Angular SSR's URL resolution allows attackers to bypass same-origin checks and cause Server-Side Request Forgery (SSRF), potentially leaking sensitive server-side credentials.

When applications validate incoming URLs using the WHATWG URL standard (new URL(input, trustedOrigin)), Unicode whitespace characters such as NO-BREAK SPACE U+00A0 or ZERO WIDTH NO-BREAK SPACE U+FEFF are not stripped and are evaluated as part of a same-origin relative path, for example http://trusted-origin/%C2%A0//attacker.example/collect. Consequently, these URLs successfully pass application-level same-origin checks.

However, @angular/platform-server's URL resolution utility (parseUrl) previously executed String.prototype.trim(). Because JavaScript's String.prototype.trim() strips all Unicode whitespace, including U+00A0, the leading non-breaking space was removed, converting the string into a cross-origin protocol-relative URL (//attacker.example/collect). When resolved during server-side rendering, such as in relativeUrlsTransformerInterceptorFn, this caused the HTTP request to be dispatched to the attacker-controlled origin (http://attacker.example/collect), leaking any credentials such as Authorization headers attached by the application for the intended same-origin request.

The vulnerability affects Angular Server-Side Rendering applications where user-controlled input influences resource or request URLs processed by Angular's HttpClient, where an application-level same-origin check is performed before dispatching, and where sensitive server-side credentials such as API keys or Bearer tokens are attached to approved requests. Successful exploitation allows attackers to bypass same-origin validation, triggering Server-Side Request Forgery and leaking sensitive server-side credentials attached to the request.

‍

Mitigation

Angular versions prior to 20 were already End-of-Life when this CVE was published and will not receive any updates to address this issue. For more information see here.

Users of the affected components should apply one of the following mitigations:

• Migrate affected applications to a patched version of Angular.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍

Credits

• Adyej999 (finder)