CVE-2026-42945

What it actually does

The flaw is a heap buffer overflow in the NGINX rewrite module triggered under a specific configuration pattern: a rewrite directive followed by another rewrite, if, or set directive that uses an unnamed PCRE capture such as $1 or $2, where the replacement string contains a question mark. A crafted unauthenticated HTTP request can exercise the vulnerable rewrite logic and corrupt heap memory in an NGINX worker process. The most likely outcome is worker process crash and restart, causing denial of service. In less common but higher-impact conditions, especially where ASLR is disabled or can be bypassed, memory corruption may be shaped into arbitrary code execution in the context of the NGINX worker process.

Why it matters to the business

Public-facing NGINX reverse proxies, web servers, and API gateways using vulnerable rewrite configurations may be remotely crashed by unauthenticated traffic, causing service instability, degraded availability, failed transactions, or intermittent outages. Because NGINX is often placed at the edge of production environments, exploitation can affect multiple downstream applications even if those applications are not themselves vulnerable. The CVSS score is high and EPSS is elevated at approximately 66%, indicating meaningful exploitation likelihood, but exploitation depends on a specific configuration and is currently not listed in CISA KEV or associated with ransomware use. The issue has been public for 89 days, so internet-facing deployments should be reviewed and updated with urgency even without known KEV status.

How an attack unfolds

An attacker first identifies an internet-exposed NGINX or NGINX Plus service. They then probe URL paths and query strings to infer whether rewrite rules are present and whether requests are being transformed in a way consistent with vulnerable ngx_http_rewrite_module behavior. If the target configuration contains the vulnerable sequence of directives and unnamed PCRE captures with a replacement string containing a question mark, the attacker sends a crafted HTTP request designed to drive execution through that rewrite path. When the vulnerable rewrite logic processes the request, heap memory in the worker process may be overwritten. In typical deployments this crashes the affected worker, which the master process restarts, leading to repeated worker exits, 5xx responses, and service instability if requests continue. If ASLR is disabled or bypassed and the attacker has enough control over heap layout, the same corruption condition may be developed into code execution as the NGINX worker user.

How to fix it

Upgrade NGINX Open Source or NGINX Plus to a vendor-fixed release as soon as fixed versions are available for the deployed branch. Because no fixed version list was provided, administrators should consult the official NGINX/F5 advisory for CVE-2026-42945 and apply the first patched release for their supported version line. Do not rely on versions that have reached End of Technical Support, as they may not be evaluated or patched. As an immediate mitigation, audit NGINX configuration files for rewrite-module patterns where a rewrite directive is followed by rewrite, if, or set and uses unnamed captures such as $1 or $2 with a replacement string containing a question mark. Replace unnamed captures with named captures where supported, simplify chained rewrite logic, remove unnecessary question marks from replacement strings, or restructure the rule so the vulnerable directive sequence is not present. Keep ASLR enabled at the operating-system level and avoid running NGINX workers with unnecessary privileges. If NGINX is deployed in containers, rebuild images from patched base packages and redeploy rather than patching only running containers.

How to confirm the fix worked

Confirm exposure by inventorying all NGINX and NGINX Plus instances, including reverse proxies, ingress controllers, load balancers, containers, appliances, and embedded deployments. Check the runtime version with commands such as `nginx -v` or package-manager inventory and compare it against the vendor advisory's patched releases. Validate configuration by reviewing all loaded configuration files, including included files, for `rewrite`, `if`, and `set` directive chains that use unnamed captures like `$1`, `$2`, `$3` and replacement strings containing `?`. After remediation, run `nginx -t` to confirm the configuration is valid, reload the service, and verify the active binary version. Where safe, use a staging environment to replay representative requests through previously affected rewrite paths and confirm there are no worker crashes, connection resets, or unexpected 5xx responses. Monitor process supervision logs after deployment to ensure NGINX workers are no longer exiting unexpectedly.

Typical attack path

1. Discover an exposed NGINX or NGINX Plus endpoint through scanning, banners, TLS metadata, HTTP behavior, or error pages.
2. Send benign requests to map application routes and identify paths likely handled by rewrite rules.
3. Craft requests with path and query-string patterns intended to trigger vulnerable rewrite, if, or set directive chains using unnamed regex captures.
4. Observe worker crashes, connection resets, intermittent 502/503/504 errors, or repeated service recovery as evidence that the vulnerable code path is reachable.
5. Repeat requests to cause denial of service or, in advanced scenarios where memory protections can be bypassed, attempt to convert heap corruption into code execution within the NGINX worker process.

How to detect it

To determine whether exploitation already occurred, review NGINX access logs, error logs, system logs, process manager logs, container runtime logs, and monitoring data from the publication date onward. Look for repeated requests to the same rewritten paths immediately followed by NGINX worker crashes, connection resets, segmentation faults, abnormal exits, or bursts of 500, 502, 503, or 504 responses. In systemd-based deployments, inspect journald for NGINX worker processes exiting on signal 11 or being restarted by the master process. In containerized deployments, review Kubernetes pod events, container restart counts, ingress-controller logs, and crash-loop events. Correlate suspicious request bursts by source IP, URI, query string, user agent, and timestamp with worker restart events. If code execution is suspected, examine the NGINX worker user context for unexpected child processes, shell execution, outbound network connections, modified web content, new scheduled tasks, anomalous files in temporary directories, or changes to NGINX modules and configuration. Because no specific public exploit signature or threat actor indicator was provided, detection should focus on behavioral evidence of worker memory corruption and post-exploitation activity rather than a single request pattern.

• worker process exited on signal 11
• worker process exited on signal 6
• segmentation fault
• segfault at
• core dumped
• recv() failed (104: Connection reset by peer)
• upstream prematurely closed connection
• connect() failed (111: Connection refused) while connecting to upstream
• HTTP/1.1" 500
• HTTP/1.1" 502
• HTTP/1.1" 503
• HTTP/1.1" 504
• nginx: worker process
• nginx -t
• /var/log/nginx/error.log
• /var/log/nginx/access.log
• /usr/local/nginx/logs/error.log
• /usr/local/nginx/logs/access.log
• /etc/nginx/nginx.conf
• /etc/nginx/conf.d/
• /etc/nginx/sites-enabled/
• rewrite .*\$[0-9].*\?
• if .*\$[0-9].*\?
• set .*\$[0-9].*\?

What your security team should do

• Prioritize internet-facing NGINX and NGINX Plus systems because exploitation is unauthenticated and EPSS is elevated.
• Obtain the official NGINX/F5 advisory and upgrade every supported deployment to a patched release for its version line; replace unsupported EoTS versions.
• Perform a configuration-focused exposure review for rewrite-module directive chains using unnamed captures and question marks in replacement strings.
• Apply temporary configuration mitigations immediately where patching cannot be completed quickly, especially on public reverse proxies and API gateways.
• Ensure ASLR is enabled and hardening controls such as least-privilege worker users, SELinux/AppArmor profiles, systemd sandboxing, and container isolation are in place.
• Review NGINX error logs and process supervisor logs for unexplained worker crashes or repeated restarts since the vulnerability publication date.
• Add monitoring for spikes in 5xx responses, connection resets, abnormal worker exits, and repeated requests to rewritten URL paths.
• After patching, redeploy immutable images or appliances from trusted patched artifacts rather than modifying only live instances.
• Track vendor updates because fixed-version details were not supplied in the input and may vary by NGINX Open Source or NGINX Plus branch.