CVE-2026-40701

What it actually does

This is a heap-use-after-free vulnerability in the NGINX ngx_http_ssl_module that is reachable over the network when NGINX is configured for client certificate verification using ssl_verify_client set to "on" or "optional" and OCSP validation is enabled with ssl_ocsp set to "on" or leaf certificate validation is configured with a resolver. Under the vulnerable configuration, a remote unauthenticated requester can trigger memory corruption in an NGINX worker process when TLS client-certificate and OCSP-related request handling reaches the unsafe object lifetime condition. The expected technical outcomes are NGINX worker process crash/restart and potential limited data corruption or unintended modification of in-memory request-processing data; available information does not indicate reliable remote code execution. Impact is constrained to deployments using the affected SSL/client-certificate verification configuration and affected NGINX Open Source, NGINX Plus, or products embedding NGINX such as F5 NGINX Gateway Fabric, NGINX Ingress Controller, NGINX Instance Manager, F5 WAF, and related F5 offerings.

Why it matters to the business

Affected internet-facing reverse proxies, ingress controllers, API gateways, and web application security tiers may experience intermittent request failures, dropped TLS sessions, worker restarts, degraded availability, and instability when targeted. Because NGINX is commonly deployed at the edge or in front of critical applications, even limited worker crashes can translate into customer-facing errors, reduced capacity, noisy operational incidents, and potential bypass or disruption of dependent services. The current EPSS is low at 0.0069 with no 30-day movement, it is not listed in CISA KEV, and no public exploit maturity is reported, so this is not currently a mass-exploitation emergency; however, organizations using mutual TLS, client certificate authentication, OCSP validation, ingress controllers, or gateway products should still prioritize remediation because the flaw is remotely reachable and requires no authentication.

How an attack unfolds

An attacker first identifies an HTTPS endpoint served by an affected NGINX-based product. The endpoint must be configured to verify client certificates using ssl_verify_client set to "on" or "optional" and must also use OCSP validation through ssl_ocsp set to "on" or a leaf-certificate resolver configuration. The attacker then sends crafted or repeated TLS/HTTPS requests that exercise the client-certificate and OCSP validation path. When the vulnerable object lifetime sequence occurs, influenced partly by runtime conditions outside the attacker’s direct control, NGINX may dereference previously freed heap memory inside a worker process. Successful exploitation is most likely observed as a worker crash and automatic restart, connection resets, transient 5xx responses, and error-log entries showing abnormal worker termination or segmentation faults. Repeated triggering can degrade service availability and may cause limited corruption of request-processing data, but current public information does not support treating this as a reliable full remote code execution vulnerability.

How to fix it

Upgrade affected NGINX Open Source, NGINX Plus, and F5 products to vendor-provided fixed releases as soon as they are available for the specific product line in use. No exact fixed versions were provided in the input, so administrators should consult the latest F5/NGINX security advisories for NGINX Open Source, NGINX Plus, F5 NGINX Gateway Fabric, F5 NGINX Ingress Controller, F5 NGINX Instance Manager, F5 WAF, and related affected products. Where immediate patching is not possible, reduce exposure by disabling unnecessary client-certificate verification, disabling ssl_ocsp where operationally acceptable, removing vulnerable leaf-certificate resolver configurations, restricting access to affected mutual-TLS endpoints, rate-limiting suspicious TLS handshake traffic, and placing affected services behind additional filtering controls. Do not rely solely on worker auto-restart as a mitigation, because repeated triggering can still cause service instability. Also ensure unsupported or End-of-Technical-Support builds are removed or replaced, since they may not receive evaluation or fixes.

How to confirm the fix worked

Confirm exposure by reviewing the effective NGINX configuration, not only included configuration snippets. Use commands such as nginx -T or the product-equivalent configuration export and search for ssl_verify_client set to "on" or "optional" combined with ssl_ocsp set to "on" or leaf certificate validation using a resolver. Validate running versions for NGINX Open Source, NGINX Plus, ingress controller images, gateway components, and F5-packaged products against the vendor advisory and patched release notes. After remediation, restart or reload the affected service, confirm the updated binary/container/package is active, and re-run configuration checks to verify that vulnerable directive combinations are absent or patched. Operational validation should include monitoring error logs for worker crashes, segmentation faults, abnormal exits, repeated TLS handshake failures, and elevated 4xx/5xx rates before and after the change.

Typical attack path

1. Scan for HTTPS services running NGINX, NGINX Plus, or NGINX-derived ingress/gateway products.
2. Identify endpoints that request or require client certificates, such as mutual TLS APIs, administrative portals, partner integrations, or service-to-service gateways.
3. Send TLS/HTTPS requests that exercise client-certificate verification and OCSP validation paths.
4. Trigger the vulnerable heap-use-after-free condition during SSL client verification handling under the required runtime conditions.
5. Observe connection resets, failed handshakes, intermittent HTTP errors, or worker process restarts as signs of successful triggering.
6. Repeat requests to cause recurring worker crashes, degraded edge capacity, or instability in the reverse proxy, ingress, or gateway layer.

How to detect it

To determine whether this was already exploited or attempted, review NGINX error logs, access logs, ingress-controller logs, F5 product logs, container stdout/stderr, systemd journals, syslog, kernel logs, and crash/core-dump records for abnormal worker exits correlated with HTTPS requests to endpoints using client-certificate verification. Focus on time windows with repeated TLS handshake failures, connection resets, unexplained 400/495/496/497 responses, 502/503/504 responses from upstream gateways, and error-log entries indicating worker process crashes or segmentation faults. In containerized environments, inspect pod restart counts, container exit codes, Kubernetes events, and ingress controller logs for repeated restarts without deployment activity. In appliance or managed gateway deployments, inspect high-availability failover logs, process supervision logs, and health-check failures. Because exploitation may not leave a unique request string, detection should correlate vulnerable configuration, external reachability, TLS/client-certificate endpoints, abnormal worker termination, and repeated activity from the same source networks. No named threat actors, ransomware campaigns, or CISA KEV exploitation are currently associated with this vulnerability in the supplied data.

• ssl_verify_client on;
• ssl_verify_client optional;
• ssl_ocsp on;
• resolver
• nginx: worker process
• worker process exited on signal 11
• exited on signal 11
• SIGSEGV
• segmentation fault
• core dumped
• recv() failed
• SSL_do_handshake() failed
• client SSL certificate verify error
• client sent no required SSL certificate
• 495
• 496
• 497
• /var/log/nginx/error.log
• /var/log/nginx/access.log
• /var/log/syslog
• /var/log/messages
• /var/log/kern.log
• /var/lib/systemd/coredump/
• nginx-ingress-controller
• nginx: master process
• nginx: worker process

What your security team should do

• Inventory all NGINX Open Source, NGINX Plus, F5 NGINX Ingress Controller, F5 NGINX Gateway Fabric, F5 NGINX Instance Manager, F5 WAF, and other NGINX-derived deployments, including containers and appliances.
• Prioritize internet-facing and partner-facing HTTPS endpoints that use mutual TLS, client certificate authentication, OCSP validation, or certificate resolver configurations.
• Check effective configurations for ssl_verify_client set to "on" or "optional" together with ssl_ocsp set to "on" or resolver-based leaf certificate validation.
• Patch to the vendor-fixed version for each affected product as soon as available; replace EoTS versions rather than attempting to compensate indefinitely.
• If patching is delayed, temporarily disable nonessential OCSP/client-certificate verification paths or restrict access to affected endpoints using network controls, allowlists, and rate limits.
• Enable and retain NGINX error logs, ingress controller logs, system logs, core-dump metadata, and process supervision logs to support investigation of worker crashes.
• Create detections for abnormal NGINX worker exits, SIGSEGV events, repeated TLS handshake failures, and spikes in connection resets or 5xx responses on mTLS-enabled endpoints.
• Because this is not currently KEV-listed, has low EPSS, and has no known public exploit maturity, schedule remediation based on exposure and business criticality rather than emergency global patching, while still treating externally exposed mTLS gateways as higher priority.