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
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 22.2.1, 21.2.25 or 20.3.33 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.
A Denial of Service (DoS) vulnerability exists in @angular/platform-server's DOM emulation parser (domino). When processing untrusted user input containing an incomplete DOCTYPE declaration ending with whitespace before EOF (such as <!DOCTYPE html ), the HTML parser enters an infinite synchronous loop, pegging CPU utilization at 100% and completely freezing the Node.js server process. Technical Description In Angular Server-Side Rendering (SSR), @angular/platform-server uses domino to parse and sanitize HTML bound through template bindings (such as [innerHTML]) or manipulated via DOM APIs. In Domino's HTML parser (lib/HTMLParser.js), tokenizer states that specify fixed lookahead—such as afterdoctypenamestate (lookahead = 6)—rely on the state handler function to explicitly advance the character index pointer (nextchar). While branches for whitespace, , and keyword matching advance nextchar, the EOF branch (case -1: // EOF) emitted doctype and EOF tokens without advancing nextchar or…
Recommended action: Upgrade to 22.1.6, 21.2.23 or 20.3.31 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.
An XSS vulnerability exists in @angular/platform-server during server-side rendering (SSR) HTML serialization of ProcessingInstruction DOM nodes (<?target data?, nodeType === 7) when nested inside fallback raw-content elements (<noscript, <iframe, <noembed, <noframes). While processing instruction data escaped to >, it did not check for or escape matching closing tags of ancestor fallback elements (e.g., </noscript). When rendered in a browser with scripting enabled, an unescaped closing tag sequence in a processing instruction prematurely closes the fallback raw-content tag and causes subsequent sibling elements to execute as live HTML. Technical Description In HTML5 parsing, fallback raw-content elements (<noscript, <iframe, <noembed, <noframes) place the browser's HTML tokenizer into RAWTEXT mode. In RAWTEXT mode, processing instruction tokens (<?...?) are treated as literal raw text rather than bogus comments, and the parser ignores or ?. The only token sequence that…
Recommended action: Upgrade to 22.1.4, 21.2.22 or 20.3.30 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.
An XSS vulnerability exists in @angular/platform-server during server-side rendering (SSR) HTML serialization when traversing ancestor tags across <template element boundaries. When an application renders untrusted user input within raw-text tags (<xmp, <style, <script), comments, or text nodes inside a <template that is nested within a fallback raw-content element (<noscript, <iframe, <noembed, <noframes), matching closing tags (e.g., </noscript) are not escaped during HTML serialization. When rendered in a browser, this unescaped closing tag prematurely terminates the fallback container and executes trailing markup as active DOM elements. Technical Description In HTML5 parsing, fallback raw-content elements (<noscript, <iframe, <noembed, <noframes) place the browser's tokenizer into RAWTEXT mode. In this mode, inner content is parsed as literal text until an end tag matching the container tag name (e.g., </noscript) is encountered. To prevent XSS breakout vectors during SSR…
Recommended action: Upgrade to 22.1.4, 21.2.22 or 20.3.30 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.
A discrepancy between WHATWG URL parsing and Angular SSR's URL resolution allows attackers to bypass same-origin checks and cause Server-Side Request Forgery (SSRF), potentially leaking sensitive server-side credentials. Technical Description When applications validate incoming URLs using the WHATWG URL standard (new URL(input, trustedOrigin)), Unicode whitespace characters (such as NO-BREAK SPACE U+00A0 or ZERO WIDTH NO-BREAK SPACE U+FEFF) are not stripped and are evaluated as part of a same-origin relative path (e.g. http://trusted-origin/%C2%A0//attacker.example/collect). Consequently, these URLs successfully pass application-level same-origin checks. However, @angular/platform-server's URL resolution utility (resolveUrl / parseUrl) previously executed String.prototype.trim(). Because JavaScript's String.prototype.trim() strips all Unicode whitespace (including U+00A0), the leading non-breaking space was removed, converting the string into a cross-origin protocol-relative…
Recommended action: Upgrade to 22.1.4, 21.2.22 or 20.3.30 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.
A Cross-Site Scripting (XSS) vulnerability exists in @angular/platform-server's DOM emulation dependency (domino) when serializing the content of fallback raw-content elements (<iframe, <noembed, <noframes, and <noscript). When rendering dynamic text content inside fallback raw-content elements via template bindings, the template engine expects the browser to render the content safely. Under Server-Side Rendering (SSR), domino is configured with scripting enabled, meaning these elements are treated as raw-text elements. However, domino's serializer previously did not escape text nodes within fallback raw-content elements (<iframe, <noembed, <noframes, <noscript) during DOM serialization. As a result, any occurrence of closing tags in the bound dynamic text was not escaped. The unescaped closing tag could be serialized directly into the output HTML. When parsed by a browser or re-parsed during SSR post-processing without preserving raw-content parser state, an injected closing tag…
Recommended action: Upgrade to 22.0.7, 21.2.19 or 20.3.27 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.
A Cross-Site Scripting (XSS) vulnerability exists in @angular/platform-server's DOM emulation dependency (domino) when serializing the content of <noscript elements. When rendering dynamic text content inside a <noscript element via template bindings (such as {{ value }} or [textContent]), the template engine expects the browser to render the content safely. Under Server-Side Rendering (SSR), domino is configured with scripting enabled, meaning <noscript is treated as a raw-text element. However, domino's serializer completely omitted <noscript from the list of raw-text elements requiring closing-tag escaping during DOM serialization. As a result, any occurrence of </noscript in the bound dynamic text was never escaped under any circumstances. The unescaped closing tag was serialized directly into the output HTML (e.g. <noscript</noscript<scriptalert(1)</script</noscript). When parsed by a browser, it closes the <noscript block early, allowing the injected <script block to execute in…
Recommended action: Upgrade to 22.0.0-rc.2 (pre-release), 21.2.16, 20.3.24 or 19.2.25 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.
A Cross-Site Scripting (XSS) vulnerability exists in @angular/platform-server's DOM emulation dependency (domino) when serializing the content of raw-text elements (such as <script, <style, and <iframe). domino supports escaping raw-text elements during serialization to prevent closing-tag breakout. However, a Unicode index alignment bug existed in this escaping logic. In JavaScript, string lengths and character indices are calculated based on UTF-16 code units (where astral characters—such as emojis—occupy 2 code units / 4 bytes). If the bound dynamic text contained astral Unicode characters before the closing tag (e.g. </script, </style, or </iframe), the index offset calculation in domino's replacement logic shifted. This misalignment caused domino to fail to replace or escape the closing tag, leaving it raw and unescaped in the output HTML. An attacker who controls the dynamic text can supply a payload containing both an astral Unicode character and a closing tag (e.g.,…
Recommended action: Upgrade to 22.0.0-rc.2 (pre-release), 21.2.16, 20.3.24 or 19.2.25 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.
An issue in the @angular/platform-server package allows remote attackers to bypass host allowlist constraints and direct server-side outgoing requests to arbitrary external endpoints. This occurs due to a parser differential between the strict WHATWG URL parser used for allowlist validation and the lenient Domino URL parser used to initialize the server emulated DOM. When a server-side request contains a malformed URL with a double port structure (e.g., http://evil.com:80:80/path), Node's strict URL.canParse(url) logic returns false and skips host check validation entirely. However, the same malformed URL is later accepted and parsed leniently by Domino's internal parser, which resolves the origin to http://evil.com:80. The Angular SSR HTTP request interceptor (relativeUrlsTransformerInterceptorFn) then resolves all relative backend HTTP requests against this adopted origin, executing the SSRF attack. Impact Any Angular application utilizing server-side rendering…
Recommended action: Upgrade to 22.0.0-rc.2 (pre-release), 21.2.15, 20.3.22 or 19.2.23 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.
Impact A Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server. The issue stems from how the server-side rendering (SSR) engine processes the request URL provided to the rendering entry points. When an absolute-form URL (e.g., http://evil.com) is passed to the rendering engine, the internal ServerPlatformLocation can be manipulated into adopting the attacker-controlled domain as the "current" hostname. Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services. Fix Information The vulnerability is mitigated by introducing an Allowlist Mechanism directly into the core rendering APIs. The renderModule and renderApplication functions now include an allowedHosts configuration option. The rendering engine validates the hostname extracted from the request URL against this list before proceeding. If the hostname does not match an…
Recommended action: Upgrade to 22.0.0-next.12 (pre-release), 21.2.13, 20.3.21 or 19.2.22 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.
Impact A Server-Side Request Forgery (SSRF) vulnerability exists in @angular/platform-server due to improper handling of URLs during Server-Side Rendering (SSR). When an attacker sends a request such as GET /\evil.com/ HTTP/1.1 the server engine (Express, etc.) passes the URL string to Angular’s rendering functions. Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is evil.com. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative HttpClient requests or PlatformLocation.hostname references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services. Affected APIs: - renderModule - renderApplication - CommonEngine (from @angular/ssr) Non-Affected APIs: - AngularAppEngine (from @angular/ssr) - AngularNodeAppEngine (from @angular/ssr) Attack…
Recommended action: Upgrade to 22.0.0-next.8 (pre-release), 21.2.9, 20.3.19 or 19.2.21 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.