You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)=>{constprefix=req.headers['x-forwarded-prefix']?.trim();if(prefix){// Sanitize by removing all leading slashesreq.headers['x-forwarded-prefix']=prefix.replace(/^[/\\]+/,'/');}next();});
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.
constALLOWED_HOSTS=newSet(['your-domain.com']);app.use((req,res,next)=>{consthostHeader=(req.headers['x-forwarded-host']??req.headers['host'])?.toString();constportHeader=req.headers['x-forwarded-port']?.toString();if(hostHeader){consthostname=hostHeader.split(':')[0];// Reject if hostname contains path separators or is not in allowlistif(/^[a-z0-9.:-]+$/i.test(hostname)||(!ALLOWED_HOSTS.has(hostname)&&hostname!=='localhost')){returnres.status(400).send('Invalid Hostname');}}// Ensure port is strictly numeric if providedif(portHeader&&!/^\d+$/.test(portHeader)){returnres.status(400).send('Invalid Port');}next();});
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)=>{constprefix=req.headers['x-forwarded-prefix'];if(typeofprefix==='string'){// Sanitize by removing all leading forward and backward slashesreq.headers['x-forwarded-prefix']=prefix.trim().replace(/^[/\\]+/,'/');}next();});
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)=>{letprefix=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)constdecodedPrefix=decodeURIComponent(prefix);// Sanitize: remove traversal attempts and ensure a safe leading slashreq.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 entirelydeletereq.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:
constappEngine=newAngularAppEngine({// Trust specific headerstrustProxyHeaders: ['x-forwarded-host','x-forwarded-proto','x-forwarded-prefix'],});constnodeAppEngine=newAngularNodeAppEngine({// Trust all X-Forwarded-* headerstrustProxyHeaders: true,});
renovateBot
changed the title
chore(deps): update dependency @angular/ssr to v21.2.3 [security]
chore(deps): update dependency @angular/ssr to v21.2.3 [security] - autoclosed
Mar 27, 2026
renovateBot
changed the title
chore(deps): update dependency @angular/ssr to v21.2.3 [security] - autoclosed
chore(deps): update dependency @angular/ssr to v21.2.3 [security]
Mar 30, 2026
renovateBot
changed the title
chore(deps): update dependency @angular/ssr to v21.2.3 [security]
chore(deps): update dependency @angular/ssr to v21.2.9 [security]
May 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
the
type: chore
![kodiakhq[bot]](https://avatars.githubusercontent.com/in/29196?s=60&v=4){kind=small}
renovate
Bot
changed the title
This PR contains the following updates:
21.2.0→21.2.921.0.0→21.2.9Angular 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-Prefixheader, an attacker can provide a value starting with three slashes (e.g.,///evil.com).redirectToor i18n locale switch).///evil.comas the prefix.//evil.com.Locationheader.//as a protocol-relative URL, redirecting the user fromhttps://your-app.comtohttps://evil.com.Impact
This vulnerability allows attackers to conduct large-scale phishing and SEO hijacking:
Attack Preconditions
X-Forwarded-Prefixheader to the SSR process without sanitization.X-Forwarded-Prefixheader.Patches
Workarounds
Until the patch is applied, developers should sanitize the
X-Forwarded-Prefixheader in theirserver.tsbefore the Angular engine processes the request:Resources
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NReferences
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:
HostandX-Forwarded-Hostheaders 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.X-Forwarded-Hostheader was not checked for path segments or special characters, allowing manipulation of the base path for all resolved relative URLs.X-Forwarded-Portheader was not verified as numeric, leading to malformed URI construction or injection attacks.This vulnerability manifests in two primary ways:
HttpClientresolves relative URLs against this unvalidated and potentially malformed base origin. An attacker can "steer" these requests to an external server or internal service.REQUESTobject to manually construct URLs (for fetch or third-party SDKs) directly inherit these unsanitized values. By accessing theHost/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:
Authorizationheaders or session cookies by redirecting them to an attacker's server.169.254.169.254) not exposed to the public internet.Attack Preconditions
HttpClientrequests using relative URLs OR manually construct URLs using the unvalidatedHost/X-Forwarded-*headers using theREQUESTobject.Patches
Workarounds
req.headersfor URL construction. Instead, use trusted variables for your base API paths.server.tsto enforce numeric ports and validated hostnames.References
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:NReferences
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/ssrdue 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-Prefixheader:\evil.com).Locationheader containing/\evil.com./\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-Prefixheader, 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:
Patches
Workarounds
Until the patch is applied, developers should sanitize the
X-Forwarded-Prefixheader in theirserver.tsbefore the Angular engine processes the request:References
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NReferences
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-Prefixheader 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-Prefixheader without prior sanitization, an attacker can provide a payload such as/%2e%2e/evil.The vulnerability manifests in two ways:
redirectTo). The decoded traversal payload manipulates the Location header, forcing the browser to an unintended path or external domain.HttpClientrequests. This causes the server to make requests to unintended internal paths or external endpoints.Attack Preconditions
HttpClientrequests.X-Forwarded-Prefixheader to the SSR process without stripping or sanitizing it.Workarounds
Until the patch is applied, developers should manually sanitize the
X-Forwarded-Prefixheader in theirserver.ts. The workaround involves decoding the component to catch encoded traversal attempts before normalization: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:
Patches
Resources
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
angular/angular-cli (@angular/ssr)
v21.2.9Compare Source
@angular/cli
@schematics/angular
@angular/ssr
v21.2.8: 21.2.8Compare Source
@angular/cli
@angular-devkit/build-angular
@angular/build
v21.2.7Compare Source
@angular/cli
@angular/build
v21.2.6Compare Source
@angular/cli
@angular/build
v21.2.5Compare Source
@angular/cli
@angular/ssr
v21.2.4Compare Source
@angular/cli
@angular/build
@angular/ssr
v21.2.3Compare Source
@angular/cli
@angular/build
@angular/ssr
v21.2.2Compare Source
@angular/cli
@angular/build
CHROME_BINfor vitest playwright providerv21.2.1Compare Source
@angular/cli
ng add@schematics/angular
@angular-devkit/build-angular
@angular/build
vi.mockfor non-relative importsng-package.jsonin unit-test builderng servewith i18n@angular/ssr
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.