AngularJS End of Life & Support Options —
What To Do When AngularJS Patches Stop, Every Version's Date

AngularJS — the original Angular 1.x — reached end of life on December 31, 2021. Not a single version: the entire framework. Google stopped all development, bug fixes, and security patches that day, and there has been no official update since. That was more than four years ago, and AngularJS is still running quietly inside a remarkable number of production applications.

If you maintain an AngularJS app, this is the rare EOL with no "upgrade to the next version" path — there is no AngularJS 1.9. The only ways forward are a migration to a different framework or commercial extended support to keep the security patches coming. This page lays out the dates, the real risk level, and your actual options.

Key Dates at a Glance

• AngularJS 1.8 (final line): released 2020-06-04; end of life 2021-12-31
• AngularJS 1.7: end of life 2021-12-31
• AngularJS 1.6: end of life 2021-12-31
• AngularJS 1.5: end of life 2021-12-31

The One Date That Matters — December 31, 2021

Unlike most software, AngularJS does not have a staggered, per-version end-of-life schedule. Google committed to supporting AngularJS through a long-term support window that closed on December 31, 2021, and every release in the 1.x line — from 1.0 through the final 1.8.3 — reached end of life on that same day.

Since then, AngularJS has received zero official patches. Any vulnerability discovered in the framework after that date is disclosed publicly with no fix coming from the project. For a client-side framework that renders untrusted data and handles authentication flows, that is a standing, unmanaged exposure.

Every AngularJS Version and Its EOL Status

All AngularJS releases share the same end-of-life date. The final release, 1.8.3, shipped in April 2022 (a last security patch under the LTS window) and is the version most maintained apps run today.

Every AngularJS version, one line each

The same schedule as plain statements, one per release line, for anyone who needs a single date rather than a table. Every date is bound to the same data as the AngularJS product page, checked against the project's version support status page, and re-verified at each build. The 1.0 to 1.2 lines share one recorded release date because the project's published table starts there.

• AngularJS 1.8 — released June 4, 2020; end of life December 31, 2021.
• AngularJS 1.7 — released May 11, 2018; end of life December 31, 2021.
• AngularJS 1.6 — released December 8, 2016; end of life December 31, 2021.
• AngularJS 1.5 — released February 5, 2016; end of life December 31, 2021.
• AngularJS 1.4 — released May 27, 2015; end of life December 31, 2021.
• AngularJS 1.3 — released October 13, 2014; end of life December 31, 2021.
• AngularJS 1.2 — released November 23, 2013; end of life December 31, 2021.
• AngularJS 1.1 — released November 23, 2013; end of life December 31, 2021.
• AngularJS 1.0 — released November 23, 2013; end of life December 31, 2021.

How Dangerous Is Running EOL AngularJS, Really?

Here is where it pays to be precise rather than alarmist. AngularJS carries an EOL Risk Score™ of 50 out of 100 (live value, recalculated at every build). That number is worth understanding, because it cuts against the instinct to either ignore the problem or panic over it.

The live score is built from four factors: how long a version has been past end of life, its attack surface, whether it is named in CISA’s Known Exploited Vulnerabilities catalog, and whether extended support exists. For AngularJS the recency factor is at its maximum — it has been unsupported since the end of 2021 — while the attack-surface factor is medium rather than critical, and AngularJS is not currently listed in the CISA Known Exploited Vulnerabilities catalog. In plain terms: it is genuinely unpatched and the exposure compounds over time, but there is no evidence of active, large-scale exploitation in the wild today.

So the honest read is: this is a "plan your exit deliberately" situation, not a drop-everything emergency. The real risk isn't a known zero-day — it's the slow accumulation. Every month AngularJS goes unpatched, the gap between disclosed-but-unfixed vulnerabilities and your defenses widens, and AngularJS apps tend to sit in exactly the places attackers probe: customer-facing portals, admin consoles, and legacy internal tools.

AngularJS vs Angular — Why This Trips People Up

The naming is genuinely confusing, and it changes everything about your options. AngularJS is the original framework (versions 1.x), built around a different architecture entirely. Angular (version 2 and up — now well past version 20) is a complete rewrite Google released in 2016. They share a name and almost nothing else.

This matters because moving from AngularJS to modern Angular is not an upgrade — it is a rewrite. There is no in-place migration command; the component model, dependency injection, templating, and build tooling are all different. Teams that assumed "we'll just bump to Angular" discover a multi-month project, which is precisely why so many AngularJS apps never made the jump and are now stranded on EOL software.

Modern Angular has its own lifecycle, of course — each version gets roughly 18 months of support. If you do migrate, check the Angular EOL timeline so you don't land on a version that's already near its own end of life.

Your Three Options After EOL

Because there's no newer AngularJS to upgrade to, every path is a real decision with real cost. There are three:

• 01
  Migrate to a modern framework Rewrite the app in current Angular, React, Vue, or Svelte. This is the only permanent fix, but it's the most expensive — a full rewrite of a non-trivial AngularJS app is typically a multi-month effort. Best for applications with a long future and the budget to invest. Plan it; don't let an incident force it.
• 02
  Buy commercial extended support Specialist vendors publish security patches for end-of-life AngularJS, letting you keep the existing app secure and audit-compliant while you plan (or defer) a migration. This is the pragmatic bridge for teams that can't rewrite immediately — it converts an open-ended security liability into a managed, supported one. See extended-support options.
• 03
  Accept and isolate the risk If the app is low-value or scheduled for retirement, you may choose to run it unpatched — but do it deliberately: log it in your risk register, wrap it in compensating controls (a WAF, network segmentation, restricted access, enhanced monitoring), and set a decommission date. "Do nothing by default" is the one option that is never acceptable for software handling real data.

How to Reduce Risk Right Now

• 01
  Confirm what you're actually running Check your package.json or loaded scripts for angular at a 1.x version (e.g. 1.8.3). Don't confuse it with @angular/core — that's modern Angular. Run the Stack Scanner against your dependency file to surface AngularJS and everything else that's EOL in one pass.
• 02
  Put it on the risk register with a decision date Medium risk that's invisible becomes Critical risk that's a breach. Document the AngularJS exposure, assign an owner, and set a date by which you'll have chosen migrate, support, or retire. The decision is the deliverable.
• 03
  Add compensating controls while you decide A web application firewall, strict Content-Security-Policy headers, dependency-level subresource integrity, and tightened access controls all reduce the practical attack surface of an EOL front-end framework. They're a stopgap, not a fix — but they buy time without pretending the problem is solved.
• 04
  Don't forget the rest of the stack An app old enough to still run AngularJS usually has EOL company — an old Node runtime, an unsupported jQuery or Bootstrap, a dated build toolchain. Scan the whole dependency file so you're fixing the real risk surface, not just the framework you happened to notice.