CVE-2021-33502

What it actually does

The normalize-url Node.js package contains a regular expression denial-of-service weakness when processing specially crafted data: URLs. In affected versions before 4.5.1, 5.x before 5.3.1, and 6.x before 6.0.1, certain malformed or adversarial data: URL strings can trigger exponential regular-expression backtracking. If an application normalizes attacker-controlled URLs synchronously in a request path, a single crafted input can consume excessive CPU time and block the Node.js event loop, degrading or preventing service availability. The issue does not directly provide code execution, data disclosure, or privilege escalation; its impact is availability loss.

Why it matters to the business

Applications that accept and normalize user-supplied URLs may become slow or unavailable if an attacker sends crafted data: URL values. Because Node.js services often rely on a single event loop per process, CPU exhaustion in URL normalization can affect all concurrent users served by that process. Public APIs, link-preview services, webhooks, crawlers, redirect validation, content ingestion, and form-processing workflows are the most likely business-impact areas. The vulnerability is older, not listed in CISA KEV, has no known ransomware association, and has relatively low EPSS, but remediation is still important because the flaw is remotely triggerable without authentication where vulnerable URL normalization is exposed.

How an attack unfolds

An attacker first identifies an endpoint or workflow that accepts a URL-like value and passes it to normalize-url, such as a submitted website field, redirect parameter, webhook target, feed URL, profile link, import URL, or API payload. The attacker then submits a specially crafted data: URL designed to exercise the vulnerable regular expression path. When the application attempts to normalize that value, the regex engine performs excessive backtracking and consumes CPU for an abnormally long time. In a Node.js process, this can block the event loop, delaying unrelated requests and potentially causing upstream timeouts, health-check failures, process restarts, autoscaling events, or sustained service degradation if repeated. Exploitation requires no authentication if the affected input is publicly reachable, but it requires the vulnerable package version and a code path that normalizes attacker-controlled data: URLs.

How to fix it

Upgrade normalize-url to a fixed version appropriate for the dependency line: 4.5.1 or later for 4.x, 5.3.1 or later for 5.x, and 6.0.1 or later for 6.x. If consuming directly from the Git repository, use a version containing commit 305e3f22efb87505d3bc87c17c50b1ef67789acb or later. Regenerate lockfiles and redeploy all services that bundle the vulnerable package, including transitive consumers. Where immediate upgrade is not possible, reject or strictly limit data: URLs before calling normalize-url, enforce maximum URL length, apply request body and parameter size limits, use request timeouts, rate-limit unauthenticated URL-submission endpoints, and isolate CPU-heavy parsing from latency-sensitive request handlers. Do not rely on WAF filtering alone because payload details may vary and the vulnerable behavior occurs inside application-side parsing.

How to confirm the fix worked

Confirm that dependency manifests and lockfiles no longer resolve normalize-url to affected versions: any version before 4.5.1, 5.x before 5.3.1, or 6.x before 6.0.1 should be treated as vulnerable. Validate built artifacts and container images because JavaScript dependencies may be vendored or bundled during build. Run software composition analysis against package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and deployed images. Functionally test endpoints that accept URL input with benign long data: URL values and verify that requests are rejected quickly or handled within normal latency bounds. Monitor CPU utilization and event-loop delay under test to ensure malformed URL inputs cannot cause disproportionate processing time.

Typical attack path

1. Find a public endpoint, API, form, webhook, crawler, or import feature that accepts URL input.
2. Submit test values to determine whether data: URLs are accepted or processed.
3. Send a crafted data: URL that triggers catastrophic regex backtracking in vulnerable normalize-url versions.
4. Cause the Node.js process to spend excessive CPU time during URL normalization.
5. Repeat requests or distribute them across sources to sustain event-loop blocking and service degradation.
6. Observe application slowdowns, request timeouts, failed health checks, or process restarts as the denial-of-service effect.

How to detect it

This vulnerability causes denial of service rather than persistent compromise, so detection should focus on evidence of attempted or successful resource exhaustion. Review HTTP access logs, API gateway logs, load balancer logs, WAF logs, application logs, APM traces, and Node.js runtime telemetry for requests containing data: URL values, especially unusually long values or repeated submissions to URL-processing endpoints. Correlate those requests with spikes in CPU usage, event-loop lag, request latency, upstream timeouts, HTTP 408/429/499/500/502/503/504 responses, container restarts, process manager restarts, failed health checks, or autoscaling events. Examine application error logs for request timeout messages and performance traces showing time spent in URL normalization or regex processing. Because payloads may be URL-encoded or embedded in JSON bodies, decode request parameters and inspect body samples where retention and privacy policies permit. There are no widely reliable attacker-specific network indicators for this issue; detection is behavior- and payload-pattern based.

• data:
• %64%61%74%61%3A
• data%3A
• normalize-url
• package-lock.json
• node_modules/normalize-url/package.json
• "normalize-url"
• "version": "4.
• "version": "5.
• "version": "6.0.0"
• event loop lag
• Event loop delay
• request timeout
• upstream timed out
• HTTP 503
• HTTP 504

What your security team should do

• Inventory all applications and services using normalize-url directly or transitively, prioritizing internet-facing Node.js services that process user-supplied URLs.
• Upgrade normalize-url to 4.5.1+, 5.3.1+, or 6.0.1+ depending on the major version in use, and rebuild/redeploy affected services.
• Add input validation that rejects data: URLs unless explicitly required; if required, enforce strict length, media-type, and character constraints before normalization.
• Apply request-size limits, per-endpoint rate limits, and timeouts to unauthenticated URL-submission paths.
• Search historical logs for unusually long data: URL parameters, elevated request latency, HTTP 408/499/500/502/503/504 spikes, Node.js event-loop delay, and CPU saturation around URL-processing endpoints.
• Add dependency scanning gates so vulnerable normalize-url versions cannot be introduced through direct or transitive dependencies.
• Ensure production monitoring alerts on event-loop lag, high CPU, request queue depth, and repeated health-check failures for Node.js services.