Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A Path Traversal vulnerability exists in the prerendered (SSG) page retrieval logic of CommonEngine in @angular/ssr/node (and @angular/ssr in earlier versions). When deployed on Windows, an attacker can craft a request path with backslash directory traversal sequences that causes CommonEngine to serve prerendered pages from sibling output directories. The vulnerability occurs due to how relative URLs and Windows file paths are resolved and validated: 1. A request URL containing a backslash parent traversal segment (e.g., /..\app-admin) is passed to CommonEngine.render({ url }). 2. The engine parses the URL using new URL(url, 'resolve://'). Because resolve:// is a non-special scheme under the WHATWG URL standard, backslashes are not normalized to forward slashes, leaving the pathname unnormalized as /..\app-admin. 3. The engine constructs the candidate file path using join(publicPath, pathname, 'index.html'). On Windows, path.join treats \ as a path delimiter, resolving the parent…
Recommended action: Upgrade to 22.1.7, 21.2.23 or 20.3.36 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
21.2.920.3.2519.2.2522.0.0-next.7· Vendor fix available
Issue
A vulnerability exists in the X-Forwarded-Prefix header processing logic within Angular SSR. The internal validation mechanism fails to properly account for URL-encoded characters, specifically dots (%2e%2e). This allows an attacker to bypass security filters by injecting encoded path traversal sequences that are later decoded and utilized by the application logic. When an Angular SSR application is configured to trust proxy headers and is deployed behind a proxy that forwards the X-Forwarded-Prefix header without prior sanitization, an attacker can provide a payload such as /%2e%2e/evil. The vulnerability manifests in two ways: - Open Redirect: The application processes a redirect (e.g., router redirectTo). The decoded traversal payload manipulates the Location header, forcing the browser to an unintended path or external domain. - Server-Side Request Steering: The manipulated prefix is used as the base path for server-side HttpClient requests. This causes the server to…
Recommended action: Upgrade to 22.0.0-next.7 (pre-release), 21.2.9, 20.3.25 or 19.2.25 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An Open Redirect vulnerability exists in @angular/ssr due to an incomplete fix for CVE-2026-27738. While the original fix successfully blocked multiple leading slashes (e.g., ///), the internal validation logic fails to account for a single backslash (\) bypass. When an Angular SSR application is deployed behind a proxy that passes the X-Forwarded-Prefix header: - An attacker provides a value starting with a single backslash (e.g., \evil.com). - The internal validation failed to flag the single backslash as invalid. - The application prepends a leading forward slash, resulting in a Location header containing /\evil.com. - Modern browsers interpret the /\ sequence as //, treating it as a protocol-relative URL and redirecting the user to the attacker-controlled domain. Furthermore, the response lacks the Vary: X-Forwarded-Prefix header, allowing the malicious redirect to be stored in intermediate caches (Web Cache Poisoning). Impact This vulnerability allows attackers to conduct…
Recommended action: Upgrade to 22.0.0-next.2 (pre-release), 21.2.3 or 20.3.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
21.2.0-rc.121.1.520.3.1719.2.21· Vendor fix available
Issue
An Open Redirect vulnerability exists in the internal URL processing logic in Angular SSR. The logic normalizes URL segments by stripping leading slashes; however, it only removes a single leading slash. When an Angular SSR application is deployed behind a proxy that passes the `X-Forwarded-Prefix` header, an attacker can provide a value starting with three slashes (e.g., `///evil.com`). 1. The application processes a redirect (e.g., from a router `redirectTo` or i18n locale switch). 2. Angular receives `///evil.com` as the prefix. 3. It strips one slash, leaving `//evil.com`. 4. The resulting string is used in the `Location` header. 5. Modern browsers interpret `//` as a protocol-relative URL, redirecting the user from `https://your-app.com` to `https://evil.com`. Impact This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking: - Scale: A single request can poison a high-traffic route, impacting all users until the cache expires. - **SEO…
Recommended action: Upgrade to 21.2.0-rc.1 (pre-release), 21.1.5, 20.3.17 or 19.2.21 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vulnerability is a Server-Side Request Forgery (SSRF) flaw within the URL resolution mechanism of Angular's Server-Side Rendering package (@angular/ssr). 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…
Recommended action: Upgrade to 21.0.0-next.8 (pre-release), 20.3.6 or 19.2.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.