When “No CVEs” Isn’t a Security Guarantee: What the Latest Angular Vulnerabilities Reveal About Open-Source Risk

For many teams building on Angular, the framework’s historically quiet vulnerability record seemed to suggest a high degree of stability and maturity. Angular is made by an amazing team of engineers, has a strong enterprise backing it, and went years without any major CVEs - for many organizations, that was interpreted as evidence of strong inherent security.

But in the span of a few weeks, three meaningful Angular vulnerabilities were disclosed:

• CVE-2025-66412: (High Severity) Stored XSS involving SVG/MathML and animation attributes
• CVE-2025-66035: (High Severity) XSRF token leakage via protocol-relative URLs
• CVE-2025-59052: (High Severity) Server-side rendering race condition leading to cross-request data exposure

These discoveries don’t indicate that Angular suddenly became insecure. Instead, they highlight something true across all open-source ecosystems:

A lack of published CVEs does not necessarily mean a lack of vulnerabilities. It often reflects how often the software is examined and how actively the community is reviewing it.

‍

Why “No CVEs” Can Be Misleading

1. Vulnerabilities can remain dormant simply because they are hard to find

Some issues, like the SSR race condition in CVE-2025-59052, stem from architectural assumptions that date back multiple versions. Race conditions, sanitization edge-cases, and cross-origin logic bugs are notoriously subtle. It’s common for such issues to go unnoticed until usage patterns shift or new research focuses on them.

2. Low disclosure volume often reflects limited security research, not flawless code

Angular is widely used but not always the primary focus of security researchers, who often gravitate toward browsers, Node.js, or newly emerging frameworks. Fewer researchers looking at a system naturally leads to fewer findings, regardless of the actual security posture.

3. Modern frameworks have expansive attack surfaces

Angular includes:

• a template compiler
• a sanitization and security context system
• a dependency injection framework
• server-side rendering
• an HTTP client with built-in protection layers
• a CLI and build chain

Any platform of this size and complexity will inevitably contain edge cases that require careful scrutiny, especially as standards evolve and usage patterns expand.

4. Vulnerabilities often surface in clusters once attention increases

Open-source projects frequently see waves of discoveries when either the community or focused researchers analyze a particular subsystem. The recent Angular disclosures are consistent with this pattern: once the ecosystem began looking more closely at certain areas, such as SSR and HttpClient, latent issues began to emerge.

‍

A Closer Look at the Recent Vulnerabilities

CVE-2025-66412: Stored XSS in SVG/MathML attributes

A Stored XSS flaw in Angular’s template compiler allows certain SVG and MathML attributes to bypass sanitization, enabling malicious JavaScript URLs to be injected. SVG animation elements also failed to validate attributeName, allowing attackers to target sensitive attributes like href. Together, these issues let untrusted data trigger arbitrary script execution.

CVE-2025-66035: XSRF token leakage

A flaw in Angular’s HttpClient XSRF interceptor caused protocol-relative URLs (starting with //) to be treated as same-origin. As a result, Angular attached the user’s XSRF token to attacker-controlled requests, exposing the token and allowing authenticated CSRF attacks. Any application using Angular’s built-in XSRF protection and making protocol-relative requests was vulnerable.

CVE-2025-59052: SSR race condition

A race condition in Angular’s server-side rendering system causes the shared platform injector to leak or overwrite state between concurrent requests, exposing rendered content or headers from one user to another. This issue affects several SSR-related packages and can impact apps even during local development. Updated versions fix the problem by changing how the server-side platform is bootstrapped.

‍

The Broader Lesson: Security Depends on Ongoing Review

These issues do not indicate a failure on Angular’s part. They illustrate a larger truth: security is not static, and no framework, no matter how mature, is immune to new discoveries. As applications grow in scale, adoption changes, and features like SSR become more widely used, new cases of vulnerabilities naturally surface.

Organizations maintaining Angular applications, especially long-lived ones, should not assume that a quiet CVE history equates to complete safety. Instead, the recent disclosures reinforce the value of:

• regular audits
• ongoing patching
• dedicated security review
• backports for older framework versions
• continuous maintenance
  
  

Frameworks evolve. Attack techniques evolve. Usage patterns evolve. Security must evolve alongside them.

‍

Final Thought

A framework without CVEs is not necessarily more secure, it may simply be less examined. The recent Angular disclosures serve as a reminder that security comes from active care, not from silence.

If you are in a position where upgrading to the newest version of Angular is not a feasible option, consider utilizing Never-Ending Support for Angular from HeroDevs. NES for Angular keeps your applications compliant, secure, and stable while you plan your migration – allowing you to control your roadmap. To learn more, contact us or explore pricing.