Safeguard
Open Source

Is the npm Luxon Package Safe to Use? A Security Review

The npm Luxon package is actively maintained and safe for current use, with one notable historical ReDoS advisory to be aware of. Here is the security picture.

Yukti Singhal
Security Analyst
5 min read

The npm Luxon package is a well-maintained, safe-to-use date and time library, with one historical vulnerability, a regular-expression denial-of-service issue fixed years ago, that you only need to worry about on very old versions. Luxon is the modern successor to Moment.js from the same maintainers, and if you are choosing a date library today it is a reasonable pick from a security standpoint. This review covers what the one real advisory was, which versions are affected, and how to use luxon npm safely.

What Luxon is and why people use it

Luxon is a JavaScript library for working with dates, times, time zones, and durations, built on the browser's Intl API. It is a common replacement for the now-legacy Moment.js because it is immutable, has a cleaner API, and does not carry Moment's large bundle and mutable-object footguns. Because it handles user-supplied date strings, its parsing routines are exactly the kind of code that deserves a security look.

The one advisory worth knowing: CVE-2023-22467

The notable known vulnerability in Luxon is CVE-2023-22467, a regular-expression denial-of-service (ReDoS) issue. Prior to versions 1.38.1, 2.5.2, and 3.2.1, Luxon's DateTime.fromRFC2822() method had quadratic (N-squared) time complexity on certain crafted inputs. An application that passed untrusted data into that method could be pushed into a (re)DoS condition, where a single malicious string ties up the event loop long enough to degrade or stall the service.

The fix shipped across all three maintained branches: version 1.38.1 for the 1.x line, 2.5.2 for the 2.x line, and 3.2.1 for the 3.x line. If you are on any version at or above the fix for your major line, this advisory does not apply to you.

Are you affected?

Check your resolved version, not just your declared range:

npm ls luxon

If the resolved version is below 1.38.1, 2.5.2, or 3.2.1 depending on your major line, and your code passes user-controlled strings to DateTime.fromRFC2822(), you are exposed to the ReDoS. The remediation is a straightforward upgrade:

npm install luxon@latest

Luxon follows semver reasonably well, so moving to the latest 3.x release from a patched 3.x version is low-risk. Jumping across major versions (1.x to 3.x) requires reading the migration notes, but the security-relevant change is small.

Maintenance status

Luxon's maintenance health is good. The project ships releases on a healthy cadence, the most recent version at the time of writing was released in September 2025, and it is not deprecated. It has a small maintainer team, which is typical for focused utility libraries and not a red flag on its own. For a dependency you will keep for years, an actively released, non-deprecated package is what you want to see.

That said, a healthy status today does not remove your obligation to watch it. Any parser-heavy library can pick up a new ReDoS or logic issue, so keep it in whatever dependency-monitoring you already run. An SCA tool will surface a new luxon advisory automatically rather than relying on you to check manually.

Safe usage patterns

Beyond staying patched, a few habits reduce risk when handling untrusted date input with any library, Luxon included:

  • Validate and bound input length before parsing. A date string does not need to be thousands of characters; reject absurd lengths early.
  • Prefer explicit format parsing (DateTime.fromFormat with a known pattern) over permissive parsers when you control the expected format, so malformed input fails fast.
  • Wrap parsing of external data in error handling and check .isValid rather than assuming a DateTime came back usable.
  • Treat any method that accepts free-form strings from users as a potential DoS surface and keep those code paths patched.

How Luxon compares as a choice

From a security lens, Luxon compares favorably to alternatives. Moment.js is in maintenance mode and its maintainers explicitly recommend against new projects. date-fns and the newer Temporal API are also reasonable, each with their own trade-offs. Luxon's single well-scoped historical advisory, promptly fixed across all branches, is a good track record for a library that parses untrusted input. If you want the broader decision framework, our dependency selection material in the Academy covers how to weigh maintenance, advisory history, and bundle size together.

FAQ

Is npm luxon safe to use in 2025 and beyond?

Yes. Luxon is actively maintained, not deprecated, and free of known unpatched vulnerabilities on current versions. The one notable advisory, CVE-2023-22467, was fixed years ago. Stay on a patched version (at least 1.38.1, 2.5.2, or 3.2.1 for your major line) and keep it monitored.

What was CVE-2023-22467 in Luxon?

A regular-expression denial-of-service issue in DateTime.fromRFC2822(), which had quadratic complexity on certain inputs before versions 1.38.1, 2.5.2, and 3.2.1. Passing untrusted strings to that method on an unpatched version could cause a ReDoS. Upgrading resolves it.

How do I check which Luxon version I have?

Run npm ls luxon to see the resolved version in your dependency tree, which is what actually runs rather than the range in package.json. If it is below the fix for your major line, run npm install luxon@latest.

Is Luxon better than Moment.js for security?

For new projects, yes. Moment.js is in maintenance mode and its own maintainers recommend against using it for new work. Luxon is actively developed by the same team, immutable by design, and has a clean advisory history, making it the safer modern choice.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.