Severity by source
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable SSR endpoint with no auth or user interaction; SSRF crosses a security boundary into internal/metadata services (S:C), yielding high confidentiality, limited integrity, no availability impact.
Primary rating from Vendor (https://github.com/angular/angular).
CVSS VectorVendor: https://github.com/angular/angular
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
6DescriptionCVE.org
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();
});AnalysisAI
Server-Side Request Forgery in @angular/platform-server allows remote unauthenticated attackers to hijack the SSR hostname by supplying an absolute-form URL to the rendering entry points, causing relative HttpClient calls and PlatformLocation references to be redirected to attacker-controlled domains. Affected versions span the 19.x, 20.x, 21.x, and 22.0.0-next branches, and exploitation can expose internal APIs or cloud metadata services. No public exploit identified at time of analysis, EPSS is very low at 0.05%, but the upstream fix and clear reproduction path raise the practical risk for exposed SSR deployments.
Technical ContextAI
The vulnerability resides in @angular/platform-server, the Node.js-side runtime that performs Angular Server-Side Rendering via renderModule and renderApplication. Internally, ServerPlatformLocation derives the 'current' hostname from the request URL passed into the renderer; when that URL is absolute (scheme + host), the host portion is adopted as the SSR origin. Any later HttpClient request using a relative path is then resolved against that attacker-controlled host, and PlatformLocation.hostname reflects the same value. This is a textbook CWE-918 (SSRF) caused by trusting an externally controlled URL as a server-side request target. The patch (PR #68570) adds an allowedHosts option and an isHostAllowed check inside validateAllowedHosts, which parses the URL with URL.canParse, extracts the hostname, and rejects requests whose host is not in the configured allowlist (with '*' and '*.domain' wildcard support).
RemediationAI
Vendor-released patch: upgrade @angular/platform-server to 19.2.22, 20.3.21, 21.2.13, or 22.0.0-next.12 depending on your major version, per GHSA-rfh7-fxqc-q52v and PR https://github.com/angular/angular/pull/68570, and pass the new allowedHosts option to renderModule/renderApplication listing only your trusted SSR hostnames (wildcards like '*.example.com' or '*' are supported but '*' disables the protection). If you cannot patch immediately, normalize or validate req.url in your Express/Node entry point before handing it to the renderer - either reject requests whose Host header does not match an allowlist (with HTTP 403, accepting that legitimate clients using unexpected host headers will be blocked) or strip the absolute-form portion and pass only a relative path to renderModule/renderApplication, which preserves routing but loses access to the original host for any code that legitimately depends on PlatformLocation.hostname. Putting Angular SSR behind a reverse proxy (nginx, ALB) that rewrites the request line to origin-form is an additional defense, but does not substitute for upgrading since some proxies forward absolute-form URLs unchanged.
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-38294
GHSA-rfh7-fxqc-q52v