An 18-Year-Old Bug in Nginx Just Got a Working Exploit — and Your Rewrite Rules Might Be the Trigger

On May 13, 2026, the Nginx team published CVE-2026-42945. Two things made it the security story of the week. First, the bug had been sitting in production since 2008, in code most operators consider plumbing — the rewrite module. Second, by May 16, VulnCheck's honeypot network was logging active exploitation in the wild, and the proof-of-concept had been on GitHub for three days. The CVSS score landed at 9.2.

The flaw lives in ngx_http_rewrite_module. When a rewrite directive uses an unnamed PCRE capture (the classic $1, $2 placeholders) and the replacement string contains a question mark, and that block is followed by another rewrite, if, or set directive in the same scope, Nginx's worker process can be coerced into a heap buffer overflow. Crafted HTTP requests reliably crash the worker — which on its own is a denial-of-service. On systems where ASLR is disabled, or where the attacker chains heap grooming with a memory disclosure side-channel, this becomes remote code execution.

1. The patch and the lower-effort fix

The fix is in nginx-1.30.1 stable and nginx-1.31.0 mainline. If you cannot deploy a new binary tonight, you can still defuse the bug today by auditing your nginx.conf and any included server blocks. Search for rewrite rules that combine unnamed PCRE captures with a replacement containing ?, and re-write them either with named captures or with the redirect already terminating the block. This is grep-level work — a senior SRE can survey a fleet in an hour:

grep -rE 'rewrite\s+[^;]+\$[0-9]+[^;]*\?' /etc/nginx/

2. Who is actually exposed

Every Nginx from 0.6.27 (2008) through 1.30.0 is in scope. That is essentially every Nginx ever deployed. The exposed configurations are narrower — you need the specific combination of unnamed capture, question-mark replacement, and a follow-up directive — but the WAF telemetry that has surfaced in the last 72 hours shows that the configuration is common enough that real workloads are being hit, not lab targets. Anyone running Laravel behind Nginx with classic legacy URL rewrites should treat this as a "patch this week, not this quarter."

3. The Laravel angle

Laravel's public/.htaccess and the conventional Nginx site config use a clean front-controller rewrite that does not match the vulnerable pattern. But teams that bolted on legacy redirects — migrated WordPress sites, marketing landing pages with custom query-string rewrites, multi-tenant configurations that route by prefix — are exactly where the vulnerable shape tends to live. The audit should walk every server and location block, not just the main Laravel block.

4. Defense in depth for the worker process

While you are patching, do four things. One: confirm ASLR is on (it has been a Linux default for years, but containers and minimal images sometimes ship with it off). Two: enable per-worker resource limits so a crashing worker cannot take down the host. Three: front the box with a WAF rule that blocks requests with the specific malformed PCRE-trigger pattern — both Cloudflare and AWS WAF managed rules pushed signatures on May 14. Four: log every worker process exited on signal 11 in your monitoring and trigger an alert on the first one. The exploit is loud; you just need to be listening.

5. The broader lesson

The bug was 18 years old. That is not unusual — last year's CUPS chain was the same shape, the OpenSSH regression a few months back was the same shape. The unsexy code paths in our infrastructure — the rewrite module, the logging filter, the cron job that nobody owns — keep producing the worst vulnerabilities. The teams that handle this well are the teams that already had a quarterly Nginx-config audit on a calendar. Not because they are paranoid, but because the cost of finding the bug yourself is always lower than the cost of finding out from VulnCheck.

My Take

The hardest part of running a public web stack in 2026 is not the modern things. It is not Kubernetes, not Cloudflare, not the AI agents you let near production. It is the eighteen-year-old code path nobody has read since 2008, that is the only thing between the open internet and your application. CVE-2026-42945 is a reminder that "we have been running this in prod for years and it has been fine" is not a security posture. It is an unscanned attic. Patch this one tonight.