GHSA-W739-GVWX-GRC3

Vulnerability from github – Published: 2026-10-20 14:35 – Updated: 2026-10-20 14:35
VLAI
Summary
@angular/platform-server: Open Redirect via Protocol-Relative URLs in Server-Side Rendering (SSR)
Details

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 # 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.
Severity
5.1 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0"
            },
            {
              "fixed": "21.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0"
            },
            {
              "fixed": "20.3.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "19.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-111754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-20T14:35:49Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "An open redirect vulnerability was identified in `@angular/platform-server` when Server-Side Rendering (SSR) is enabled.\n\nWhen 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.\n\nWhen 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(\u0027//\u0027)` check. Subsequent WHATWG URL parsing resolved the dot-segments and resulted in a `pathname` starting with `//` (`//evil.test`).\n\nConsequently, `ServerPlatformLocation` stored `pathname = \u0027//evil.test\u0027`. When `@angular/ssr` detected a mismatch between the rendered URL and the router\u0027s 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.\n\n### Impact\n\nSuccessful exploitation allows an unauthenticated remote attacker to craft URLs that trick Angular SSR into redirecting users to an arbitrary external domain.\n\n* **Bypasses Application-Level Guards:** Common application-level validation routines (such as checking `!returnUrl.startsWith(\u0027//\u0027)` before invoking `router.navigateByUrl`) accept `/.//evil.test` or `/.;/(//evil.test)` as a safe relative path, allowing attackers to bypass redirect allowlists.\n* **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.\n\n### Attack Preconditions \u0026 Vulnerable Configurations\n\nAn application is affected if the following conditions are met:\n\n* **SSR Enabled:** The application runs in a Server-Side Rendering environment using `@angular/platform-server` and `@angular/ssr`.\n* **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`).\n* **Reverse Proxy Passthrough:** Upstream reverse proxies (Nginx, Cloudflare, ALB) pass semicolons (`;`) or dot-segments without stripping or normalizing them.\n\n#### Exploit Payload Example\n\nAn attacker sends a request targeting a route with parameters and child segments:\n\n```http\nGET /.;/(//evil.test) HTTP/1.1\nHost: example.com\n```\n\n**Response:**\n```http\nHTTP/1.1 302 Found\nLocation: //evil.test\n```\n\nThe client browser resolves `//evil.test` protocol-relatively and redirects the user away from `example.com` to `evil.test`.\n\n### Patches\n\nThe 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`.\n\n* `22.2.1`\n* `21.2.25`\n* `20.3.33`\n\n### Workarounds \u0026 Mitigations\n\nIf you cannot immediately upgrade to a patched version, apply one of the following mitigations at your edge reverse proxy or WAF:\n\n1. **Reject Paths with Dot-Segments Followed by Slashes:**\n   Configure your reverse proxy (e.g., Nginx, Cloudflare, AWS WAF) to block requests containing `/.//`, `/..//`, or `/.;/`:\n   ```nginx\n   # Nginx example: reject suspicious path normalization sequences\n   if ($request_uri ~* \"(\\n/\\.\\/|\\/\\.\\;)\") {\n       return 400;\n   }\n   ```\n2. **Sanitize Redirect Headers:**\n   Ensure edge proxies or API gateways rewrite or disallow protocol-relative (`//`) `Location` response headers originating from the SSR upstream.",
  "id": "GHSA-w739-gvwx-grc3",
  "modified": "2026-10-20T14:35:49Z",
  "published": "2026-10-20T14:35:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/security/advisories/GHSA-w739-gvwx-grc3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/71077"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/71078"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/pull/71079"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/commit/450af9c813c7660b9bd91e5635f705ee3ed7b32a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/commit/83944fc8c50e86be90e8ec4184cd15002b5af262"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/commit/928dcfd2582152655b5559509d057bf6a5a19521"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/commit/d7d81e189d227108c3b9d39178dbb7389f6f970d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/angular/angular"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/releases/tag/v20.3.33"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/releases/tag/v21.2.25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/releases/tag/v22.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@angular/platform-server: Open Redirect via Protocol-Relative URLs in Server-Side Rendering (SSR)"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.