chore(deps): update dependency @angular/ssr to v20.3.21 [security] - autoclosed by renovate[bot] · Pull Request #124 · schedule-x/angular

renovate · 2025-09-11T00:29:19Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@angular/ssr	`20.1.2` → `20.3.21`

GitHub Vulnerability Alerts

CVE-2025-59052

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 @&#8203;angular/cli @&#8203;angular/core

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

# For apps on Angular v18:
ng update @&#8203;angular/cli@18 @&#8203;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 @&#8203;angular/core --name add-bootstrap-context-to-server-main

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

# For apps on Angular v18:
ng update @&#8203;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

CVE-2025-62427

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 resolved against the attacker's domain, forcing the server to communicate with an arbitrary external endpoint.

Exploit Scenario

A request to http://localhost:4200//attacker-domain.com/some-page causes Angular to believe the host is attacker-domain.com. A relative request to api/data then becomes a server-side request to http://attacker-domain.com/api/data.

Patches

@angular/ssr 19.2.18
@angular/ssr 20.3.6
@angular/ssr 21.0.0-next.8

Mitigation

The application's internal location must be robustly determined from the incoming request. The fix requires sanitizing or validating the request path to prevent it from being interpreted as a schema-relative URL (i.e., ensuring it does not start with //).

Server-Side Middleware

If you can't upgrade to a patched version, implement a middleware on the Node.js/Express server that hosts the Angular SSR application to explicitly reject or sanitize requests where the path begins with a double slash (//).

Example (Express/Node.js):

// Place this middleware before the Angular SSR handler
app.use((req, res, next) => {
  if (req.originalUrl?.startsWith('//')) {
    // Sanitize by forcing a single slash
    req.originalUrl = req.originalUrl.replace(/^\/\/+/, '/');
    req.url = req.url.replace(/^\/\/+/, '/');
  }
  next();
});

References

CVE-2026-27738

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).

The application processes a redirect (e.g., from a router redirectTo or i18n locale switch).
Angular receives ///evil.com as the prefix.
It strips one slash, leaving //evil.com.
The resulting string is used in the Location header.
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 Poisoning: Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains.
Trust: Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

Attack Preconditions

The application must use Angular SSR.
The application must have routes that perform internal redirects.
The infrastructure (Reverse Proxy/CDN) must pass the X-Forwarded-Prefix header to the SSR process without sanitization.
The cache must not vary on the X-Forwarded-Prefix header.

Patches

21.2.0-rc.1
21.1.5
20.3.17
19.2.21

Workarounds

Until the patch is applied, developers should sanitize the X-Forwarded-Prefix header in theirserver.ts before the Angular engine processes the request:

app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix']?.trim();
  if (prefix) {
    // Sanitize by removing all leading slashes
    req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
  }
  next();
});

Resources

Report
Fix

CVE-2026-27739

A Server-Side Request Forgery (SSRF) vulnerability has been identified in the Angular SSR request handling pipeline. The vulnerability exists because Angular’s internal URL reconstruction logic directly trusts and consumes user-controlled HTTP headers specifically the Host and X-Forwarded-* family to determine the application's base origin without any validation of the destination domain.

Specifically, the framework didn't have checks for the following:

Host Domain: The Host and X-Forwarded-Host headers were not checked to belong to a trusted origin. This allows an attacker to redefine the "base" of the application to an arbitrary external domain.
Path & Character Sanitization: The X-Forwarded-Host header was not checked for path segments or special characters, allowing manipulation of the base path for all resolved relative URLs.
Port Validation: The X-Forwarded-Port header was not verified as numeric, leading to malformed URI construction or injection attacks.

This vulnerability manifests in two primary ways:

Implicit Relative URL Resolution: Angular's HttpClient resolves relative URLs against this unvalidated and potentially malformed base origin. An attacker can "steer" these requests to an external server or internal service.
Explicit Manual Construction: Developers injecting the REQUEST object to manually construct URLs (for fetch or third-party SDKs) directly inherit these unsanitized values. By accessing the Host / X-Forwarded-* headers, the application logic may perform requests to attacker-controlled destinations or malformed endpoints.

Impact

When successfully exploited, this vulnerability allows for arbitrary internal request steering. This can lead to:

Credential Exfiltration: Stealing sensitive Authorization headers or session cookies by redirecting them to an attacker's server.
Internal Network Probing: Accessing and transmitting data from internal services, databases, or cloud metadata endpoints (e.g., 169.254.169.254) not exposed to the public internet.
Confidentiality Breach: Accessing sensitive information processed within the application's server-side context.

Attack Preconditions

The victim application must use Angular SSR (Server-Side Rendering).
The application must perform HttpClient requests using relative URLs OR manually construct URLs using the unvalidated Host / X-Forwarded-* headers using the REQUEST object.
Direct Header Access: The application server is reachable by an attacker who can influence these headers without strict validation from a front-facing proxy.
Lack of Upstream Validation: The infrastructure (Cloud, CDN, or Load Balancer) does not sanitize or validate incoming headers.

Patches

21.2.0-rc.1
21.1.5
20.3.17
19.2.21

Workarounds

Use Absolute URLs: Avoid using req.headers for URL construction. Instead, use trusted variables for your base API paths.
Implement Strict Header Validation (Middleware): If you cannot upgrade immediately, implement a middleware in your server.ts to enforce numeric ports and validated hostnames.

const ALLOWED_HOSTS = new Set(['your-domain.com']);

app.use((req, res, next) => {
  const hostHeader = (req.headers['x-forwarded-host'] ?? req.headers['host'])?.toString();
  const portHeader = req.headers['x-forwarded-port']?.toString();

  if (hostHeader) {
    const hostname = hostHeader.split(':')[0];
    // Reject if hostname contains path separators or is not in allowlist
    if (/^[a-z0-9.:-]+$/i.test(hostname) || 
       (!ALLOWED_HOSTS.has(hostname) && hostname !== 'localhost')) {
      return res.status(400).send('Invalid Hostname');
    }
  }

  // Ensure port is strictly numeric if provided
  if (portHeader && !/^\d+$/.test(portHeader)) {
    return res.status(400).send('Invalid Port');
  }

  next();
});

References

Fix
Docs

CVE-2026-33397

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 large-scale phishing and SEO hijacking:

Scale: A single request can poison a high-traffic route, impacting all users until the cache expires.
SEO Poisoning: Search engine crawlers may follow and index these malicious redirects, causing the legitimate site to be delisted or associated with malicious domains.
Trust: Because the initial URL belongs to the trusted domain, users and security tools are less likely to flag the redirect as malicious.

Patches

22.0.0-next.2
21.2.3
20.3.21

Workarounds

Until the patch is applied, developers should sanitize the X-Forwarded-Prefix header in their server.ts before the Angular engine processes the request:

app.use((req, res, next) => {
  const prefix = req.headers['x-forwarded-prefix'];
  if (typeof prefix === 'string') {
    // Sanitize by removing all leading forward and backward slashes
    req.headers['x-forwarded-prefix'] = prefix.trim().replace(/^[/\\]+/, '/');
  }
  next();
});

References

Fix: https://github.com/angular/angular-cli/pull/32771
Original CVE: CVE-2026-27738

Release Notes

angular/angular-cli (@angular/ssr)

Commit	Description
	disallow x-forwarded-prefix starting with a backslash
	ensure unique values in redirect response Vary header
	support custom headers in redirect responses

Commit	Type	Description
8700e18d7	fix	prevent open redirect via X-Forwarded-Prefix header
67582a946	fix	validate host headers to prevent header-based SSRF

Commit	Type	Description
cceb86296	fix	handle `X-Forwarded-Prefix` and `APP_BASE_HREF` in redirects
1abe68ad8	fix	prevent redirect loop with encoded query parameters

Commit	Type	Description
08e07e338	fix	improve locale handling in app-engine
683697ebc	fix	improve route matching for wildcard routes

Commit	Type	Description
542973ab0	fix	add adapters to new reporter
f0885691d	fix	ensure locale data plugin runs before other plugins
45e498f95	fix	handle redirects from guards during prerendering

Commit	Type	Description
8cdda111c	fix	resolve Angular locale data namespace in esbuild
5847ccc54	fix	update `vite` to `7.11.1`

Commit	Type	Description
3a28fb6a1	fix	correctly handle routes with matrix parameters
5db6d6487	fix	ensure server-side navigation triggers a redirect

Commit	Type	Description
c94bf7ff0	fix	Out of the box support for PM2
465436c9f	fix	use bracket notation for `process.env['pm_id']`

Commit	Type	Description
be60be499	fix	add timestamp to bundle generation log
d60f4e53d	fix	update vite to version `7.1.5`

Commit	Type	Description
a793bbc47	fix	don't set a default for array options when length is 0
2736599e2	fix	set process title when running architect commands

Commit	Type	Description
5c2abffea	fix	avoid extra tick in SSR dev-server builds
f3c826853	fix	maintain media output hashing with vitest unit-testing

Commit	Type	Description
6937123a3	fix	directly resolve karma config template in migration
5d6dd4425	fix	prevent AI config schematic from failing when 'none' and other AI tools are selected

Commit	Type	Description
06a6ddc10	fix	correct JS/TS file paths when running under Bazel
b6816b0cb	fix	ensure karma polyfills reporter factory returns a value

Commit	Type	Description
b4de9a1bf	feat	add --experimental-tool option to mcp command
755ba70fd	feat	add --local-only option to mcp command
59d7ef343	feat	add --read-only option to mcp command
4e92eb6f1	feat	add modernize tool to the MCP server
a3b25f675	fix	add choices to command line parser when type is array and has an enum
e19eee614	fix	address Node.js deprecation DEP0190
4ee6f327a	fix	apply default to array types
8ba6b0bcc	fix	use correct path for MCP get_best_practices tool

Commit	Type	Description
2e3cfd598	feat	add migration to remove default Karma configurations
d80dae276	feat	add schematics to generate ai context files.
ffe6fb916	fix	allow AI config prompt to be skipped without selecting a value
ae2802b7d	fix	improve AI config prompt wording
b017f84fd	fix	improve coverage directory handling for Karma configuration comparisons
6a79f9a75	fix	zoneless is now stable

Commit	Type	Description
584bc1d41	fix	add extra prettier config
02b0506fd	fix	correct configure the `typeSeparator` in the library schematic

Conversation

renovate bot commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Impact

Patches

Workarounds

References

Impact

Exploit Scenario

Patches

Mitigation

Server-Side Middleware

References

Impact

Attack Preconditions

Patches

Workarounds

Resources

Impact

Attack Preconditions

Patches

Workarounds

References

Impact

Patches

Workarounds

References

Release Notes

v20.3.21: 20.3.21

Breaking Changes

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate bot commented Sep 11, 2025 •

edited

Loading

`v20.3.21`: 20.3.21