Three days. That is the entire window defenders had between the patch landing and the first exploitation attempts hitting the wider internet. On 16 May 2026, VulnCheck reported the first probing activity against its honeypot networks targeting CVE-2026-42945, the 18-year-old heap overflow in NGINX's ngx_http_rewrite_module that was disclosed and patched on 13 May. The window for unhurried patching is gone.
The flaw, which carries a CVSS score of 9.2, sits in how NGINX handles a specific rewrite directive pattern containing a question mark in the replacement string followed by a set or rewrite directive using an unnamed PCRE capture group. That is the entire trigger. Everything else discussed below flows from what attackers can do once that pattern is reachable.
According to SecurityWeek, the exploitation attempts began three days after both the vendor patch and the depthfirst proof-of-concept were made public. That timing is not coincidental. The PoC handed attackers a working template, and the gap between disclosure and weaponisation collapsed to roughly 72 hours.
There is an important nuance in how scanning is likely working. Attackers probing the internet at scale cannot know in advance whether a given NGINX instance has the precise vulnerable configuration pattern. They cannot read your nginx.conf from the outside. What they can do is fire the malformed request at every NGINX server they find and watch for a crash. A crashed worker process is, in effect, the confirmation signal. That means even servers being scanned speculatively are at risk of denial-of-service simply through the reconnaissance phase, before any deliberate follow-up.
VulnCheck's honeypot telemetry does not yet show the end goals behind the activity. It could be opportunistic scanning by initial access brokers building target lists. It could be groundwork for targeted denial-of-service. It could be a combination. The uncertainty itself is the problem, because the same probe that crashes a worker today could be paired with a code execution payload tomorrow.
Any NGINX deployment running versions 0.6.27 through 1.30.0 with the vulnerable config pattern can be crashed by a remote attacker. On any reachable, internet-facing service, that is an immediate denial-of-service condition. No authentication required, no special privileges, no chained vulnerabilities.
The second outcome is remote code execution within the worker process, and it depends on ASLR. AlmaLinux maintainers were measured in their assessment, stating that "turning the heap overflow into reliable code execution is not trivial in the default configuration, and on systems with ASLR enabled we do not expect a generic, reliable exploit to be easy to produce." Most modern Linux distributions enable ASLR by default, which means for the typical NGINX deployment the practical ceiling is currently a crash, not a shell. On systems with ASLR disabled, that ceiling disappears.
Do not read this as comfort. A reliable, remote, unauthenticated denial-of-service on any internet-facing NGINX server with a particular config pattern is already a serious incident in its own right. Reverse proxies, load balancers, ingress controllers, public-facing application gateways — these are precisely the components whose unavailability cascades.
If you have not patched, treat this as an active incident risk rather than a scheduled task. The PoC was public before exploitation began, so the barrier to building a working attack was effectively zero for anyone motivated.
The fastest detection signal is your NGINX error log. Worker process crashes generate error log entries, and unexpected worker restart events are among the clearest indicators of compromise available for this specific vulnerability. Pull the last week of logs and look for anomalous worker exits. If you find them and your config matches the vulnerable rewrite pattern, assume you are being probed.
For patching, the fixed versions are NGINX Open Source 1.30.1 and 1.31.0, along with NGINX Plus R32 P6 and R36 P4. Equivalent fixes are available for NGINX App Protect WAF, Ingress Controller, Gateway Fabric, and Instance Manager. Each carries its own target version in the F5 advisory K000160932, so consult that directly rather than assuming a single version string covers your estate.
If you cannot patch immediately, audit your configuration for the trigger pattern. A rewrite directive with a question mark in the replacement string, followed by a set or rewrite directive using an unnamed capture group such as $1 or $2, is what makes the flaw reachable. Removing that pattern closes the door without a binary update. It is a stopgap, not a strategy.
The three-day window between patch and exploitation is the broader lesson. When a detailed technical write-up accompanies a disclosure, and when that write-up demonstrates remote code execution in a deployed component as widely used as NGINX, the assumption that defenders have weeks to test and roll out fixes is no longer reasonable. The arithmetic has changed. For high-severity flaws in widely deployed infrastructure, patching cycles measured in days, not weeks, are now the baseline expectation.
For NGINX administrators specifically, the action items are short. Confirm your version. If you are in the vulnerable range, patch to a fixed release. Pull your error logs and look for unexpected worker exits. If your config contains the vulnerable rewrite pattern and you cannot patch today, edit the config to remove the trigger. None of this is complicated. What it requires is treating the next 24 to 48 hours as the operational priority.
Yes, it is worth investigating. Worker crashes triggered by this vulnerability will appear in the NGINX error log as worker process exits. Check whether your configuration contains a rewrite directive with a question mark in the replacement string followed by a set or rewrite directive using a capture group such as $1 or $2. If your config matches that pattern and you are running any version from 0.6.27 through 1.30.0, treat the crashes as a probable exploitation attempt and patch immediately.
ASLR significantly raises the bar for achieving remote code execution — AlmaLinux maintainers stated they do not expect a generic, reliable exploit to be easy to produce on ASLR-enabled systems. However, ASLR is not a fix. An attacker who can repeatedly crash your worker process has a denial-of-service capability regardless of ASLR status, and sophisticated actors have historically found ways to defeat ASLR given enough attempts. The only reliable fix is patching to NGINX 1.30.1, 1.31.0, or the appropriate NGINX Plus release.
Removing or rewriting the specific vulnerable config pattern — a rewrite with a question mark followed by a set directive using an unnamed capture group — closes the trigger path without updating NGINX. This is a viable short-term measure if you can audit your config quickly. It is fiddly at scale and should not be treated as a permanent substitute for patching. The worker crash logs are your fastest signal for whether your current config is being probed.
