CVE-2020-7661

What it actually does

The url-regex package contains a regular expression that can exhibit catastrophic backtracking when evaluated against specially crafted, very long input. If an application passes attacker-controlled strings into url-regex matching logic, a single request or a small number of requests can consume excessive CPU in the Node.js process, blocking the event loop and causing denial of service. The flaw does not directly allow data theft, code execution, or privilege escalation; the primary impact is loss of availability.

Why it matters to the business

Applications that use url-regex on untrusted input can become slow or unavailable when targeted, affecting customer-facing services, APIs, background processors, and any workflow that parses user-supplied text for URLs. Because exploitation requires no authentication and public exploit knowledge exists, internet-exposed services that process arbitrary text are at higher operational risk, even though this issue is not listed in CISA KEV and is not known to be ransomware-associated.

How an attack unfolds

An attacker identifies an endpoint or workflow that accepts free-form text, URLs, messages, comments, metadata, or uploaded content that is later evaluated with url-regex. The attacker submits an unusually long crafted string designed to trigger worst-case regular-expression backtracking. When the application calls String.test, RegExp.test, match, or similar parsing logic using the vulnerable expression, the Node.js process spends excessive time evaluating the input. During that time, the event loop can be blocked, causing requests to queue, time out, or fail. Repeating the request, or sending several such requests concurrently, can sustain service degradation or outage.

How to fix it

There are no fixed versions listed for the affected url-regex package in the provided advisory data. Treat continued use as risky where untrusted input is processed. Prefer replacing url-regex with a maintained URL parsing or validation library that avoids vulnerable regular-expression behavior, or use platform URL parsers where appropriate. If replacement is not immediately possible, reduce exposure by enforcing strict maximum input lengths before regex evaluation, rejecting or truncating unusually long strings, avoiding regex checks on unauthenticated bulk input, applying request body limits and rate limits, and isolating expensive parsing into worker processes with execution timeouts. Review dependency manifests and lockfiles for direct and transitive use of url-regex and remove or override it where feasible.

How to confirm the fix worked

Confirm remediation by verifying that url-regex is no longer present in dependency manifests, lockfiles, or production bundles, or that all code paths using it enforce safe input-length limits before regex evaluation. Use dependency tooling such as npm ls url-regex, yarn why url-regex, pnpm why url-regex, software composition analysis, or SBOM review to identify remaining exposure. Perform controlled negative testing in a non-production environment with long URL-like strings to verify the service rejects input quickly and does not exhibit CPU spikes, event-loop stalls, worker restarts, or request timeouts. Validate that request-size limits, rate limits, and monitoring alerts are active for exposed endpoints that process free-form text.

Typical attack path

1. Identify an application feature that accepts attacker-controlled text or URL-like input.
2. Send a very long crafted string intended to trigger catastrophic backtracking in url-regex.
3. Cause the server-side Node.js process to spend excessive CPU time evaluating the vulnerable regular expression.
4. Repeat or parallelize requests to keep the event loop saturated.
5. Observe service latency, request timeouts, worker crashes, autoscaling pressure, or full denial of service.

How to detect it

Look for evidence of denial-of-service activity rather than a durable host compromise artifact. Relevant sources include web access logs, API gateway logs, load balancer logs, WAF logs, application logs, APM traces, Node.js process metrics, container or orchestrator restart events, and infrastructure CPU metrics. Hunt for requests with unusually large text parameters or request bodies that precede CPU saturation, event-loop lag, increased 5xx responses, upstream timeouts, worker crashes, or autoscaling events. In application telemetry, correlate spikes in CPU time with URL-detection or text-parsing functions. In web logs, compare payload sizes, request duration, response status, and source IP repetition. Since this is a ReDoS vulnerability, successful exploitation typically leaves signs such as long-running requests, blocked event loops, high CPU, timeout errors, and service restarts, not malware files or persistence artifacts.

What your security team should do

• Prioritize inventory of Node.js applications and packages for direct or transitive dependency on url-regex.
• Replace url-regex with a maintained safer alternative or remove URL-regex parsing where it is not strictly required.
• Add strict pre-regex input-length validation on all user-controlled text fields that may be parsed for URLs.
• Apply rate limiting, request body limits, and timeout controls to unauthenticated or public endpoints that process arbitrary text.
• Monitor Node.js services for high CPU, event-loop lag, request timeouts, worker restarts, and unusual spikes in long request payloads.
• Add regression tests for ReDoS-style long-input cases so future dependency or code changes do not reintroduce the weakness.
• Because public exploit information exists, treat internet-facing exposure as a near-term availability risk even without KEV listing.