### 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 to`renderApplication` or `renderModule`. ```TypeScript // 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(); }); ```
### 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 to`renderApplication` or `renderModule`. ```TypeScript // 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(); }); ```
Update @angular/platform-server to 22.0.0-next.12; @angular/platform-server to 21.2.13; @angular/platform-server to 20.3.21; @angular/platform-server to 19.2.22 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@angular/platform-server: SSRF via Hostname Hijacking affects @angular/platform-server (npm), @angular/platform-server (npm), @angular/platform-server (npm), @angular/platform-server (npm), @angular/platform-server (npm). Severity is high. ### 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 to`renderApplication` or `renderModule`. ```TypeScript // 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(); }); ```
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @angular/platform-servernpm | >=22.0.0-next.0,<22.0.0-next.12 | 22.0.0-next.12 |
| @angular/platform-servernpm | >=21.0.0-next.0,<21.2.13 | 21.2.13 |
| @angular/platform-servernpm | >=20.0.0-next.0,<20.3.21 | 20.3.21 |
| @angular/platform-servernpm | >=19.0.0-next.0,<19.2.22 | 19.2.22 |
| @angular/platform-servernpm | <=18.2.14 | Not reported |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate @angular/platform-server to 22.0.0-next.12; @angular/platform-server to 21.2.13; @angular/platform-server to 20.3.21; @angular/platform-server to 19.2.22 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@angular/platform-server: SSRF via Hostname Hijacking affects @angular/platform-server (npm), @angular/platform-server (npm), @angular/platform-server (npm), @angular/platform-server (npm), @angular/platform-server (npm). Severity is high. ### 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 to`renderApplication` or `renderModule`. ```TypeScript // 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(); }); ```
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @angular/platform-servernpm | >=22.0.0-next.0,<22.0.0-next.12 | 22.0.0-next.12 |
| @angular/platform-servernpm | >=21.0.0-next.0,<21.2.13 | 21.2.13 |
| @angular/platform-servernpm | >=20.0.0-next.0,<20.3.21 | 20.3.21 |
| @angular/platform-servernpm | >=19.0.0-next.0,<19.2.22 | 19.2.22 |
| @angular/platform-servernpm | <=18.2.14 | Not reported |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard