CVE-2022-25844 is a regular-expression denial-of-service (ReDoS) vulnerability in AngularJS, published on April 21, 2022, that affects the angular npm package at version 1.7.0 and above. It carries a CVSS 3.1 base score of 7.5 (High), and the catch that makes it awkward to close is simple: AngularJS is end-of-life, so there is no fixed release to upgrade to. If you still ship a front end built on AngularJS 1.x, this is one of several dependency risks you inherit whether you touch the code or not.
What CVE-2022-25844 actually does
The vulnerability lives in AngularJS's number-formatting logic. When the framework builds a currency or number filter, it reads locale rules from NUMBER_FORMATS.PATTERNS. An attacker who can supply a custom locale rule controls the posPre value in NUMBER_FORMATS.PATTERNS[1].posPre. That value is spliced directly into a regular expression without any length check.
Regular expressions built from unbounded, attacker-influenced input are the classic setup for catastrophic backtracking. Feed the engine a posPre string with an extremely large value and the resulting regex takes exponential time to evaluate against certain inputs. The single thread running the Node or browser event loop stalls, and legitimate requests pile up behind it. That is the whole DoS: no memory corruption, no code execution, just a regex that never finishes.
The weakness maps to CWE-1333 (Inefficient Regular Expression Complexity). It is network-exploitable, needs low attack complexity, requires no privileges, and needs no user interaction, which is why the score lands at 7.5 rather than something lower.
Which versions are affected
Public advisories list the vulnerable range as AngularJS 1.7.0 and higher. In npm terms that is the angular package (the 1.x line), not the modern @angular/* scoped packages that make up Angular 2+. This distinction trips people up constantly. Angular (the TypeScript framework, version 2 and later) is a full rewrite and is not affected by this CVE. AngularJS (the original 1.x framework) is what CVE-2022-25844 targets.
To check whether you are exposed, look at what your lockfile resolves:
npm ls angular
If that returns something like angular@1.8.3, you are in the affected range. A transitive pull is just as real as a direct dependency, so do not assume you are clear because your package.json does not name angular directly.
Why there is no upstream fix
AngularJS reached the end of its long-term support period at the end of 2021. The Angular team stopped shipping patches, including security patches, after that date. The npm angular package is effectively deprecated. So unlike a normal CVE where the answer is "bump to the patched version," CVE-2022-25844 has no vendor release that closes it. Vulnerability scanners will keep flagging it because, from the ecosystem's point of view, the fix does not exist.
That leaves three realistic paths, in order of how much they actually solve the problem.
How to remediate CVE-2022-25844
Migrate off AngularJS. This is the only remediation that removes the risk rather than managing it. Moving to modern Angular, React, Vue, or Svelte eliminates every unpatched AngularJS CVE at once, not just this one. It is expensive, and for a large legacy app it is a quarters-long project, but the alternative is running an unmaintained framework indefinitely.
Use a commercial extended-support build. A few vendors sell patched AngularJS forks that backport security fixes past the official EOL. If you cannot migrate on a useful timeline and the app is business-critical, a supported fork buys you time and gives your scanner something to point at.
Constrain the exposure if neither is possible yet. CVE-2022-25844 only bites when an attacker can influence locale rules. Most applications hardcode a single locale and never expose NUMBER_FORMATS configuration to user input. If that describes your app, the practical exploitability is low even though the CVE is still present. Audit every place you set or merge locale data, make sure none of it derives from a request parameter, and document that analysis so an auditor understands why you are accepting the finding.
Whichever path you take, treat it as a tracked decision, not a silent one. An SCA tool such as Safeguard can flag CVE-2022-25844 transitively and let you record an accepted-risk justification against the finding, so the next scan does not re-open the same conversation.
Where AngularJS CVEs hide in a modern build
The reason this bug outlives so many migration plans is that AngularJS ends up as a transitive dependency of things nobody thinks of as "AngularJS apps." Legacy admin dashboards, embedded reporting widgets, white-labeled portals from acquisitions, and old build tooling all drag angular 1.x into node_modules. Because the package installs cleanly and the app runs, the risk stays invisible until a scan surfaces it.
Generate a software bill of materials on every build and diff it over time. A dependency that appears out of nowhere after a routine npm update of some unrelated tool is exactly how EOL frameworks sneak back into a codebase you thought you had cleaned. If you want a deeper walkthrough of the broader class, our JavaScript security vulnerabilities guide covers ReDoS alongside the other patterns worth scanning for.
FAQ
Is CVE-2022-25844 exploitable in every AngularJS app?
No. It only triggers when an attacker can supply a custom locale rule that influences the posPre value used to build a number-formatting regex. Apps that hardcode their locale and never expose that configuration to untrusted input have low practical exposure, though the vulnerable code is still present and will still be flagged.
Does upgrading AngularJS fix CVE-2022-25844?
There is no fixed release. AngularJS went end-of-life at the end of 2021, so no official patch exists. The durable fix is migrating off AngularJS entirely, or using a commercially supported extended-support fork if migration is not yet feasible.
Does CVE-2022-25844 affect modern Angular (2+)?
No. The bug is specific to AngularJS 1.x, distributed as the angular npm package. The modern Angular framework (the @angular/* scoped packages, version 2 and later) is a separate codebase and is not affected.
How do I know if my project pulls in AngularJS?
Run npm ls angular to see whether your lockfile resolves the 1.x angular package, directly or transitively. Because it is often a transitive dependency of legacy tooling, checking the resolved tree matters more than reading package.json.