Server-Side Request Forgery in Angular SSR via Malicious URL Resolution

The Angular SSR is a server-rise rendering tool for Angular applications. The vulnerability is a Server-Side Request Forgery (SSRF) flaw within the URL resolution mechanism of Angular's Server-Side Rendering package (@angular/ssr) before 19.2.18, 20.3.6, and 21.0.0-next.8. The function createRequestUrl uses the native URL constructor. When an incoming request path (e.g., originalUrl or url) begins with a double forward slash (//) or backslash (\), the URL constructor treats it as a schema-relative URL. This behavior overrides the security-intended base URL (protocol, host, and port) supplied as the second argument, instead resolving the URL against the scheme of the base URL but adopting the attacker-controlled hostname. This allows an attacker to specify an external domain in the URL path, tricking the Angular SSR environment into setting the page's virtual location (accessible via DOCUMENT or PlatformLocation tokens) to this attacker-controlled domain. Any subsequent relative HTTP requests made during the SSR process (e.g., using HttpClient.get('assets/data.json')) will be incorrectly resolved against the attacker's domain, forcing the server to communicate with an arbitrary external endpoint. This vulnerability is fixed in 19.2.18, 20.3.6, and 21.0.0-next.8.

The normalized record identifies vendor angular and product angular-cli; the vendor advisory identifies the vulnerable package as @angular/ssr.

• The branch >=19.0.0-next.0, <19.2.18 is affected. The corresponding patched release is 19.2.18.
• The branch >=20.0.0-next.0, <20.3.6 is affected. The corresponding patched release is 20.3.6.
• The branch >=21.0.0-next.0, <21.0.0-next.8 is affected. The corresponding patched release is 21.0.0-next.8.

These boundaries apply to @angular/ssr; the status of other branches is not inferred beyond the available evidence.

The flaw is in URL construction within the @angular/ssr package, specifically the createRequestUrl function. The function uses the native URL constructor with the request protocol, hostname, and port as the base URL, but a value from originalUrl or url beginning with // or a backslash is interpreted as a schema-relative URL. This allows an attacker-controlled hostname to override the hostname in the base URL while retaining its scheme. Angular SSR then sets the page virtual location, accessible through the DOCUMENT or PlatformLocation tokens, to the attacker-selected domain. Relative HTTP requests made during rendering, such as HttpClient.get('assets/data.json'), can therefore resolve to that domain instead of the intended server. Exploitation requires an exposed Angular SSR application that accepts attacker-controlled request paths and makes relative requests during rendering; the available evidence does not establish which application requests, credentials, or network destinations are reachable in a particular deployment.

The issue is reachable over the network through an Angular SSR endpoint that accepts a crafted request path. The supplied attack metrics state that authentication and user interaction are not required, and that attack complexity is low. Successful exploitation also depends on the application making relative HTTP requests during server-side rendering. The record marks a public exploit as available, but does not identify a specific exploit by name. It does not identify a campaign, victim, or specific exploitation indicator.

Successful exploitation changes the virtual location used by Angular SSR to resolve relative URLs, causing the server to send HTTP requests to an attacker-controlled hostname. The primary technical consequence is SSRF and possible disclosure of data that the SSR process includes in requests or receives in responses. No account or separate user interaction is required, but the deployment must expose an SSR endpoint and make relative requests during rendering. Access to internal networks, credentials, or privileged resources depends on application configuration and egress policy and is not established by the record. The record does not describe code execution, data modification, or service interruption as direct consequences.

The flaw can cause an SSR server to send requests to an external endpoint chosen by an attacker instead of the destination expected by the application.

• Data available to the SSR process may be exposed if the application includes request or response data in its output, logs, or another processing path.
• The deployment may generate unexpected outbound traffic, DNS lookups, and HTTP connections, complicating egress control and incident analysis.
• The affected data scope depends on the relative requests made during rendering and the deployment's network policy.
• The available evidence does not establish access to internal-only endpoints, use of particular credentials, data modification, or service disruption.

1. Upgrade @angular/ssr to the patched release for the branch in use: 19.2.18 for the 19 branch, 20.3.6 for the 20 branch, or 21.0.0-next.8 for the 21 prerelease branch. Verify that the lockfile, build artifact, and runtime image all contain the patched release.
2. If an upgrade is not immediately possible, add middleware before the Angular SSR handler on the Node.js or Express server to reject or sanitize request paths beginning with //. The protection should also prevent paths from being interpreted as schema-relative URLs, including the backslash forms described in the flaw mechanism.
3. Review reverse proxy and framework adapter behavior to ensure that dangerous paths are not restored or passed unchanged into originalUrl or url after middleware processing.
4. After remediation, verify that the SSR virtual location retains the expected hostname and that relative HTTP requests made during rendering cannot be redirected to a hostname supplied by the request.

1. Inventory Angular applications that use server-side rendering and identify direct or transitive installations of @angular/ssr.
2. Compare package versions in lockfiles, container images, and runtime installations against the affected branches and patched releases listed in affected_summary.
3. Review SSR code for use of DOCUMENT, PlatformLocation, HttpClient, or other mechanisms that create relative HTTP requests during rendering.
4. Review access and proxy logs for request paths beginning with // or a backslash, and review outbound DNS and HTTP telemetry for SSR connections to unexpected external hostnames.
5. Absence of suspicious log entries does not prove that a deployment is safe. The outbound checks are precautionary monitoring, not confirmed indicators for this vulnerability.