chore(deps): update dependency @angular/ssr to v20.3.25 [security] 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.25`

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 @&#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

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 SSR has a Server-Side Request Forgery (SSRF) flaw

CVE-2025-62427 / GHSA-q63q-pgmf-mxhr

More information

Details

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

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:N/SI:N/SA:N

References

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

Angular SSR has an Open Redirect via X-Forwarded-Prefix

CVE-2026-27738 / GHSA-xh43-g2fq-wjrj

More information

Details

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

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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

Angular SSR is vulnerable to SSRF and Header Injection via request handling pipeline

CVE-2026-27739 / GHSA-x288-3778-4hhx

More information

Details

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

Severity

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

References

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

Protocol-Relative URL Injection via Single Backslash Bypass in Angular SSR

CVE-2026-33397 / GHSA-vfx2-hv2g-xj5f

More information

Details

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

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

References

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

Angular SSR has Open Redirect and Request Steering via Encoded X-Forwarded-Prefix

CVE-2026-44437 / GHSA-69xr-m8h6-h664

More information

Details

Description

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 make requests to unintended internal paths or external endpoints.

Attack Preconditions

The application must use Angular SSR.
The application must perform internal redirects or use relative URLs in server-side HttpClient requests.
The upstream infrastructure (Reverse Proxy/CDN) must pass the X-Forwarded-Prefix header to the SSR process without stripping or sanitizing it.

Workarounds

Until the patch is applied, developers should manually sanitize the X-Forwarded-Prefix header in their server.ts. The workaround involves decoding the component to catch encoded traversal attempts before normalization:

app.use((req, res, next) => {
  let prefix = req.headers['x-forwarded-prefix'];
  if (Array.isArray(prefix)) prefix = prefix[0];

  if (prefix) {
    try {
      // Decode the prefix to catch encoded characters like %2e (dots)
      const decodedPrefix = decodeURIComponent(prefix);
      
      // Sanitize: remove traversal attempts and ensure a safe leading slash
      req.headers['x-forwarded-prefix'] = decodedPrefix
        .replace(/\.\./g, '')       // Remove any dot-dot sequences
        .replace(/^[/\\]+/, '/');   // Ensure it starts with exactly one slash
    } catch (e) {
      // If decoding fails, remove the potentially malicious header entirely
      delete req.headers['x-forwarded-prefix'];
    }
  }
  next();
});

Configuring Trusted Proxy Headers

By default, Angular ignores all X-Forwarded-* headers. If your application is behind a trusted reverse proxy (like a load balancer) that sets these headers, you can configure Angular to trust them.
You can configure trustProxyHeaders when initializing the application engine:

const appEngine = new AngularAppEngine({
  // Trust specific headers
  trustProxyHeaders: ['x-forwarded-host', 'x-forwarded-proto', 'x-forwarded-prefix'], 
});

const nodeAppEngine = new AngularNodeAppEngine({
  // Trust all X-Forwarded-* headers
  trustProxyHeaders: true, 
});

Patches

22.0.0-next.7
21.2.9
20.3.25
19.2.25

Resources

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N

References

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

Release Notes

angular/angular-cli (@angular/ssr)

Commit	Type	Description
1dc6992a5	fix	disallow x-forwarded-prefix starting with a backslash
0a2ff0b2b	fix	ensure unique values in redirect response Vary header
cdbac82a8	fix	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`

Conversation

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

Uh oh!

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

Details

Impact

Patches

Workarounds

References

Severity

References

Angular SSR has a Server-Side Request Forgery (SSRF) flaw

Details

Impact

Exploit Scenario

Patches

Mitigation

Server-Side Middleware

References

Severity

References

Angular SSR has an Open Redirect via X-Forwarded-Prefix

Details

Impact

Attack Preconditions

Patches

Workarounds

Resources

Severity

References

Angular SSR is vulnerable to SSRF and Header Injection via request handling pipeline

Details

Impact

Attack Preconditions

Patches

Workarounds

References

Severity

References

Protocol-Relative URL Injection via Single Backslash Bypass in Angular SSR

Details

Impact

Patches

Workarounds

References

Severity

References

Angular SSR has Open Redirect and Request Steering via Encoded X-Forwarded-Prefix

Details

Description

Attack Preconditions

Workarounds

Configuring Trusted Proxy Headers

Patches

Resources

Severity

References

Release Notes

Breaking Changes

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate Bot commented Sep 11, 2025 •

edited

Loading