Executive Summary

This vulnerability is a Server-Side Request Forgery (SSRF) issue in Angular's platform-server package during Server-Side Rendering (SSR). It occurs because the URL parser improperly handles certain URLs, such as protocol-relative URLs (e.g., //evil.com/) or backslash-prefixed URLs (e.g., \evil.com\). The parser normalizes backslashes to forward slashes, causing the application to mistakenly treat the attacker's domain as the local origin.

As a result, relative HTTP client requests or hostname references within the application are redirected to the attacker-controlled server. This misinterpretation can expose internal APIs or metadata services to the attacker.

The vulnerability affects versions of @angular/platform-server prior to 19.2.21, 20.3.19, 21.2.9, and 22.0.0-next.8 and has been patched in these versions.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker to trick your server into treating their domain as a trusted local origin. Consequently, any relative HTTP requests or hostname references made by your application during server-side rendering could be redirected to the attacker-controlled server.

This redirection can lead to exposure of sensitive internal APIs or metadata services, potentially leaking confidential information.

The attack requires no privileges or user interaction and can be executed remotely over the network, making it a high-severity risk with a CVSS score of 8.7.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring incoming HTTP requests to your Angular platform-server that contain suspicious URL patterns such as protocol-relative URLs (e.g., //evil.com/) or backslash-prefixed URLs (e.g., \evil.com\). These requests may indicate attempts to exploit the SSRF vulnerability by tricking the server into treating an attacker-controlled domain as the local origin.

To detect such attempts, you can inspect your web server logs or use network monitoring tools to filter requests with URLs starting with double slashes (//) or backslashes (\). For example, using command-line tools on a Linux server:

• grep -E 'GET \/\/|GET \\' /var/log/nginx/access.log
• grep -E 'GET \/\/|GET \\' /var/log/apache2/access.log

These commands search for GET requests where the URL path starts with // or \ which are indicative of attempts to exploit the vulnerability.

Additionally, you can implement middleware or logging in your Angular server to log and alert on requests with such URL patterns before they reach the Angular rendering functions.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this SSRF vulnerability in Angular platform-server, you should immediately upgrade your Angular platform-server package to one of the patched versions: 19.2.21, 20.3.19, 21.2.9, or 22.0.0-next.8.

If upgrading immediately is not possible, implement middleware in your server to sanitize incoming request URLs before they reach Angular's rendering functions. This middleware should ensure that URLs start with a single forward slash and remove any leading double slashes or backslashes to prevent the URL parser from misinterpreting the origin.

• Sanitize request URLs to start with a single forward slash.
• Remove or reject requests with protocol-relative URLs (//) or backslash-prefixed URLs (\).

These steps prevent the attacker from hijacking the internal state of the application and redirecting relative HttpClient requests or PlatformLocation.hostname references to attacker-controlled servers.

Useful 0 Not Useful 0

Compliance Impact

The Server-Side Request Forgery (SSRF) vulnerability in Angular's platform-server component can lead to exposure of internal APIs or metadata services by redirecting requests to attacker-controlled servers. This exposure of internal data could potentially result in unauthorized access to sensitive information.

Such unauthorized data exposure may impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of personal and sensitive data from unauthorized access or disclosure.

Therefore, if exploited, this vulnerability could lead to violations of data protection requirements under these regulations, emphasizing the importance of applying the available patches and implementing URL sanitization to mitigate the risk.

Useful 0 Not Useful 0