GHSA-RFH7-FXQC-Q52V
Vulnerability from github – Published: 2026-05-19 20:29 – Updated: 2026-05-19 20:29Impact
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();
});
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@angular/platform-server"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0-next.0"
},
{
"fixed": "22.0.0-next.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/platform-server"
},
"ranges": [
{
"events": [
{
"introduced": "21.0.0-next.0"
},
{
"fixed": "21.2.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/platform-server"
},
"ranges": [
{
"events": [
{
"introduced": "20.0.0-next.0"
},
{
"fixed": "20.3.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/platform-server"
},
"ranges": [
{
"events": [
{
"introduced": "19.0.0-next.0"
},
{
"fixed": "19.2.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@angular/platform-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "18.2.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46417"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T20:29:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nA 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.\n\nWhen 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.\n\nConsequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.\n\n### Fix Information\nThe vulnerability is mitigated by introducing an Allowlist Mechanism directly into the core rendering APIs.\nThe 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.\n\n\n### Patches\n- 22.0.0-next.12\n- 21.2.13\n- 20.3.21\n- 19.2.22\n\n\n### Workarounds\nDevelopers 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 to`renderApplication` or `renderModule`.\n\n```TypeScript\n// Example manual normalization in Express\napp.get(\u0027*\u0027, (req, res, next) =\u003e {\n const trustedHost = \u0027localhost:4000\u0027;\n // Ensure the request target matches expectations\n if (req.headers.host !== trustedHost) {\n return res.status(403).send(\u0027Forbidden\u0027);\n }\n next();\n});\n```",
"id": "GHSA-rfh7-fxqc-q52v",
"modified": "2026-05-19T20:29:49Z",
"published": "2026-05-19T20:29:49Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/angular/angular/security/advisories/GHSA-rfh7-fxqc-q52v"
},
{
"type": "WEB",
"url": "https://github.com/angular/angular/pull/68570"
},
{
"type": "PACKAGE",
"url": "https://github.com/angular/angular"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "@angular/platform-server: SSRF via Hostname Hijacking"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.