CVE-2017-18214 is a regular expression denial of service (ReDoS) vulnerability in Moment.js versions before 2.19.3, caused by a date-parsing regex that used unbounded quantifiers and could be forced into catastrophic backtracking. A crafted date string of around 50 kilobytes could make the vulnerable regex take multiple seconds to evaluate, which is enough to tie up a single-threaded Node.js process handling that request. What makes this CVE worth a closer look isn't the bug itself — it's how often it still shows up in scans of codebases years after the fix shipped.
What actually made the regex vulnerable?
The vulnerable regex used quantifiers like [0-9]* and unbounded character-class repetition without an upper bound, which meant certain crafted inputs forced the regex engine into exponential backtracking while trying to match. This is the classic ReDoS pattern: a regex that looks harmless on normal input but has pathological worst-case behavior on adversarial input, and date-parsing libraries are a common place to find it because they often accept loosely-formatted strings and try multiple parsing patterns against them. The maintainers' fix replaced the unbounded quantifiers with explicit bounds (capping repetition at a fixed length like 256 characters), which eliminates the exponential blowup without changing normal-case parsing behavior.
Why do severity scores for this CVE disagree?
NVD's CVSS v3.1 score for this CVE is 7.5 (High), while Snyk's own internal severity rating for the same issue is notably lower, around 3.7. This kind of disagreement happens because CVSS scoring and a vendor's contextual risk scoring weigh different things — NVD's score reflects the theoretical worst case (a single request tying up a process for seconds), while a vendor's practical score can account for how narrow the exploitation window typically is in real deployments. Neither number is "wrong"; they're measuring slightly different questions, and it's worth checking both rather than anchoring on just one severity source.
Why does a 2017 fix still show up in scans today?
It shows up because Moment.js itself was declared a legacy project in maintenance mode by its own maintainers in 2020, and it remains deeply embedded as a transitive dependency in old lockfiles, bundled minified assets, and applications that were built years ago and never revisited. A JavaScript vulnerability scanner scanning an old package-lock.json or a vendored moment.min.js file will correctly flag a pre-2.19.3 copy sitting untouched since initial project setup — the CVE is old, but the vulnerable code is often still physically present in the codebase. It's also tracked under a separate GitHub Security Advisory ID alongside the CVE number, so some scanners can surface what looks like two findings for the same underlying issue.
How do you actually clear this finding?
Upgrade to Moment.js 2.19.3 or later if you're still using the library, or — since Moment itself is in maintenance mode — consider whether a currently-maintained alternative (date-fns, Luxon, or the native Intl API) better fits a project starting fresh. For an existing codebase where Moment is deeply embedded, the version bump alone resolves this specific CVE without requiring a full library migration.
FAQ
Is Moment.js still safe to use at all?
The library's own maintainers recommend against using it in new projects since 2020, though existing usage on a patched version isn't itself dangerous — it's a maintenance and long-term-support concern more than an active security emergency.
Does upgrading to 2.19.3 require code changes?
No — it's a patch-level release that fixed the vulnerable regex internally, without changing Moment's public API, so it's typically a safe, drop-in upgrade.
Why does this CVE keep appearing after we already fixed it once?
Check for bundled or vendored copies of an old Moment version sitting in a separate part of the codebase, or a transitive dependency pinning an old version independently of your direct package.json entry — both are common reasons a "fixed" CVE reappears in a later scan.
Is a ReDoS vulnerability as serious as a remote code execution CVE?
Generally no — ReDoS causes denial of service (a hung process or slow response), not code execution or data exposure, which is part of why severity ratings for this class of bug vary more than they do for RCE-class vulnerabilities.