New Angular Vulnerabilities Expose XSS, XSRF Token Leakage, and SSR Data Leaks Across Multiple Versions

Overview of the Vulnerabilities

The recent disclosure of CVE-2025-66412, CVE-2025-66035, and CVE-2025-59052 has raised new concerns for teams maintaining Angular applications, particularly those running long-lived versions of the framework. While Angular has historically reported few vulnerabilities, these findings highlight previously unexamined areas of the platform that can introduce significant risk.

These issues do not indicate a sudden drop in Angular’s security posture. Instead, they demonstrate how subtle logic flaws, sanitization gaps, and server-side design patterns can remain dormant until broader security research focuses on them. Below is a breakdown of each vulnerability and what it means for affected applications.

‍

CVE-2025-66412 — Stored XSS in SVG/MathML Attributes

CVE-2025-66412 is a Stored Cross-Site Scripting (XSS) vulnerability rooted in Angular’s template compiler. Angular uses an internal security schema to determine which attributes require strict sanitization. Several SVG and MathML attributes were not classified correctly, allowing JavaScript URLs and other malicious values to bypass sanitization entirely.

A related issue affects SVG animation elements (animate, set, animateMotion, animateTransform), where the attributeName property was not properly validated. Attackers can leverage these attributes to target sensitive fields such as href or xlink:href, enabling arbitrary script execution during user interaction or during an animation trigger.

‍

CVE-2025-66035 — XSRF Token Leakage via Protocol-Relative Requests

CVE-2025-66035 is a high-severity vulnerability affecting Angular’s XSRF protection. Angular’s HttpClient interceptor is designed to append an XSRF token to same-origin requests. However, the origin-checking logic incorrectly treated protocol-relative URLs (//example.com) as same-origin.

As a result, Angular would attach the user’s real XSRF token to attacker-controlled domains, enabling authenticated CSRF actions against the victim’s account. This vulnerability affects any application using Angular’s built-in XSRF mechanism and issuing protocol-relative requests.

‍

CVE-2025-59052 — Server-Side Rendering Race Condition

CVE-2025-59052 exposes a race condition in Angular’s server-side rendering (SSR) implementation. Angular’s SSR platform reused a shared injector across concurrent requests, causing leaked state between users. Under load, data from User A could appear in User B’s rendered response.

This issue affects several SSR-related packages and may appear even in local development environments. Updated releases redesign how the SSR platform is bootstrapped to ensure requests remain isolated.

‍

Recommended Remediation

We recommend following the remediation guidance provided in the official vulnerability database and Angular project releases:

• Upgrade to the patched OSS Angular versions that address all three vulnerabilities:
  
  • v21.0.2+, v20.3.15+, v19.2.17+ all have patches for CVE-2025-66412, CVE-2025-66035, and CVE-2025-59052.
• For applications running EOL Angular versions (4–18), apply fixes through HeroDevs Never-Ending Support (NES) for Angular, which provides backported security patches for every affected subsystem (template compiler, HttpClient XSRF interceptor, and SSR platform).
• To mitigate CVE-2025-66035 (XSRF token leakage):
  
  • Remove or update any protocol-relative requests (//domain.com) until the patched version is deployed.
• To mitigate CVE-2025-66412 (Stored XSS in SVG/MathML):
  
  • Avoid binding untrusted values to SVG, MathML, or animation attributes.
  • Audit templates for unsafe attribute usage.
• To mitigate CVE-2025-59052 (SSR race condition):
  
  • Ensure your SSR server platform uses the updated bootstrapping logic.
  • Verify that injectors are not shared across concurrent requests.
    
    

For the full vulnerability listings, visit the HeroDevs Vulnerability Directory for each CVE breakdown, affected versions, and fix status.

‍

Context for Angular Applications

Angular provides a broad application surface: a compiler, a templating system, a sanitization layer, SSR infrastructure, an HTTP client, and a developer tooling chain. These vulnerabilities highlight how interconnected these systems are and how a flaw in a single part (origin logic, security schema, or injector behavior) can cascade into user-impacting exposures.

Organizations using Angular in long-running environments — especially those operating regulated workloads — should ensure that security reviews, dependency upgrades, and patch backports are performed regularly rather than relying on historic assumptions of safety.

‍

Assessing Exposure

To determine your application’s potential risk:

• For CVE-2025-66412:
  Review any Angular templates that bind data into SVG or MathML elements, especially attributes such as href, xlink:href, or animation properties. Applications that bind untrusted values are most exposed.
  
  
• For CVE-2025-66035:
  Search for protocol-relative requests (//example.com). Any such request will cause Angular to attach the XSRF token, even if the domain is attacker-controlled.
  
  
• For CVE-2025-59052:
  If your application uses Angular SSR, validate that your server platform is not sharing injectors between requests. Applications under concurrent load are most likely to observe leakage.
  
  

Applications that do not use SVG/MathML bindings, do not rely on protocol-relative URLs, or do not implement SSR may be unaffected — but should still apply patched versions to maintain long-term security integrity.

‍

Risk Evaluation

While the exact likelihood of exploitation varies based on application architecture, user input pathways, and server-side configuration, these vulnerabilities are high-severity and affect core parts of the Angular platform. Token leakage, stored XSS, and cross-request data exposure each represent meaningful attack surfaces with potential real-world impact.

Organizations running unsupported Angular versions face the highest risk, as the community will not provide further fixes. We strongly recommend upgrading or applying backported patches through NES for Angular to minimize exposure.

‍