We’ve released security updates to address two SSR vulnerabilities that we were made aware of and have since submitted committed code changes to fix.
The two patched vulnerabilities are:
We recommend all developers update their SSR applications to the latest patch version as soon as possible. If an app does not deploy SSR to production, there is no immediate need to update, however we generally recommend staying on the latest supported patch versions as much as possible.
SSRF and Header Injection in Angular SSR
A Server-Side Request Forgery (SSRF) vulnerability was identified in the Angular SSR request handling pipeline. Angular’s internal URL reconstruction logic incorrectly trusted 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.
To update your project, please find the patched version from the table on the report page and run
ng update @angular/ssr@<patched-version>`
For more information including affected versions and patch information, please refer to the CVE report on GitHub.
Workarounds
Any developers on an unsupported version of Angular or unable to quickly update should consider:
- Using Absolute URLs: Avoid using req.headers for URL construction. Instead, use trusted variables for your base API paths.
- Implementing Strict Header Validation (Middleware): Implement a middleware in your server.ts to enforce numeric ports and validated hostnames.
const ALLOWED_HOSTS = new Set(['your-domain.com']);
app.use((req, res, next) => {
const hostHeader = (req.headers['x-forwarded-host'] ?? req.headers['host'])?.toString();
const portHeader = req.headers['x-forwarded-port']?.toString();
if (hostHeader) {
const hostname = hostHeader.split(':')[0];
// Reject if hostname contains path separators or is not in allowlist
if (/^[a-z0-9.:-]+$/i.test(hostname) ||
(!ALLOWED_HOSTS.has(hostname) && hostname !== 'localhost')) {
return res.status(400).send('Invalid Hostname');
}
}
// Ensure port is strictly numeric if provided
if (portHeader && !/^\d+$/.test(portHeader)) {
return res.status(400).send('Invalid Port');
}
next();
});
Open Redirect via X-Forwarded-Prefix in Angular SSR
An Open Redirect vulnerability was identified in internal URL processing logic in Angular SSR. The logic normalized URL segments by stripping leading slashes; however, it only removed a single leading slash.
If Angular SSR application is deployed behind a proxy that accepted the X-Forwarded-Prefix header, an attacker can provide a value starting with three slashes (e.g., ///evil.com), causing a redirect to an attacker-controlled origin and could potentially poison any cached responses shared across multiple users.
To update your project, please find the patched version from the table on the report page and run
ng update @angular/ssr@<patched-version>
For more information, please refer to the report on GitHub.
Workarounds
Any developers on an unsupported version of Angular or unable to quickly update should consider sanitizing the X-Forwarded-Prefix header in their server.ts before the Angular engine processes the request:
app.use((req, res, next) => {
const prefix = req.headers['x-forwarded-prefix']?.trim();
if (prefix) {
// Sanitize by removing all leading slashes
req.headers['x-forwarded-prefix'] = prefix.replace(/^[/\\]+/, '/');
}
next();
});
Conclusion
We appreciate working with such bright security researchers who share our passion to keep the web secure everywhere. We participate in Google’s VRP (vulnerability rewards program) to encourage responsible disclosure of issues like these. We strongly recommend keeping critical infrastructure up-to-date to ensure security patches are applied and deployed in a timely manner.
<hr /><p>Security Advisory: Addressing Recent Vulnerabilities in Angular was originally published in Angular Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>