Vulnerability Database

407,382

Total vulnerabilities in the database

CVE-2026-111754 — @angular / platform-server

URL Redirection to Untrusted Site ('Open Redirect')

An open redirect vulnerability was identified in @angular/platform-server when Server-Side Rendering (SSR) is enabled.

When Angular SSR renders an incoming request, URL resolution and platform navigation are managed by ServerPlatformLocation using resolveUrl (or parseUrl in v20). While resolveUrl rejected protocol-relative URLs whose raw string directly started with //, this check ran prior to WHATWG URL normalization.

When a request URL includes a popping dot-segment followed by multiple slashes (such as /.//evil.test or serialized from router route shapes like /.;/(//evil.test)), the input bypassed the initial urlStr.startsWith('//') check. Subsequent WHATWG URL parsing resolved the dot-segments and resulted in a pathname starting with // (//evil.test).

Consequently, ServerPlatformLocation stored pathname = '//evil.test'. When @angular/ssr detected a mismatch between the rendered URL and the router's final location state, it emitted the unnormalized pathname into the HTTP Location response header, producing an HTTP 302 redirect with Location: //evil.test, which browsers resolve as a protocol-relative navigation off-origin.

Impact

Successful exploitation allows an unauthenticated remote attacker to craft URLs that trick Angular SSR into redirecting users to an arbitrary external domain.

  • Bypasses Application-Level Guards: Common application-level validation routines (such as checking !returnUrl.startsWith('//') before invoking router.navigateByUrl) accept /.//evil.test or /.;/(//evil.test) as a safe relative path, allowing attackers to bypass redirect allowlists.
  • Client-side SPAs Unaffected: Pure client-side Angular applications (Single Page Applications without SSR) are not vulnerable, as ServerPlatformLocation is only utilized in server-side execution environments.

Attack Preconditions & Vulnerable Configurations

An application is affected if the following conditions are met:

  • SSR Enabled: The application runs in a Server-Side Rendering environment using @angular/platform-server and @angular/ssr.
  • Parameter Route Shapes: The router contains parameter routes with wildcard or child segments (e.g. /:tenant matching . and serializing secondary outlet groups (//evil.test) to /.//evil.test), or passes user-provided navigation targets (e.g. returnUrl).
  • Reverse Proxy Passthrough: Upstream reverse proxies (Nginx, Cloudflare, ALB) pass semicolons (;) or dot-segments without stripping or normalizing them.

Exploit Payload Example

An attacker sends a request targeting a route with parameters and child segments:

GET /.;/(//evil.test) HTTP/1.1 Host: example.com

Response:

HTTP/1.1 302 Found Location: //evil.test

The client browser resolves //evil.test protocol-relatively and redirects the user away from example.com to evil.test.

Patches

The issue is resolved by updating resolveUrl (and parseUrl in v20) in @angular/platform-server to verify that the normalized URL pathname does not start with // when allowProtocolRelative is false.

  • 22.2.1
  • 21.2.25
  • 20.3.33

Workarounds & Mitigations

If you cannot immediately upgrade to a patched version, apply one of the following mitigations at your edge reverse proxy or WAF:

  1. Reject Paths with Dot-Segments Followed by Slashes: Configure your reverse proxy (e.g., Nginx, Cloudflare, AWS WAF) to block requests containing /.//, /..//, or /.;/: # Nginx example: reject suspicious path normalization sequences if ($request_uri ~* "(\n/\.\/|\/\.\;)") { return 400; }
  2. Sanitize Redirect Headers: Ensure edge proxies or API gateways rewrite or disallow protocol-relative (//) Location response headers originating from the SSR upstream.

No technical information available.

CWEs:

Is CVE-2026-111754 exposed on your perimeter?

A vulnerability database tells you what is broken. Attack surface management tells you where it is running: it discovers your internet-facing assets and flags the ones affected by issues like this one.

What is attack surface management? →

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.