CVE-2026-50170: Angular SSR Credential Caching & Data Leakage Vulnerability

Technical summary

The vulnerability resides in @angular/common's HttpTransferCache mechanism, which optimizes SSR hydration by serializing cached HTTP responses into the TransferState object embedded in the HTML document. The flaw is the absence of withCredentials flag inspection and Cookie header validation before caching. When a credentialed request executes during SSR—such as one bearing session cookies or Authorization headers—the response is cached and transferred without distinguishing it as user-specific. Upon HTML serialization, this cached state becomes part of the static markup. Any downstream cache that stores the rendered HTML (CDN, reverse proxy, browser cache headers permitting) will serve the same HTML—including the previous user's response data—to subsequent clients. This creates a cross-user information disclosure channel. The fix, available in the patched versions listed, enforces credential-aware caching decisions in the HttpTransferCache implementation.

Business impact

For organizations deploying Angular SSR applications, this vulnerability poses a direct risk to user privacy and data confidentiality. Customer-sensitive data—authentication tokens, personalized settings, PII—could leak from one user session to another if your infrastructure includes any caching layer between your Angular SSR server and clients. This exposure is particularly acute in multi-tenant environments or high-traffic sites where cache hit rates are common. Beyond regulatory fines under GDPR, CCPA, or similar frameworks, unauthorized data disclosure damages customer trust and creates incident response costs. Applications not using SSR or not enabling hydration are not at risk.

Affected systems

Angular applications running versions prior to 22.0.0-rc.2, 21.2.15, 20.3.22, or 19.2.23 are affected, but only if both Server-Side Rendering and hydration are enabled. Framework consumers using older Angular versions (19.x through 22.0.0-rc.1) without SSR/hydration enabled are not vulnerable. The @angular/common package is the affected component; all applications depending on it with SSR+hydration active should be assessed.

Exploitability

Exploitation requires no special technique or authentication—it is passive and automatic. Any credentialed HTTP request made during SSR is vulnerable to caching by default; no attacker action is needed to trigger the flaw. However, actual data leakage depends on presence of a caching layer between your SSR server and clients. In architectures without CDN, reverse proxy, or shared cache (direct server-to-browser delivery only), the risk is lower. In typical enterprise deployments with Cloudflare, Nginx reverse proxies, AWS CloudFront, or similar caching infrastructure, the vulnerability is easily exploitable and likely to manifest. The CVSS score of 7.5 reflects high-severity information disclosure with network-accessible attack vector, low attack complexity, and no privileges or user interaction required.

Remediation

Upgrade Angular to a patched version immediately: 22.0.0-rc.2 or later, 21.2.15 or later, 20.3.22 or later, or 19.2.23 or later, depending on your current minor version. Verify compatibility with your application before deploying to production. As an interim measure on unpatched systems, consider disabling client-side hydration if operationally feasible, or disable SSR entirely; however, these workarounds sacrifice performance benefits and should only be temporary. Review your caching policy: ensure that cache headers on SSR responses exclude credentialed responses or reduce cache TTL for authenticated traffic. Conduct a forensic review of application logs and cache logs to determine whether credentialed responses were cached and served to other users during the vulnerable period.

Patch guidance

Apply updates in order of availability: upgrade @angular/common and related Angular framework packages to one of the fixed versions (22.0.0-rc.2+, 21.2.15+, 20.3.22+, or 19.2.23+). Test in a staging environment, particularly validating that SSR and hydration still function correctly and that no performance regression occurs. For organizations on extended support or LTS versions, confirm your specific version is listed in the Angular security advisory. If your version is no longer receiving updates, plan a broader framework upgrade. Coordinate the release to minimize downtime if your application is high-traffic.

Detection guidance

Monitor for signs of credential leakage: review CDN and reverse proxy cache logs for patterns where the same HTML response (identifiable by content hash or ETag) is served to multiple users within a short timeframe. Audit TransferState serialization in your SSR output—inspect the HTML source for cached HTTP response bodies in the transfer state script tag and check whether those responses contain user-specific or sensitive fields (e.g., 'user', 'email', 'token', 'session'). Enable verbose logging on your HttpClient to track which requests include credentials (withCredentials: true) and correlate those with what appears in TransferState. Search application security logs and user reports for anomalies: users seeing other users' data, unexpected account details, or session leakage. Implement runtime instrumentation to flag when a credentialed request is about to be cached in TransferState.

Why prioritize this

This vulnerability should be patched urgently. The combination of high CVSS (7.5), ease of exploitation (automatic, no user action), broad applicability (any Angular SSR application), and severe impact (multi-user data leakage) creates immediate and material risk. Unlike vulnerabilities requiring attacker effort or rare conditions, this flaw is triggered by normal operation in common deployment architectures. The fact that it is not yet on the KEV catalog does not lower the actual risk; it reflects recency rather than severity. Apply patches within 1–2 weeks, and conduct a forensic review of production logs for evidence of exploitation during the vulnerable window.

Risk score, explained

The CVSS v3.1 score of 7.5 (HIGH) is assigned on the basis of: Attack Vector=Network (exploitation is trivial from the internet), Attack Complexity=Low (no special setup required), Privileges Required=None (unauthenticated attacker can trigger the leak), User Interaction=None (automatic during normal SSR operation), Scope=Unchanged (impact is limited to confidentiality of cached data), Confidentiality=High (user-specific private data is disclosed), Integrity=None (no data modification), Availability=None (no service disruption). The score does not account for the conditional nature of actual leakage (requires a caching layer), but reflects the intrinsic severity of the vulnerability itself.

Frequently asked questions