CVE-2025-47279

What it actually does

Undici versions prior to 5.29.0, 6.21.2, and 7.5.0 can leak memory when an application repeatedly makes outbound HTTP/TLS requests to a server presenting an invalid certificate. The issue primarily affects Node.js applications that implement webhook, callback, URL-fetching, or user-configurable outbound request workflows using undici. Repeated failed TLS connection attempts can cause memory consumption to grow over time, potentially leading to process instability or termination due to out-of-memory conditions. The flaw does not provide code execution, data disclosure, or direct privilege escalation; the impact is limited to availability.

Why it matters to the business

An attacker who can register or influence webhook destinations may be able to degrade or interrupt affected Node.js services by causing them to repeatedly call a malicious HTTPS endpoint with an invalid certificate. The likely consequence is service slowdown, container restarts, failed background jobs, or temporary outage of systems that process outbound webhooks. Overall urgency is moderate to low because the CVSS score is low, EPSS is low, there is no known CISA KEV listing, no known ransomware use, and no mature public exploitation is reported; however, webhook-heavy or multi-tenant platforms should prioritize remediation because repeated retries can amplify the operational impact.

How an attack unfolds

An attacker first obtains the ability to configure, register, or otherwise influence a webhook-like endpoint that the application will call. They then host an HTTPS server using an invalid, self-signed, expired, mismatched, or otherwise untrusted TLS certificate. The attacker causes the application to invoke the webhook repeatedly, either by triggering events, abusing retry behavior, or submitting repeated requests that generate outbound callbacks. In vulnerable undici versions, each failed connection path can retain memory instead of releasing it fully. Over many attempts, memory usage rises until the Node.js process becomes slow, is killed by the runtime or container orchestrator, or crashes with an out-of-memory error. Successful exploitation requires repeated calls and a vulnerable outbound request path; it does not require the attacker to intercept traffic or compromise the server.

How to fix it

Upgrade undici to a patched release: 5.29.0 or later for the 5.x line, 6.21.2 or later for the 6.x line, or 7.5.0 or later for the 7.x line. If tracking source directly, use a version containing commit 9528f6853a72a637823e863f1dd12ec47a3fc9e7. Review direct and transitive dependencies because undici may be included through frameworks, SDKs, or Node.js HTTP clients. As a temporary mitigation, avoid repeatedly calling webhook endpoints after TLS/certificate failures, cap retry counts, add exponential backoff, enforce per-destination rate limits, and disable or quarantine webhook destinations that repeatedly fail certificate validation. Where feasible, validate webhook URLs at registration time, restrict outbound callbacks to approved schemes and destinations, and monitor memory limits for Node.js services.

How to confirm the fix worked

Confirm the installed undici version with package manager tooling such as `npm ls undici`, `pnpm why undici`, `yarn why undici`, or software composition analysis output, and verify that all resolved versions are 5.29.0, 6.21.2, 7.5.0, or newer within the applicable major version. Inspect lockfiles and container images to ensure older transitive copies are not still present. For source-based deployments, verify that the code includes commit 9528f6853a72a637823e863f1dd12ec47a3fc9e7 or an equivalent patched release. Functionally validate by exercising webhook failure handling against an endpoint with an invalid certificate and confirming that memory usage remains stable across repeated failed attempts and that retry limits/backoff stop repeated calls.

Typical attack path

1. Identify an application feature that sends outbound HTTP requests using undici, such as webhooks, callbacks, integrations, notifications, or URL validation.
2. Register or supply an attacker-controlled HTTPS URL as the webhook/callback destination.
3. Configure the attacker-controlled server with an invalid TLS certificate, such as self-signed, expired, hostname-mismatched, or untrusted-chain certificate.
4. Trigger application behavior that causes repeated outbound calls to that URL, including event generation or retry loops.
5. Cause repeated TLS validation failures in the vulnerable undici request path.
6. Allow memory usage in the Node.js process to increase until performance degrades, the process is restarted, or the service experiences an availability incident.

How to detect it

To determine whether exploitation may already have occurred, review application logs, webhook delivery logs, outbound proxy logs, egress firewall logs, TLS error logs, container/runtime events, and observability metrics for repeated outbound HTTPS attempts to the same destination followed by growing memory use or Node.js process restarts. Focus on patterns where webhook deliveries repeatedly fail because of certificate validation errors, especially when tied to newly created or suspicious webhook destinations. Correlate these failures with memory growth, garbage collection pressure, `JavaScript heap out of memory` crashes, container OOMKilled events, restart loops, elevated webhook retry volume, or degraded service health. Also review attacker-controlled or unusual webhook URLs registered shortly before memory spikes. There are no globally unique network indicators for this vulnerability because exploitation uses attacker-chosen destinations, but repeated invalid-certificate failures combined with memory exhaustion in a vulnerable undici-based process are strong investigative signals.

• DEPTH_ZERO_SELF_SIGNED_CERT
• SELF_SIGNED_CERT_IN_CHAIN
• UNABLE_TO_VERIFY_LEAF_SIGNATURE
• ERR_TLS_CERT_ALTNAME_INVALID
• CERT_HAS_EXPIRED
• self signed certificate
• unable to verify the first certificate
• Hostname/IP does not match certificate's altnames
• certificate has expired
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• OOMKilled
• Container killed due to memory usage
• webhook delivery failed
• webhook retry
• certificate verify failed

What your security team should do

• Inventory Node.js applications that send outbound webhooks, callbacks, integration notifications, or user-supplied HTTP requests using undici.
• Patch undici to 5.29.0, 6.21.2, 7.5.0, or later, prioritizing internet-facing, multi-tenant, and webhook-heavy services.
• Search dependency lockfiles and container images for vulnerable undici versions, including transitive dependencies.
• Add controls to limit webhook retry storms: maximum retry count, exponential backoff, per-destination throttling, circuit breakers, and automatic disablement after repeated TLS failures.
• Monitor Node.js memory usage, process restarts, and out-of-memory events for services that process outbound webhooks.
• Review application logs for repeated TLS certificate validation failures associated with the same webhook destination or account.
• Ensure outbound request allowlisting, URL validation, and SSRF protections are in place where users can influence callback destinations.
• Because the issue is not KEV-listed, has low EPSS, and has no known mature exploit, treat remediation as normal-priority unless the application exposes high-volume webhook functionality to untrusted users.