CVE-2023-51931: High ReDoS in urlite npm Package

CVE-2023-51931 is a high severity regular expression denial of service in the urlite npm package version 3.1.0, scored 7.5. A crafted string makes the parse function spin the CPU. No fixed release is confirmed, so cap URL length before parsing or switch to a maintained parser.

What's affected

CVE-2023-51931 affects alanclarke urlite, a small URL parsing library for JavaScript, in version 3.1.0. NVD published it on 2024-02-16 with a score of 7.5 (high) and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Only availability is affected.

The reporter's GitHub issue says the regular expression in lib/pattern.js is vulnerable to catastrophic backtracking and that a long crafted input made the parse function take about 17 seconds in their test. The issue was open when I read it, with no comments and no maintainer response, and I found no fixed version. The record's product list shows only 3.1.0 by name, so earlier releases may also be affected. That is unverified.

Check the project's releases and issue 61 before you decide; if a patched version appears, upgrade to it.

Weakness class: CWE-1333, CWE-20.

How to check if you're exposed

Find out whether urlite is in your dependency tree, directly or through another package. In an npm project:

npm ls urlite

For yarn, run yarn why urlite; for pnpm, run pnpm why urlite. Also search lockfiles and any vendored copies of the library:

grep -rn "urlite" package.json package-lock.json yarn.lock pnpm-lock.yaml

Then find where your code calls the parser. If it only parses URLs you wrote yourself, exposure is low. If it parses URLs from request bodies, headers or user submitted links, treat it as exposed. Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan checks the open source packages you ship. It does not inspect appliance firmware or a vendor's closed product, so for this CVE the useful work is asset inventory and vendor follow-up.

What to do now

1. Run the dependency check above in each repository and in the images you deploy, so transitive copies are not missed.
2. If urlite parses untrusted input, add a length limit on the string before it reaches the parser. Rejecting very long URLs early removes the long inputs that trigger the slowdown.
3. Consider replacing urlite with the URL class built into Node.js and browsers, or another maintained parser, if the project stays unpatched.
4. Set request timeouts and CPU limits on the service that parses URLs, so one slow request cannot block the whole process.
5. Subscribe to issue 61 and the package's release page, and upgrade when a fixed version is published.

Why it matters

The advisory tags CWE-1333 (inefficient regular expression complexity) and CWE-20 (improper input validation). A regular expression with nested or overlapping repetition can take exponentially longer as the input grows, because the matcher tries many ways to split the same text before it gives up.

In Node.js this matters more than in many runtimes. JavaScript runs your request handling on a single thread, so one expensive regex match stalls every other request on that process. A single crafted request can therefore cause an outage. The record's KEV flag is false, and I found no source reporting exploitation in the wild.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

GitHub issue 61 in alanclarke/urlite (fetched)

Reporter gist (listed in the record, not fetched)

NVD record for CVE-2023-51931 (the record this guide is built from)

Last reviewed: 19 October 2026.