Lookup for vulnerable packages by Package URL.
| Purl | pkg:npm/%40angular/platform-server@11.1.0-next.3 |
| Type | npm |
| Namespace | @angular |
| Name | platform-server |
| Version | 11.1.0-next.3 |
| Qualifiers |
|
| Subpath | |
| Is_vulnerable | true |
| Next_non_vulnerable_version | 19.2.21 |
| Latest_non_vulnerable_version | 22.0.0-next.12 |
| Affected_by_vulnerabilities |
| 0 |
| url |
VCID-jv2a-p2w8-rbdt |
| vulnerability_id |
VCID-jv2a-p2w8-rbdt |
| summary |
Angular: SSRF via protocol-relative and backslash URLs in Angular Platform-Server
### Impact
A [Server-Side Request Forgery (SSRF)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/SSRF) vulnerability exists in `@angular/platform-server` due to improper handling of URLs during Server-Side Rendering (SSR).
When an attacker sends a request such as `GET /\evil.com/ HTTP/1.1` the server engine (Express, etc.) passes the URL string to Angular’s rendering functions.
Because the URL parser normalizes the backslash to a forward slash for HTTP/HTTPS schemes, the internal state of the application is hijacked to believe the current origin is `evil.com`. This misinterpretation tricks the application into treating the attacker’s domain as the local origin. Consequently, any relative `HttpClient` requests or `PlatformLocation.hostname` references are redirected to the attacker controlled server, potentially exposing internal APIs or metadata services.
**Affected APIs:**
- `renderModule`
- `renderApplication`
- `CommonEngine` (from `@angular/ssr`)
**Non-Affected APIs:**
- `AngularAppEngine` (from `@angular/ssr`)
- `AngularNodeAppEngine` (from `@angular/ssr`)
### Attack Preconditions
- The server has outbound network access.
- The application uses Angular SSR via the affected APIs.
- A pathname is passed as URL to the rendering method (e.g. using `req.url`).
- The server-side code performs HTTP requests using `HttpClient` with relative URLs or uses `PlatformLocation.hostname` to build URLs.
### Patches
- 22.0.0-next.8
- 21.2.9
- 20.3.19
- 19.2.21
### Workarounds
Developers should implement a middleware to sanitize the request URL before it reaches Angular. This involves stripping or normalizing leading slashes:
```js
app.use((req, res, next) => {
// Sanitize the URL to ensure it starts with a single forward slash
if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) {
req.url = '/' + req.url.replace(/^[/\\]+/, '');
}
next();
});
```
### References
- [Fix](https://github.com/angular/angular/pull/68194) |
| references |
| 0 |
| reference_url |
https://api.first.org/data/v1/epss?cve=CVE-2026-41423 |
| reference_id |
|
| reference_type |
|
| scores |
| 0 |
| value |
0.00038 |
| scoring_system |
epss |
| scoring_elements |
0.11638 |
| published_at |
2026-06-08T12:55:00Z |
|
| 1 |
| value |
0.00038 |
| scoring_system |
epss |
| scoring_elements |
0.11721 |
| published_at |
2026-06-07T12:55:00Z |
|
| 2 |
| value |
0.00038 |
| scoring_system |
epss |
| scoring_elements |
0.11755 |
| published_at |
2026-06-06T12:55:00Z |
|
| 3 |
| value |
0.00038 |
| scoring_system |
epss |
| scoring_elements |
0.11762 |
| published_at |
2026-06-05T12:55:00Z |
|
| 4 |
| value |
0.00041 |
| scoring_system |
epss |
| scoring_elements |
0.12873 |
| published_at |
2026-06-09T12:55:00Z |
|
|
| url |
https://api.first.org/data/v1/epss?cve=CVE-2026-41423 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
|
| fixed_packages |
|
| aliases |
CVE-2026-41423, GHSA-45q2-gjvg-7973
|
| risk_score |
4.0 |
| exploitability |
0.5 |
| weighted_severity |
8.0 |
| resource_url |
http://public2.vulnerablecode.io/vulnerabilities/VCID-jv2a-p2w8-rbdt |
|
|
| Fixing_vulnerabilities |
|
| Risk_score | 4.0 |
| Resource_url | http://public2.vulnerablecode.io/packages/pkg:npm/%2540angular/platform-server@11.1.0-next.3 |