CVE-2026-59887

What it actually does

This is an algorithmic denial-of-service flaw in the linkify-it link-recognition library before version 5.0.2. When applications call .test() or .match() on attacker-controlled text, the mailto: schema validator may be invoked for each mailto: occurrence and repeatedly scan the remaining input through the email-name matching logic in lib/re.mjs. A specially crafted string with many mailto: occurrences can therefore cause quadratic CPU consumption, tying up the Node.js event loop or equivalent application worker and reducing availability. The issue does not provide confidentiality or integrity impact by itself; the primary impact is resource exhaustion.

Why it matters to the business

Applications that automatically detect links in user-supplied text, messages, comments, tickets, documents, chat content, or API-submitted text may become slow or unavailable when processing crafted input. Because exploitation is network-accessible, requires no authentication, and has low complexity, internet-facing services that parse untrusted text are the highest risk even though public exploitation is not currently indicated by KEV status or exploit maturity. The low EPSS score suggests broad exploitation is not expected at this time, but the operational impact can still be significant for heavily used services because a small number of malicious requests may consume disproportionate CPU.

How an attack unfolds

An attacker identifies an application feature that accepts arbitrary text and runs linkify-it against it, such as a message body, comment field, profile text, markdown renderer, support ticket, or content ingestion API. The attacker submits text deliberately containing many mailto: schema occurrences arranged so that each occurrence triggers the mailto validator and causes the library to scan a large remaining portion of the input. On vulnerable versions, repeated validator invocations create quadratic CPU work. If the application processes the input synchronously, workers or the event loop can be blocked, causing request latency, timeouts, autoscaling events, or service unavailability. The attack does not require the attacker to read data or alter application state; its objective is exhausting processing capacity.

How to fix it

Upgrade linkify-it to version 5.0.2 or later wherever it is used, including direct and transitive dependencies. If exact package inventories are unavailable, review package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls linkify-it, and software composition analysis results for vulnerable versions below 5.0.2. Rebuild and redeploy applications after updating dependencies. As compensating controls, enforce maximum input sizes for text passed to linkification routines, apply request rate limits, isolate expensive text parsing from request-critical paths, set processing timeouts where feasible, and consider disabling mailto: link recognition for untrusted high-volume inputs until upgraded.

How to confirm the fix worked

Confirm that deployed artifacts resolve linkify-it to version 5.0.2 or later, not only that source manifests were changed. Validate lockfiles and runtime dependency trees using package-manager commands such as npm ls linkify-it or equivalent tooling. Run a controlled performance regression test against representative text containing repeated mailto: occurrences and verify CPU time scales acceptably and does not block application workers. For internet-facing services, test that input-length limits and rate limits are enforced before linkification. Monitor post-deployment application CPU, request latency, timeout rates, and worker restarts for regression.

Typical attack path

1. Find an exposed feature or API that accepts user-controlled text and performs automatic link detection.
2. Confirm the application processes mailto: links through linkify-it .test() or .match().
3. Submit unusually large text containing many repeated mailto: occurrences or mail-like fragments designed to maximize validator work.
4. Repeat requests or send concurrent submissions to keep CPU-bound workers busy.
5. Observe degraded response times, request timeouts, elevated CPU, queue buildup, or application restarts.

How to detect it

Look for evidence of resource-exhaustion attempts against endpoints that accept or render user-supplied text. Useful sources include HTTP access logs, API gateway logs, WAF logs, application logs, APM traces, Node.js event-loop lag metrics, container CPU metrics, process restart logs, load balancer timeout logs, and error reporting systems. Focus on large request bodies or parameters containing repeated mailto: strings, especially when followed by high CPU, long request durations, 499/502/503/504 responses, application timeouts, event-loop delay alerts, or worker restarts. If request bodies are not logged, use WAF/API gateway sampling, reverse-proxy debug logs in a controlled manner, or application-level telemetry that records payload size and linkification duration without storing sensitive content. For forensic review, correlate timestamps of CPU saturation with requests to text-submission endpoints and inspect dependency manifests in the running artifact to determine whether linkify-it below 5.0.2 was present at the time.

• mailto:
• linkify-it
• node_modules/linkify-it/lib/re.mjs
• node_modules/linkify-it/package.json
• "linkify-it": "5.0.0"
• "linkify-it": "5.0.1"
• event loop delay
• request timeout
• upstream timed out
• 504 Gateway Timeout
• 503 Service Unavailable
• JavaScript heap out of memory
• npm ls linkify-it

What your security team should do

• Inventory applications that perform automatic link detection or render user-controlled text and determine whether they use linkify-it before 5.0.2.
• Prioritize upgrades for internet-facing, unauthenticated, or high-volume services that process comments, messages, tickets, documents, or API-submitted text.
• Update linkify-it to 5.0.2 or later and rebuild/redeploy affected applications from clean dependency locks.
• Add or verify maximum text-size limits before linkification and rate limits on endpoints that accept arbitrary text.
• Create monitoring for repeated mailto: strings in large request bodies, spikes in CPU, elevated request duration, event-loop lag, 5xx responses, and worker restarts.
• Review recent logs for suspicious large inputs containing many mailto: occurrences, especially if they correlate with CPU saturation or timeouts.
• Because this issue is not listed in CISA KEV and has low EPSS at this time, handle it through expedited dependency remediation rather than emergency incident response unless exploitation indicators are present.