Security
Jun 15, 2026

Angular's 2026 CVE Surge: 21 New Advisories, No Patches for EOL Apps

Angular CVE disclosures are accelerating, AI is driving the discovery, and end-of-life Angular versions are the most exposed software you run.

Give me the TL;DR
Angular's 2026 CVE Surge: 21 New Advisories, No Patches for EOL Apps
For Qualys admins, NES for .NET directly resolves the EOL/Obsolete Software:   Microsoft .NET Version 6 Detected vulnerability, ensuring your systems remain secure and compliant. Fill out the form to get pricing details and learn more.

For years, Angular was one of the calmer corners of the JavaScript ecosystem. In 2026, that calm ended: 21 security advisories have been published for Angular so far this year, 15 of them in a single two-week window between May 28 and June 10. Most affect end-of-life (EOL) versions that will never receive an upstream fix.

Angular is not an outlier. Spring recorded 37 CVEs in two months, more than the project saw in all of 2025, and another 66 Spring CVEs were published in the past week alone, bringing the total to more than 100 in the last four months. This is a structural shift in how vulnerabilities are found and reported, driven in large part by AI, and the frameworks that looked quiet for years are exactly the ones now under the most scrutiny. For supported versions, every new disclosure comes with a patch. For EOL versions, the disclosures keep coming and the patches never do.

Why are Angular CVEs suddenly increasing?

Strict templating, ahead-of-time compilation, and built-in sanitization meant Angular historically reported very few CVEs, far fewer than comparable frontend frameworks. That track record was real. But with new tooling pointed at the codebase, a wave of disclosures is arriving. One chart tells the story: a single advisory in 2022, eleven straight quarters of silence, and then a curve that bends sharply upward.

The inflection is visible. One CVE affecting EOL Angular in 2022. Then, in late 2025, three high-severity Angular CVEs landed in quick succession: CVE-2025-59052 (SSR request-data leakage, CVSS 7.1), CVE-2025-66035 (XSRF token exposure via protocol-relative URLs, CVSS 7.7), and CVE-2025-66412 (stored XSS in template compilation, CVSS 8.5). All three affect essentially every Angular version, but only versions 19, 20, and 21 received official fixes.

2026 has continued the trend. Already published this year:

  • CVE-2026-22610: XSS via unsanitized SVG script attributes in the Angular template compiler, affecting v18.x and earlier with no upstream fix for EOL versions.
  • CVE-2026-27970: XSS in the Angular i18n pipeline, where unsanitized HTML in translated ICU messages can execute arbitrary JavaScript.
  • CVE-2026-32635: XSS in i18n attribute bindings (CVSS 8.6, High), where internationalizing a sensitive attribute such as href bypasses Angular's sanitization.

And the pace is accelerating. Between May 28 and June 10, 2026, the Angular team published 15 more security advisories: 10 with CVE IDs assigned and 5 so new that CVE records are still pending. Every one of them follows the same pattern, with fixes shipping only to currently supported versions.

Where a CVE ID is marked pending, the Angular team has published the security advisory but the corresponding CVE record has not yet appeared in NVD or cve.org. As each is confirmed in authoritative sources, it will appear in the HeroDevs Vulnerability Directory.

Because these are Angular vulnerabilities, they are exploitable in the user's browser, at the SSR layer, or through the service worker that sits between the two, and most affect EOL versions that will never receive an upstream fix.

Do organizations run end-of-life Angular?

It would be reassuring to assume that EOL versions have aged out of production. The download data says otherwise. In the week ending June 10, 2026, @angular/core was downloaded about 5.9 million times from npm, and nearly half of those downloads, 48%, were for EOL major versions (v19 and earlier). That is roughly 2.9 million weekly installs of Angular versions that no longer receive security patches. Angular 9, which reached end of life in 2021, still accounts for almost 7% of all @angular/core downloads on its own.

Frontend frameworks are exceptionally sticky, because the framework is woven through the application's UI rather than sitting behind it. The same curve played out with Angular's predecessor: years after AngularJS (1.x) reached end of life, it is still shipped to real users' browsers every day. And the EOL population keeps growing. Angular 19 reached end of life on May 19, 2026, which means every Angular 19 application moved to the unsupported side of the line just as the June advisory batch landed without fixes for it.

What are the real risks of running EOL Angular?

The exposure runs along three lines at once.

Security. An EOL Angular version is a supply chain exposure that ships to the client in every application bundle. Each newly disclosed XSS or sanitizer bypass is a live, unpatched path to credential theft, session hijacking, or DOM manipulation, with no upstream remediation coming.

Compliance. Auditors do not grade on intent. FedRAMP (NIST SI-2), SOC 2, DORA, GDPR Article 32, and NIS2 all expect known vulnerabilities to be patched within a defined window. EOL software cannot meet a "must be patched" requirement, which turns an audit finding into one with no remediation path.

Business continuity. A rushed major-version migration under audit or breach pressure means breaking API changes, deep refactoring, and compressed regression testing, and that is how production breaks. Doing nothing leaves the door open to an exploited CVE and the breach costs that follow. Either path threatens the continuity of the business the software was built to run.

How is AI changing the way vulnerabilities are discovered?

The Angular surge is not random, and it will not slow down, because the way vulnerabilities get found has changed. AI has moved from passive coding assistant to active, autonomous vulnerability researcher. Google's Project Zero and DeepMind built Big Sleep, an agent that found a previously unknown, exploitable bug in SQLite before it shipped. Microsoft used Security Copilot to uncover vulnerabilities in open source bootloaders that had survived years of human review. And this month, Anthropic announced Claude Mythos 5, which it describes as having the strongest cybersecurity capabilities of any model in the world, alongside Claude Fable 5, a guardrailed public counterpart built to limit offensive misuse.

The point is not which vendor's tool found what. The point is that mature, widely deployed codebases that survived years of human review are now being re-examined at machine scale. It happened to Spring. It is happening to Angular now.

Why is the gap between CVE disclosure and patching so dangerous?

A published CVE is a double-edged artifact. For defenders it is a warning. For attackers it is a roadmap: a precise description of where the weakness is and, increasingly, enough detail to build a working exploit. The same AI capabilities that help defenders find bugs also help adversaries develop exploits faster, a trend Google's threat intelligence team has documented.

For supported software, the defense is straightforward: a patch ships, you apply it, the window closes. EOL software breaks that model. There is no upstream patch, so the window does not close. It stays open for every newly disclosed vulnerability, indefinitely, and the AI-driven acceleration means more such vulnerabilities will keep arriving.

How does NES for Angular close the EOL security gap?

This is the gap NES for Angular was built to close. The HeroDevs team is stepping up to the challenge of an increasing number of CVEs across EOL versions 4 through 19.

NES for Angular addresses all three exposure lines directly. On security, HeroDevs delivers ongoing CVE fixes across all severity levels for the exact versions the Angular team no longer patches. On compliance, once NES is installed, open audit findings convert into closed ones backed by HeroDevs committed patching SLAs. On business continuity, NES removes the EOL deadline and buys back the one thing teams never have: time to migrate right, on their own schedule, instead of migrating fast under pressure.

The economics are the easy part. A NES subscription is a fraction of the cost of an emergency engineering sprint, and far less than the downstream cost of a breach.

What should you do if you're running EOL Angular?

The AI-driven surge in vulnerability discovery is not a future problem. It is already reshaping disclosure rates across the ecosystem, and the frameworks that looked quiet for years, Angular among them, are exactly the ones seeing the most new scrutiny. For supported versions, keep upgrading on the upstream cadence. For the EOL Angular versions still running in production, where no upstream patch is coming, the exposure is permanent until it is remediated.

If your organization depends on Angular versions 4 through 19, see NES for Angular. It closes the security gap, the compliance gap, and the migration-timeline gap at once, so a discovery that lands tomorrow does not become an incident you are explaining to executives and regulators next quarter.

Table of Contents
Author
Javier Perez
Technical Product Owner & Manager - Javascript
Open Source Insights Delivered Monthly