CVE-2025-59464: Node.js OpenSSL Memory Leak in getPeerCertificate

Memory leaks are among the most insidious classes of software vulnerabilities. Unlike crashes or error messages that demand immediate attention, a memory leak operates silently, consuming resources incrementally until the entire system degrades or collapses. CVE-2025-59464 exemplifies this pattern at a critical intersection: Node.js's TLS implementation and OpenSSL's X.509 certificate parsing. When getPeerCertificate(true) is called during a TLS handshake, the underlying C++ binding converts certificate fields to UTF-8 using OpenSSL's ASN1_STRING_to_UTF8() function but fails to release the allocated buffer with OPENSSL_free(). The result is a memory leak that grows with every new TLS connection, creating a viable path to Denial of Service through deliberate resource exhaustion. This article dissects the technical root cause, maps the attack surface, quantifies real-world impact, and provides concrete remediation guidance.

What Is CVE-2025-59464 and Why It Matters

CVE-2025-59464 is a medium-severity vulnerability in Node.js affecting its native TLS module's integration with OpenSSL. The flaw resides in the C++ binding layer that converts X.509 certificate subject and issuer fields from ASN.1 encoding to UTF-8 strings for consumption by JavaScript code. Specifically, when tls.TLSSocket.getPeerCertificate(true) is invoked with the detailed parameter set to true, Node.js traverses the entire certificate chain and converts each certificate's fields, but the memory allocated by ASN1_STRING_to_UTF8() for these conversions is never freed.

This matters because mTLS (mutual TLS) is no longer a niche pattern. Modern API gateways, service meshes, and zero-trust architectures routinely validate client certificates on every request. In a typical mTLS API gateway handling thousands of connections per minute, each connection leaks a small amount of memory. Over hours or days, the accumulated leaks drive the Node.js process toward its memory limit, causing garbage collection thrashing, response time degradation, and eventually an out-of-memory crash. The vulnerability is particularly dangerous in long-running server processes that never restart, a common pattern in containerized deployments where uptime is prioritized above all else.

Technical Root Cause Analysis

How Node.js Interfaces with OpenSSL for X.509 Parsing

Node.js implements TLS functionality through a C++ addon layer that directly calls OpenSSL library functions. When JavaScript code calls getPeerCertificate(), execution flows from the JavaScript runtime into the native node_crypto.cc source file, where the binding code interacts with OpenSSL's X.509 data structures to extract certificate fields.

The critical function is ASN1_STRING_to_UTF8(), which OpenSSL provides for converting ASN.1-encoded strings (the format used in X.509 certificates) to UTF-8 C strings. This function allocates a new buffer using OpenSSL's internal memory allocator. The caller is responsible for freeing this buffer by calling OPENSSL_free() once the conversion is complete. This ownership pattern is documented in the OpenSSL manual but is easy to overlook when writing wrapper code that bridges two different memory management models.

The Node.js binding code extracts fields such as the Common Name (CN), Organization (O), Organizational Unit (OU), and Subject Alternative Names (SANs) from each certificate in the chain. For each field, it calls ASN1_STRING_to_UTF8(), copies the resulting UTF-8 string into a V8 JavaScript string, and should then call OPENSSL_free() to release the temporary buffer. The V8 string has its own memory managed by the garbage collector, making the OpenSSL buffer unnecessary after the copy.

The Missing OPENSSL_free() Call

The vulnerability exists because the code path that processes certificate chain entries when detailed=true omits the OPENSSL_free() call after converting specific fields. The affected code path looks conceptually like this:

// Vulnerable pattern (simplified from node_crypto.cc)
unsigned char* utf8_value = nullptr;
int len = ASN1_STRING_to_UTF8(&utf8_value, asn1_str);
if (len >= 0) {
  Local<String> v8str = String::NewFromUtf8(
      isolate,
      reinterpret_cast<char*>(utf8_value),
      NewStringType::kNormal, len).ToLocalChecked();
  target->Set(context, key, v8str).Check();
  // BUG: Missing OPENSSL_free(utf8_value) here
}

The fields that leak include the subject and issuer distinguished name components (CN, O, OU, C, ST, L) and Subject Alternative Name entries of type dNSName and rfc822Name. Each leaked allocation is typically between 10 and 200 bytes depending on the field content. While individually small, these allocations accumulate rapidly when processing certificate chains with multiple certificates and numerous SAN entries per connection.

How getPeerCertificate(true) Triggers the Leak

The Certificate Chain Parameter

The getPeerCertificate() method accepts a boolean parameter called detailed. When set to false (the default), it returns only the peer's immediate certificate. When set to true, it returns the entire certificate chain including intermediate and root certificates, with each certificate fully parsed into a JavaScript object.

The memory leak only manifests when detailed=true because the chain traversal code path contains the missing OPENSSL_free() calls. The non-detailed path processes only the leaf certificate through a different, correctly implemented code path. This distinction is crucial for understanding why some applications are affected while others using TLS in the same Node.js version are not.

Per-Connection Memory Growth

Each TLS connection that triggers getPeerCertificate(true) leaks memory proportional to the number of certificates in the chain multiplied by the number of parsed fields per certificate. A typical three-certificate chain (leaf + intermediate + root) with standard fields leaks approximately 2-4 KB per connection. Certificates with extensive SAN lists, common in CDN and cloud provider certificates, can leak significantly more, sometimes 10-20 KB per connection.

Attack Vector: DoS Through Resource Exhaustion

Exploiting the Leak Remotely

An attacker can exploit CVE-2025-59464 to cause Denial of Service against any Node.js server that calls getPeerCertificate(true) during TLS connection handling:

1. Identify a target Node.js server that performs client certificate validation using getPeerCertificate(true)
2. Generate a client certificate with a long certificate chain and numerous SAN entries to maximize per-connection leak size
3. Establish TLS connections to the target, completing the handshake to trigger certificate parsing
4. Immediately disconnect after the handshake completes and repeat at high frequency
5. Each connection cycle leaks memory that is never reclaimed by the garbage collector
6. Continue until the Node.js process exhausts available memory and crashes or becomes unresponsive

Attack Amplification Strategies

The attack can be amplified through several techniques that increase the memory leaked per connection:

• SAN inflation: Including hundreds of Subject Alternative Name entries in the client certificate increases the per-connection leak from kilobytes to tens of kilobytes
• Chain depth: Using longer certificate chains (4-5 certificates instead of the typical 3) multiplies the leak per field across more certificates
• Parallel connections: Opening multiple simultaneous TLS connections accelerates memory consumption while distributing the load across connection handlers
• Connection recycling: Rapidly opening and closing connections maximizes the leak rate while minimizing attacker resource usage since each connection is short-lived

Real-World Impact Assessment

A common mistake organizations make is assuming that TLS is "handled by the framework" and requires no application-level attention. In practice, the TLS integration layer is part of the application's attack surface, and vulnerabilities in certificate parsing directly affect availability. Developers who use getPeerCertificate(true) trust that the underlying binding manages memory correctly, but CVE-2025-59464 proves that trust is misplaced for affected Node.js versions.

Consider a Kubernetes cluster using mTLS for inter-service communication through a service mesh like Istio or Linkerd. If a Node.js microservice validates peer certificates using getPeerCertificate(true), every inter-service call leaks memory. In a high-traffic mesh where a single service handles thousands of requests per minute from dozens of other services, the accumulated leak can crash the service within hours, triggering cascading failures across dependent services.

The "amplified" row demonstrates the effect of SAN-inflated certificates. An attacker using certificates with hundreds of SAN entries can achieve the same memory exhaustion rate at one-fifth the connection frequency, making the attack harder to distinguish from legitimate traffic in rate-based monitoring.

Detection and Monitoring Strategies

Process-Level Memory Monitoring

The most direct detection method is monitoring the Node.js process's memory usage over time, paying specific attention to native memory outside the V8 heap:

// Memory monitoring for native leak detection
setInterval(() => {
  const usage = process.memoryUsage();
  const rss = Math.round(usage.rss / 1024 / 1024);
  const heapUsed = Math.round(usage.heapUsed / 1024 / 1024);
  const external = Math.round(usage.external / 1024 / 1024);
  const nativeGap = rss - heapUsed - external;
  console.log({
    rss: rss + ' MB',
    heapUsed: heapUsed + ' MB',
    external: external + ' MB',
    nativeGap: nativeGap + ' MB'  // Growing gap = native leak
  });
}, 60000);

A key indicator of this specific leak is RSS (Resident Set Size) growing steadily while heapUsed remains relatively stable. The leaked OpenSSL buffers live outside the V8 heap in native memory, so heap-based monitoring tools like Node.js's built-in inspector will not detect them. The nativeGap metric in the snippet above tracks the difference between total process memory and V8-managed memory, providing a direct signal for native memory leaks.

Infrastructure-Level Detection

For production environments, integrate memory monitoring into your observability stack:

• Monitor RSS growth trends in Prometheus/Grafana with alerts for sustained linear growth patterns that deviate from normal baseline
• Use valgrind --leak-check=full in staging environments to confirm the specific leak source and measure per-connection leak size
• Track the ratio between RSS and V8 heap total; a consistently growing gap indicates native memory leaks outside the garbage collector's reach
• Set up container-level memory alerts in Kubernetes that trigger before OOM kills occur

Key indicators to watch for:

• RSS growing linearly over time while V8 heap size remains stable or cycles normally
• Increasing gap between RSS and V8 heap total that correlates with TLS connection volume
• Memory not reclaimed after traffic drops, even after extended idle periods with garbage collection
• OOM kill events in container orchestration logs that correlate with high TLS connection periods
• Gradually increasing garbage collection pause times as the OS reclaims pages under memory pressure

Mitigation and Patching Guidance

Immediate Steps

1. Check your Node.js version: The fix is included in Node.js v20.19.1, v22.15.1, and v23.7.0 and later. Verify your version with node --version
2. Upgrade immediately: Apply the patched version to all affected environments, prioritizing production services that handle mTLS or client certificate validation
3. Restart affected processes: Existing processes will continue to leak memory from the unpatched code. A restart reclaims the accumulated leaked memory and starts the process fresh
4. Audit certificate inspection usage: Search your codebase for all calls to getPeerCertificate(true) to identify every affected entry point

Workarounds for Delayed Patching

If immediate patching is not possible, these workarounds reduce the impact:

• Avoid full chain parsing: Call getPeerCertificate(false) instead of getPeerCertificate(true) if your application logic does not require the full certificate chain. The non-detailed path is not affected
• Implement periodic restarts: Schedule process restarts at intervals calculated from your traffic volume and memory limits to reclaim leaked memory before it causes degradation
• Rate limit TLS connections: Reduce the rate at which new TLS connections are accepted to slow the leak accumulation, particularly useful against deliberate exploitation attempts

Long-Term Hardening

• TLS termination at the proxy: Offload TLS handling to nginx, HAProxy, or an Envoy sidecar, keeping Node.js behind a plaintext internal connection. This eliminates Node.js's exposure to certificate parsing vulnerabilities entirely
• Container memory limits: Set memory limits on Node.js containers to trigger a controlled restart (via OOM kill and orchestrator rescheduling) before the leak affects other workloads on the same node
• Automated canary monitoring: Deploy memory growth alerts that trigger automatic rolling restarts when RSS exceeds a configured threshold, providing a safety net against future memory leaks

Vulnerable vs. Fixed Code Patterns

The fix adds the missing OPENSSL_free() call after each ASN1_STRING_to_UTF8() conversion in the certificate chain processing path:

// Fixed pattern in node_crypto.cc
unsigned char* utf8_value = nullptr;
int len = ASN1_STRING_to_UTF8(&utf8_value, asn1_str);
if (len >= 0) {
  Local<String> v8str = String::NewFromUtf8(
      isolate,
      reinterpret_cast<char*>(utf8_value),
      NewStringType::kNormal, len).ToLocalChecked();
  target->Set(context, key, v8str).Check();
  OPENSSL_free(utf8_value);  // FIX: Free the OpenSSL-allocated buffer
}

At the Node.js application level, the API remains identical. The fix is entirely within the native C++ binding, so no application code changes are required:

// Application code remains unchanged after patching
const tls = require('tls');

const server = tls.createServer(options, (socket) => {
  // This call is now safe on patched versions
  const cert = socket.getPeerCertificate(true);
  // Process certificate chain...
  // Memory is correctly freed internally by the binding
});

Frequently Asked Questions

What CVSS score does CVE-2025-59464 carry?

CVE-2025-59464 has a CVSS 3.1 base score of 5.3 (Medium). The attack vector is network-based, requires no authentication, and impacts availability through resource exhaustion. Confidentiality and integrity are not affected since the vulnerability does not expose data or allow code execution. The medium rating reflects the fact that exploitation requires sustained connections over time rather than a single request.

Does this affect Node.js applications that do not use mTLS?

Only applications that explicitly call getPeerCertificate(true) are affected. Standard HTTPS servers that do not inspect client certificates, or those that call getPeerCertificate() without the true parameter, are not vulnerable. The leak is triggered exclusively by the detailed certificate chain parsing path in the native binding.

How quickly can an attacker exhaust server memory?

The rate depends on certificate chain complexity and connection throughput. With a typical three-certificate chain and 100 connections per second, an attacker can leak approximately 200-400 KB per second, consuming 1 GB of memory in roughly 40-80 minutes. Using SAN-inflated certificates can accelerate this by a factor of five or more.

Can this vulnerability be exploited without a valid client certificate?

In most configurations, the TLS handshake must complete for getPeerCertificate() to return data. However, if the server is configured to request but not require client certificates (requestCert: true, rejectUnauthorized: false), an attacker can trigger the leak with self-signed certificates that the server accepts for inspection but does not trust for authentication.

Are other JavaScript runtimes like Deno or Bun affected?

No. This vulnerability is specific to Node.js's C++ OpenSSL binding implementation in node_crypto.cc. Deno uses Rustls for its TLS implementation, and Bun uses BoringSSL through a different binding layer. Neither runtime shares the affected code path, so they are not vulnerable to CVE-2025-59464.

Conclusion

CVE-2025-59464 demonstrates how a single missing function call in a native binding can create a production-grade Denial of Service vector. The vulnerability sits at the intersection of C/C++ memory management and the abstraction layers that JavaScript developers trust implicitly. A missing OPENSSL_free() in the certificate chain parsing path means that every TLS connection using getPeerCertificate(true) leaks memory that the garbage collector cannot reclaim. Organizations running Node.js with mTLS or client certificate validation should treat this as a priority patch.

Beyond the immediate fix, this CVE reinforces the importance of native memory monitoring for Node.js applications. Standard heap monitoring misses these leaks entirely because the allocations exist outside V8's managed memory. Implement RSS tracking alongside heap metrics, set container memory limits as a safety net, and architect for graceful restarts when memory growth exceeds expected baselines. The most resilient long-term approach is to terminate TLS at a dedicated proxy layer, reducing the Node.js process's exposure to certificate parsing vulnerabilities entirely.

Review your TLS configuration, verify your Node.js version against the patched releases (v20.19.1, v22.15.1, v23.7.0+), and deploy the fix across all affected environments. For systems where immediate patching is not feasible, implement the workarounds described above and schedule the upgrade at the earliest opportunity. Proactive memory monitoring and architectural separation of TLS concerns will protect your infrastructure not only against this CVE but against the broader class of native memory issues that affect any runtime built on C/C++ libraries.