May 2026 dropped three critical Linux vulnerabilities on a near-weekly cadence, and the security discourse has mostly treated them as three separate bad days. They’re not. Together they form a reliable, race-free, forensically quiet kill chain from the public internet to root, and if you’re running nginx in front of anything that matters, you need to stop and read this.<\/p>\n
CVE-2026-42945, dubbed NGINX Rift, landed May 13 courtesy of depthfirst. It’s a heap buffer overflow in CVE-2026-31431, “Copy Fail,” came from Theori on April 29. It’s a logic bug in the Then there’s CVE-2026-43284 and CVE-2026-43500, “Dirty Frag,” disclosed May 7 by Hyunwoo Kim. It’s a two-bug chain that lands in the same place as Copy Fail \u2013 page-cache-to-root LPE \u2013 but routes around the Copy Fail mitigation entirely. If you blacklisted Why does the combination matter more than any single bug? Exploit chains are usually academic exercises, published to demonstrate feasibility and then left to rot in a CTF writeup. This isn’t that. CVE-2026-42945 hands you a foothold from the internet. CVE-2026-31431 or CVE-2026-43284 hands you root once you’re on the box. Neither step requires races, user interaction, or authentication. Neither leaves obvious forensic traces on disk. Both have working, published proof-of-concept code as of this writing.<\/p>\n The surface area here is genuinely uncomfortable. NGINX is the most-deployed web server on the planet. WordPress \u2013 with scads of massively-deployed plugins recommended NGINX configuration contains the exact vulnerable rewrite pattern (I checked; it’s right there in the docs) \u2013 powers something north of 40% of the web. That means whitehouse.gov, NASA, the UK Government, the Australian Government, the State of California, and essentially every major US university is potentially in scope. Every federal agency required by the 21st Century IDEA Act to maintain a public web presence. Every municipality running WordPress on a LEMP stack. Every SaaS app behind an NGINX ingress controller. An attacker doesn’t need a zero-day chain for any of these; they need access to data from a public internet scanner, a grep for vulnerable version strings, and the ability to send one HTTP request.<\/p>\n I shipped a static configuration scanner for the NGINX Rift pattern. Single bash script, no dependencies beyond bash 4+ and grep, runs offline against config files without touching a live nginx process:<\/p>\n Run it on every box running nginx. Add If you find a hit, you’ve got two options in order of preference:<\/p>\n For the kernel side, check your distro’s patch status now and don’t trust “we’ll get to it.” If you can’t patch immediately, blacklisting Three critical Linux CVEs in three weeks, all with published exploits, all in code that’s been shipping for years. The gap between disclosure and working exploit is now measured in hours, not months. The scanner above closes one piece of that gap for the nginx side. The rest depends on whether you check your configs today or wait until something in your logs looks wrong \u2013 at which point the forensic-residue-free LPE means “looking wrong” may be all you ever see.<\/p>\n","protected":false},"excerpt":{"rendered":" May 2026 dropped three critical Linux vulnerabilities on a near-weekly cadence, and the security discourse has mostly treated them as three separate bad days. They’re not. Together they form a reliable, race-free, forensically quiet kill chain from the public internet to root, and if you’re running nginx in front of anything that matters, you need […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":3,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"federated","footnotes":""},"categories":[681,3,26],"tags":[],"class_list":["post-48030","post","type-post","status-publish","format-standard","hentry","category-cybersecurity","category-information-security","category-vulnerabilities"],"yoast_head":"\nngx_http_rewrite_module<\/code> that’s been sitting in every nginx build since 2008. An unauthenticated attacker sends a single crafted HTTP request and overwrites the heap, getting remote code execution in the worker process \u2013 no auth, no prior session, no prerequisites beyond a network path to port 80 or 443. The root cause is a mismatch between two passes over the rewrite directives: the length calculation runs with is_args=0<\/code> (raw byte count) while the copy pass runs with is_args=1<\/code> (URI-escaped), so the write overruns the allocation. The trigger is a configuration pattern that’s everywhere: a rewrite<\/code> directive with an unnamed PCRE capture ($1<\/code>, $2<\/code>) and a question mark in the replacement string, followed by another rewrite<\/code>, if<\/code>, or set<\/code> in the same block. CVSS 9.2, and it earns it.<\/p>\nauthencesn<\/code> cryptographic template that lets an unprivileged local user write 4 controlled bytes into the page cache of any readable file, then pivot to root. The exploit is 732 bytes of Python (no races, no disk writes, no forensic residue \u2013 the page cache corruption means file integrity checks pass because the underlying file on disk was never touched). It works on every distro shipped since 2017. CISA added it to the Known Exploited Vulnerabilities catalog with a May 15 remediation deadline.<\/p>\nalgif_aead<\/code> thinking you were covered, Dirty Frag gets there through xfrm-ESP<\/code> or rxrpc<\/code> instead. Microsoft’s already seeing in-the-wild activity: SSH foothold, stage an ELF binary, escalate via su<\/code>. Deterministic. No races. Same bug class, different sink.<\/p>\ngit clone https:\/\/git.sr.ht\/~hrbrmstr\/cve-2026-42945-scanner\ncd cve-2026-42945-scanner\n.\/scan-nginx-rift.sh \/etc\/nginx\n<\/code><\/pre>\n--json<\/code> in CI. Point it at ingress controller configmaps. The output tells you the file, the line number, the vulnerable directive, and which following directive creates the exploitability condition:<\/p>\n[VULN] sites-enabled\/wordpress.conf:8 \u2013 rewrite ^\/([^\/]+?)-sitemap([0-9]+)?.xml$\n followed by \"if\" at line 12\n<\/code><\/pre>\n\n
rewrite<\/code>:<\/li>\n<\/ol>\n# Before (vulnerable)\nrewrite ^\/([^\/]+?)-sitemap([0-9]+)?.xml$ \/index.php?sitemap=$1&sitemap_n=$2 last;\n\n# After (safe)\nrewrite ^\/(?<term>[^\/]+?)-sitemap(?<num>[0-9]+)?.xml$ \/index.php?sitemap=$term&sitemap_n=$num last;\n<\/code><\/pre>\nalgif_aead<\/code> blocks Copy Fail but does nothing for Dirty Frag. For Dirty Frag, unload xfrm_algo.ko<\/code> and rxrpc.ko<\/code> if your workload doesn’t need them, and make sure AppArmor or SELinux policy is blocking unprivileged user namespaces.<\/p>\n