Skip to content

fix(deps): update dependency @angular/platform-server to v20 [security] - #813

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/npm-angular-platform-server-vulnerability
Open

fix(deps): update dependency @angular/platform-server to v20 [security]#813
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/npm-angular-platform-server-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jul 16, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@angular/platform-server (source) ~18.2.0 → ~20.0.0 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Angular SSR: Global Platform Injector Race Condition Leads to Cross-Request Data Leakage

CVE-2025-59052 / GHSA-68x2-mx4q-78m7

More information

Details

Impact

Angular uses a DI container (the "platform injector") to hold request-specific state during server-side rendering. For historical reasons, the container was stored as a JavaScript module-scoped global variable. When multiple requests are processed concurrently, they could inadvertently share or overwrite the global injector state.

In practical terms, this can lead to one request responding with data meant for a completely different request, leaking data or tokens included on the rendered page or in response headers. As long as an attacker had network access to send any traffic that received a rendered response, they may have been able to send a large number of requests and then inspect the responses for information leaks.

The following APIs were vulnerable and required SSR-only breaking changes:

  • bootstrapApplication: This function previously implicitly retrieved the last platform injector that was created. It now requires an explicit BootstrapContext in a server environment. This function is only used for standalone applications. NgModule-based applications are not affected.
  • getPlatform: This function previously returned the last platform instance that was created. It now always returns null in a server environment.
  • destroyPlatform: This function previously destroyed the last platform instance that was created. It's now a no-op when called in a server environment.

For bootstrapApplication, the framework now provides a new argument to the application's bootstrap function:

// Before:
const bootstrap = () => bootstrapApplication(AppComponent, config);

// After:
const bootstrap = (context: BootstrapContext) =>
  bootstrapApplication(AppComponent, config, context);

As is usually the case for changes to Angular, an automatic schematic will take care of these code changes as part of ng update:

##### For apps on Angular v20:
ng update @angular/cli @angular/core

##### For apps on Angular v19:
ng update @angular/cli@19 @angular/core@19

##### For apps on Angular v18:
ng update @angular/cli@18 @angular/core@18

The schematic can also be invoked explicitly if the version bump was pulled in independently:

##### For apps on Angular v20:
ng update @angular/core --name add-bootstrap-context-to-server-main

##### For apps on Angular v19:
ng update @angular/core@19 --name add-bootstrap-context-to-server-main

##### For apps on Angular v18:
ng update @angular/core@18 --name add-bootstrap-context-to-server-main

For applications that still use CommonEngine, the bootstrap property in CommonEngineOptions also gains the same context argument in the patched versions of Angular.

In local development (ng serve), Angular CLI triggered a codepath for Angular's "JIT" feature on the server even in applications that weren't using it in the browser. The codepath introduced async behavior between platform creation and application bootstrap, triggering the race condition even if an application didn't explicitly use getPlatform or custom async logic in bootstrap. Angular applications should never run in this mode outside of local development.

Patches

The issue has been patched in all active release lines as well as in the v21 prerelease:

  • @angular/platform-server: 21.0.0-next.3

  • @angular/platform-server: 20.3.0

  • @angular/platform-server: 19.2.15

  • @angular/platform-server: 18.2.14

  • @angular/ssr: 21.0.0-next.3

  • @angular/ssr: 20.3.0

  • @angular/ssr: 19.2.16

  • @angular/ssr: 18.2.21

Workarounds
  • Disable SSR via Server Routes (v19+) or builder options.
  • Remove any asynchronous behavior from custom bootstrap functions.
  • Remove uses of getPlatform() in application code.
  • Ensure that the server build defines ngJitMode as false.
References

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server

CVE-2026-41423 / GHSA-45q2-gjvg-7973

More information

Details

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 Preconditions
  • The server has outbound network access.
  • The application uses Angular SSR via the affected APIs.
  • A pathname is passed as URL to the rendering method (e.g. using req.url).
  • The server-side code performs HTTP requests using HttpClient with relative URLs or uses PlatformLocation.hostname to build URLs.
Patches
  • 22.0.0-next.8
  • 21.2.9
  • 20.3.19
  • 19.2.21
Workarounds

Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:

app.use((req, res, next) => {
  // Sanitize the URL to ensure it starts with a single forward slash
  if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
     req.url = '/' + req.url.replace(/^[/\\]+/, '');
  }
  next();
});
References

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Angular SSR: Global Platform Injector Race Condition Leads to Cross-Request Data Leakage

CVE-2025-59052 / GHSA-68x2-mx4q-78m7

More information

Details

Impact

Angular uses a DI container (the "platform injector") to hold request-specific state during server-side rendering. For historical reasons, the container was stored as a JavaScript module-scoped global variable. When multiple requests are processed concurrently, they could inadvertently share or overwrite the global injector state.

In practical terms, this can lead to one request responding with data meant for a completely different request, leaking data or tokens included on the rendered page or in response headers. As long as an attacker had network access to send any traffic that received a rendered response, they may have been able to send a large number of requests and then inspect the responses for information leaks.

The following APIs were vulnerable and required SSR-only breaking changes:

  • bootstrapApplication: This function previously implicitly retrieved the last platform injector that was created. It now requires an explicit BootstrapContext in a server environment. This function is only used for standalone applications. NgModule-based applications are not affected.
  • getPlatform: This function previously returned the last platform instance that was created. It now always returns null in a server environment.
  • destroyPlatform: This function previously destroyed the last platform instance that was created. It's now a no-op when called in a server environment.

For bootstrapApplication, the framework now provides a new argument to the application's bootstrap function:

// Before:
const bootstrap = () => bootstrapApplication(AppComponent, config);

// After:
const bootstrap = (context: BootstrapContext) =>
  bootstrapApplication(AppComponent, config, context);

As is usually the case for changes to Angular, an automatic schematic will take care of these code changes as part of ng update:

##### For apps on Angular v20:
ng update @angular/cli @angular/core

##### For apps on Angular v19:
ng update @angular/cli@19 @angular/core@19

##### For apps on Angular v18:
ng update @angular/cli@18 @angular/core@18

The schematic can also be invoked explicitly if the version bump was pulled in independently:

##### For apps on Angular v20:
ng update @angular/core --name add-bootstrap-context-to-server-main

##### For apps on Angular v19:
ng update @angular/core@19 --name add-bootstrap-context-to-server-main

##### For apps on Angular v18:
ng update @angular/core@18 --name add-bootstrap-context-to-server-main

For applications that still use CommonEngine, the bootstrap property in CommonEngineOptions also gains the same context argument in the patched versions of Angular.

In local development (ng serve), Angular CLI triggered a codepath for Angular's "JIT" feature on the server even in applications that weren't using it in the browser. The codepath introduced async behavior between platform creation and application bootstrap, triggering the race condition even if an application didn't explicitly use getPlatform or custom async logic in bootstrap. Angular applications should never run in this mode outside of local development.

Patches

The issue has been patched in all active release lines as well as in the v21 prerelease:

  • @angular/platform-server: 21.0.0-next.3

  • @angular/platform-server: 20.3.0

  • @angular/platform-server: 19.2.15

  • @angular/platform-server: 18.2.14

  • @angular/ssr: 21.0.0-next.3

  • @angular/ssr: 20.3.0

  • @angular/ssr: 19.2.16

  • @angular/ssr: 18.2.21

Workarounds
  • Disable SSR via Server Routes (v19+) or builder options.
  • Remove any asynchronous behavior from custom bootstrap functions.
  • Remove uses of getPlatform() in application code.
  • Ensure that the server build defines ngJitMode as false.
References

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

@​angular/platform-server: Missing <noscript> Raw-Text Serialization Escaping leads to Cross-Site Scripting (XSS) in Angular SSR

CVE-2026-50556 / GHSA-gxx4-3xcv-f8qx

More information

Details

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 `` 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 `` 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><script>alert(1)</script></noscript>). When parsed by a browser, it closes the <noscript> block early, allowing the injected <script> block to execute in the user's browser context, causing same-origin Cross-Site Scripting (XSS).

Impact

This vulnerability allows an attacker to perform same-origin Cross-Site Scripting (XSS) attacks against any user visiting an SSR-rendered page that binds user-controlled data inside a <noscript> element. This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions
  • 22.0.0-rc.2
  • 21.2.16
  • 20.3.24
  • 19.2.25
Workarounds

If you cannot immediately update your dependencies, you can:

  • Avoid binding user-controlled values inside <noscript> elements.
  • Sanitize any user input placed inside <noscript> to explicitly strip closing </noscript> tags before passing it to the template.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

@​angular/platform-server: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CVE-2026-50555 / GHSA-hqr9-c56f-3x7f

More information

Details

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., 😀</iframe><script>alert(1)</script>). When serialized on the server during SSR, the browser parses the unescaped closing tag, exits the raw-text context early, and executes the subsequent <script> block, leading to same-origin Cross-Site Scripting (XSS).

Impact

This vulnerability allows an attacker to perform same-origin Cross-Site Scripting (XSS) attacks against any user visiting an SSR-rendered page that binds user-controlled data inside raw-text elements. This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions
  • 22.0.0-rc.2
  • 21.2.16
  • 20.3.24
  • 19.2.25
Workarounds

If you cannot immediately update your dependencies, you can:

  • Avoid binding user-controlled values inside <iframe> or other raw-text elements.
  • Sanitize any user input placed inside raw-text elements to explicitly strip closing tags before passing it to the template.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

@​angular/platform-server: SSRF via Hostname Hijacking

CVE-2026-46417 / GHSA-rfh7-fxqc-q52v

More information

Details

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 allowed entry, the engine prevents the hostname hijacking, ensuring that HttpClient requests remain restricted to trusted domains.

Patches
  • 22.0.0-next.12
  • 21.2.13
  • 20.3.21
  • 19.2.22
Workarounds

Developers unable to update immediately should implement strict URL validation in their server entry point (e.g., server.ts). Ensure that req.url is validated against a known list of trusted hostnames or normalized to a relative path before being passed torenderApplication or renderModule.

// Example manual normalization in Express
app.get('*', (req, res, next) => {
  const trustedHost = 'localhost:4000';
  // Ensure the request target matches expectations
  if (req.headers.host !== trustedHost) {
     return res.status(403).send('Forbidden');
  }
  next();
});

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

@​angular/platform-server: URL Parser Differential leading to SSRF Allowlist Bypass

CVE-2026-50168 / GHSA-xrxm-cp7j-8xf6

More information

Details

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 (@angular/platform-server) that configures host routing allowlists (allowedHosts) is vulnerable to this allowlist bypass.

By sending an HTTP request with a malformed Host header (e.g. Host: evil.com:80:80) or an absolute-form request URI, an attacker can bypass the allowlist logic completely (even when configured with a strict default deny setup). The SSR application will then route all relative HttpClient outgoing API queries—which commonly carry sensitive credentials, session cookies, and internal authorization tokens—to the attacker-controlled server instead of the intended backend services. Additionally, the attacker can supply custom payloads back to the emulated DOM, leading to response injection and content poisoning within the rendered HTML served to users.

Attack Preconditions

To successfully exploit this vulnerability, the following environment parameters and application states must all concurrently exist:

  1. Active Server-Side Rendering (SSR): The application must be configured to run with Angular Server-Side Rendering (@angular/platform-server).
  2. Host Header/URI Propagation: The SSR handler must reconstruct the request URL using raw client inputs (such as request Host headers or absolute-form URIs) and pass it as config.url to the rendering API (renderApplication or renderModule).
  3. Outbound Relative HTTP Requests: The server application must perform outbound backend API requests using relative paths (e.g., this.http.get('/api/data')) that undergo base-URL interceptor rewriting.
  4. Enabled Allowed Hosts Check: The server must use the framework-provided allowedHosts options to limit valid server locations.
Patches
  • 22.0.0-rc.2
  • 21.2.15
  • 20.3.22
  • 19.2.23

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Angular: SSRF and Cross-Origin Credential Disclosure via URL Resolution Discrepancy in SSR

CVE-2026-88056 / GHSA-f6mr-pjwc-34m4

More information

Details

Summary

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 URL (//attacker.example/collect). When resolved during server-side rendering (such as in relativeUrlsTransformerInterceptorFn), this caused the HTTP request to be dispatched to the attacker-controlled origin (http://attacker.example/collect), leaking any credentials (such as Authorization headers) attached by the application for the intended same-origin request.

Impact & Reachability
  • Reachability: The vulnerability affects Angular Server-Side Rendering (SSR) applications where user-controlled input influences resource or request URLs processed by Angular's HttpClient, an application-level same-origin check is performed before dispatching, and sensitive server-side credentials (such as API keys or Bearer tokens) are attached to approved requests.
  • Impact: Successful exploitation allows attackers to bypass same-origin validation, triggering Server-Side Request Forgery (SSRF) and leaking sensitive server-side credentials attached to the request.

Proof of Concept:

// Interceptor performing same-origin validation
const trustedOrigin = new URL('http://localhost:4000/');
const target = new URL(req.urlWithParams, trustedOrigin);

if (target.origin !== trustedOrigin.origin) {
  throw new Error('Cross-origin request blocked');
}

// Request passes validation, server attaches sensitive credential:
const authenticatedReq = req.clone({
  headers: req.headers.set('Authorization', 'Bearer SERVER-SECRET-TOKEN'),
});

// @angular/platform-server previously trimmed the URL, converting it into
// //attacker.example/collect and routing the credential to the attacker.
Workarounds
  • Validate and sanitize input URLs to disallow leading Unicode whitespace characters (such as \u00A0) before performing origin checks or passing them to HttpClient.
  • Avoid relying solely on new URL(input, trustedOrigin).origin for authorization if the input string may be trimmed or processed by utilities that normalize whitespace differently from the WHATWG URL standard.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Angular: SSR XSS via Unescaped Content Across DocumentFragment Boundaries in Fallback Raw-Content Elements

CVE-2026-88060 / GHSA-v3p8-whq6-r5jg

More information

Details

Summary

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 serialization, the DOM serializer inspects a node's ancestors to escape any matching fallback closing tags (</tag -> &lt;/tag). However:

  1. Per DOM specifications, the children of a <template> element reside in a separate DocumentFragment (template.content), whose own parentNode is null.
  2. The serializer's ancestor traversal previously only inspected element nodes. When traversing upward from a node inside template.content, traversal terminated immediately at the DocumentFragment boundary.
  3. Because traversal stopped before reaching the outer document tree, enclosing fallback raw-content ancestors (such as <noscript> or <iframe>) were not discovered. As a result, closing sequences like </noscript> within <template> content were emitted unescaped.
Impact & Reachability
  • Framework Guarantee Bypass: Angular guarantees that standard text interpolation (`` bound as element text content) is safe by default without manual sanitization. This vulnerability bypasses that guarantee during SSR HTML serialization when untrusted input is interpolated inside template content within fallback containers.
  • Template Authoring: Writing literal <xmp> or <style> directly inside a component's <template> markup requires relaxed template schema checks (CUSTOM_ELEMENTS_SCHEMA or NO_ERRORS_SCHEMA). However, standard HTML comments and text nodes inside <template> within <noscript> are reachable without relaxed schemas.
  • Imperative DOM Construction: Components or directives that construct DOM structures imperatively via Renderer2 bypass template compiler schema checks entirely and are unconditionally affected.
Proof of Concept (Minimal Reproduction)
import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <noscript>
      <template>
        <xmp></xmp>
      </template>
    </noscript>
  `
})
export class AppComponent {
  // Attacker-controlled input bound via standard text interpolation
  payload = '</noscript><img src=x onerror=alert("SSR_TEMPLATE_XSS")>';
}

Vulnerable SSR Output:

<noscript><template><xmp></noscript><img src=x onerror=alert("SSR_TEMPLATE_XSS")></xmp></template></noscript>
Workarounds
  • Avoid rendering untrusted user input inside <template> elements nested within <noscript>, <iframe>, <noembed>, or <noframes> in server-rendered templates.
  • Avoid programmatic DOM assembly of <template> elements inside fallback containers when handling untrusted data.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Angular SSR: Missing Fallback Raw-Content Serialization Escaping leads to Cross-Site Scripting (XSS)

CVE-2026-69149 / GHSA-vpx6-8pjr-4g3v

More information

Details

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 closes the element early, allowing an injected script block to execute in the user's browser context, causing same-origin Cross-Site Scripting (XSS).

Impact

This vulnerability allows an attacker to perform same-origin Cross-Site Scripting (XSS) attacks against any user visiting an SSR-rendered page that binds user-controlled data inside fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>). This can lead to session hijacking, credentials theft, unauthorized actions on behalf of users, and defacement.

Patched Versions
  • 22.0.7
  • 21.2.19
  • 20.3.27
Workarounds

If you cannot immediately update your dependencies, you can mitigate this issue using any of the following approaches:

  • Disable critical CSS inlining: Critical CSS inlining in Angular SSR post-processes the rendered HTML using domino. Disabling this step prevents domino from re-parsing and re-serializing the HTML during server-side rendering.
    • In angular.json, set inlineCritical to false under style optimization options: 
      {
  "projects": {
    "my-app": {
      "architect": {
        "build": {
          "builder": "@angular/build:application",
          "options": {
            "optimization": {
              "styles": {
                "inlineCritical": false
              }
            }
          }
        }
      }
    }
  }
}
    • When rendering programmatically with CommonEngine, set inlineCriticalCss: false in your render options.
  • Avoid binding user-controlled values inside fallback raw-content elements (<iframe>, <noembed>, <noframes>, <noscript>).
  • Sanitize user input placed inside these elements to explicitly strip or escape closing tags before passing it to the template.

Severity

  • CVSS Score: 8.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

angular/angular (@​angular/platform-server)

v20.0.0

Compare Source

Blog post: https://blog.angular.dev/announcing-angular-v20-b5c9c06cf301

Breaking Changes

common
  • Using the Y formatter (week-numbering year) without also including w (week number) is now detected as suspicious date pattern, as y is typically intended.
  • AsyncPipe now directly catches unhandled errors in
    subscriptions and promises and reports them to the application's
    ErrorHandler. For Zone-based applications, these errors would have
    been caught by ZoneJS and reported to ErrorHandler so the result is
    generally the same. The change to the exact mechanism for reporting can
    result in differences in test environments that will require test
    updates.
compiler

  • 'in' in an expression now refers to the operator

  • void in an expression now refers to the operator

    Previously an expression in the template like {{void}} referred to a
    property on the component class. After this change it now refers to the
    void operator, which would make the above example invalid. If you have
    existing expressions that need to refer to a property named void,
    change the expression to use this.void instead: {{this.void}}.

  • Parenthesis are always respected.

    This can lead to runtime breakages when a nullish coalescing operator is nested within parentheses.
    eg. {{ (foo?.bar).baz }} will throw if foo is nullish. This is the same behavior as native JavaScript.

core

  • TypeScript versions less than 5.8 are no longer supported.

  • the TestBed.flushEffects() was removed - use
    the TestBed.tick() instead.

  • provideExperimentalCheckNoChangesForDebug has several
    breaking changes:

    • It is renamed to provideCheckNoChangesConfig
    • The behavior applies to all checkNoChanges runs
    • The useNgZoneOnStable option is removed. This wasn't found to be generally
      more useful than interval

  • provideExperimentalZonelessChangeDetection is
    renamed to provideZonelessChangeDetection as it is now "Developer
    Preview" rather than "Experimental".

    • InjectFlags has been removed.
    • inject no longer accepts InjectFlags.
    • Injector.get no longer accepts InjectFlags.
    • EnvironmentInjector.get no longer accepts InjectFlags.
    • TestBed.get no longer accepts InjectFlags.
    • TestBed.inject no longer accepts InjectFlags.
    • TestBed.get has been removed. Use TestBed.inject instead.

  • afterRender was renamed to afterEveryRender.

    • Angular no longer supports Node.js v18.
    • Node.js versions 22.0 to 22.10 are also no longer supported.

    Before upgrading to Angular v20, ensure the Node.js version is at least 20.11.1.
    For the full list of supported versions, visit: https://angular.dev/reference/versions

  • PendingTasks.run no longer returns the result of the
    async function. If this behavior is desired, it can be re-implemented
    manually with the PendingTasks.add. Be aware, however, that promise rejections
    will need to be handled or they can cause the node process to shut down
    when using SSR.

  • Uncaught errors in listeners which were previously only reported to
    ErrorHandler are now also reported to Angular's internal error
    handling machinery. For tests, this means that the error will be
    rethrown by default rather than only logging the error. Developers
    should fix these errors, catch them in the test if the test is
    intentionally covering an error case, or use rethrowApplicationErrors: false in configureTestingModule as a last resort.

  • The any overload has been removed from
    injector.get. It now only supports ProviderToken<T> and (deprecated
    since v4) string.

  • Animations are guaranteed to be flushed when Angular
    runs automatic change detection or manual calls to ApplicationRef.tick.
    Prior to this change, animations would not be flushed in some situations
    if change detection did not run on any views attached to the
    application. This change can affect tests which may rely on the old
    behavior, often by making assertions on DOM elements that should have
    been removed but weren't because DOM removal is delayed until animations
    are flushed.

  • ApplicationRef.tick will no longer catch and report
    errors to the application ErrorHandler. Errors will instead be thrown out of
    the method and will allow callers to determine how to handle these
    errors, such as aborting follow-up work or reporting the error and
    continuing.

  • This commit deprecates ng-reflect-* attributes and updates the runtime to stop producing them by default. Please refactor application and test code to avoid relying on ng-reflect-* attributes.

    To enable a more seamless upgrade to v20, we've added the provideNgReflectAttributes() function (can be imported from the @angular/core package), which enables the mode in which Angular would be producing those attribites (in dev mode only). You can add the provideNgReflectAttributes() function to the list of providers within the bootstrap call.

router
  • The RedirectFn can now return Observable or
    Promise. Any code that directly calls functions returning this type
    may need to be adjusted to account for this.
  • Several methods in the public API of the Router which
    required writable arrays have now been updated to accept readonly
    arrays when no mutations are done.
  • The guards arrays on Route no longer include any in
    the type union. The union includes functions for the functional guards
    as well as a type matching Injector.get: ProviderToken<T>|string.
    Note that string is still deprecated on both the route guards and
    Injector.get.

Deprecations

core
  • ngIf/ngFor/ngSwitch are deprecated. Use the control flow blocks instead (@for/@if/@switch).
platform-browser
  • All entries of the @angular/platform-browser-dynamic
  • HammerJS support is deprecated and will be removed in a future major version.
platform-server

  • @angular/platform-server/testing

    Use e2e tests to verify SSR behavior instead.

common
Commit Type Description
2e5362a469 feat accept undefined inputs in NgTemplateOutlet (#​61404)
b7d3f3dbfc feat Allow passing ScrollOptions to ViewportScroller (#​61002)
74cceba587 feat throw error for suspicious date patterns (#​59798)
255c79e048 fix cleanup updateLatestValue if view is destroyed before promise resolves (#​58041)
739cadae62 fix Handle errors in async pipe subscriptions (#​60057)
cbbea70fa3 fix issue a warning instead of an error when NgOptimizedImage exceeds the preload limit (#​60879)
fc4a56d5c5 fix rename httpResource function in factory (#​60022)
785a1110e6 fix resolve host binding type issues (#​60481)
compiler
Commit Type Description
7a971766dc feat add extended diagnostic for uninvoked track function on @for blocks (#​60495)
f2d5cf7edd feat support exponentiation operator in templates (#​59894)
51b8ff23ce feat support tagged template literals in expressions (#​59947)
1b8e7ab9fe feat support the in keyword in Binary expression (#​58432)
0361c2d81f feat support void operator in templates (#​59894)
8b990a31c3 fix error if rawText isn't estimated correctly (#​60529)
4fe489f1b4 fix exponentiation should be right-to-left associative (#​60101)
ef1fd137a9 fix incorrect spans for template literals (#​60323)
e0d378d20e fix incorrectly handling let declarations inside i18n (#​60512)
b70ad3c4e6 fix proper handling of typeof, void in RecursiveAstVisitor (#​60101)
e25e6c95a2 fix remove TypeScript from linker (#​61635)
768239a89c perf reduce allocations for let declarations only used in the same view (#​60512)
compiler-cli

| Commit | Type | Description |
| --

❗ Important

✂ PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate

renovate Bot commented Jul 16, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: @heap-code/nna@0.0.0
npm error Found: @angular/common@18.2.14
npm error node_modules/@angular/common
npm error   @angular/common@"~18.2.0" from the root project
npm error
npm error Could not resolve dependency:
npm error peer @angular/common@"20.0.7" from @angular/platform-server@20.0.7
npm error node_modules/@angular/platform-server
npm error   @angular/platform-server@"~20.0.0" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.
npm error
npm error
npm error For a full report see:
npm error /runner/cache/others/npm/_logs/2026-09-10T20_47_31_911Z-eresolve-report.txt
npm error A complete log of this run can be found in: /runner/cache/others/npm/_logs/2026-09-10T20_47_31_911Z-debug-0.log

@renovate renovate Bot changed the title fix(deps): update dependency @angular/platform-server to v19 [security] chore(deps): update dependency @angular/platform-server to v18.2.14 [security] Jul 20, 2026
@renovate renovate Bot changed the title chore(deps): update dependency @angular/platform-server to v18.2.14 [security] fix(deps): update dependency @angular/platform-server to v19 [security] Jul 20, 2026
@renovate
renovate Bot force-pushed the renovate/npm-angular-platform-server-vulnerability branch from 6c74244 to 8eb0703 Compare August 3, 2026 17:11
@renovate renovate Bot changed the title fix(deps): update dependency @angular/platform-server to v19 [security] fix(deps): update dependency @angular/platform-server to v20 [security] Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies renovate security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants