F5 patched CVE-2026-42533 on July 15. If you run nginx, this one deserves your attention before the proof-of-concept code drops — and there is a countdown on that.

What the flaw is

The vulnerability is a heap buffer overflow (CWE-122) in nginx’s script engine — the component that assembles output strings from configuration directives at request time. It surfaces under a specific configuration pattern: a map block using regex matching, where the map’s output variable appears in a string expression after a numbered capture variable ($1, $2) from an earlier regex match.

nginx evaluates these expressions in two passes. Pass one measures how many bytes the result needs and allocates a buffer. Pass two fills it in. The problem: evaluating the map regex between the two passes overwrites the shared capture state. Pass one sizes the buffer for the original capture; pass two writes a different, attacker-influenced value into it. The write runs off the end of the allocation.

An unauthenticated attacker can send a crafted HTTP request and restart the nginx worker process — a denial of service. On systems where ASLR is disabled or can be bypassed, researcher Stan Shaw argues the overflow itself provides the ASLR bypass, making remote code execution realistic on a default Ubuntu 24.04 build. F5’s advisory frames RCE as conditional on ASLR being disabled; Shaw’s position is that the condition is self-fulfilling. He is withholding the proof-of-concept but has stated a 21-day disclosure timeline from the patch date, putting the window closing around August 5.

This is the third heap overflow disclosed in nginx’s expression-evaluation code in roughly two months, after CVE-2026-42945 (Rift) in May and CVE-2026-9256 days later. The shared root cause is a two-pass design that trusts the measurement it made in the first pass.

Who is affected

Every nginx version from 0.9.6 through 1.31.2 (mainline) and 0.9.6 through 1.30.3 (stable) is in scope — that range reaches back to 2011, when map gained regex support. For NGINX Plus, the affected range covers R37 (versions below 37.0.3.1), R36 (all versions below R36 P7), and R33 and earlier.

Exposure is configuration-dependent: if your nginx config has no map block combining regex matching with numbered capture variables, you are not on the path for this specific overflow. That said, the safest approach is still to upgrade rather than audit every virtual host’s config by hand.

Fixes

Upgrade to one of the following, all released July 15, 2026:

  • nginx 1.30.4 (stable branch)
  • nginx 1.31.3 (mainline branch)
  • NGINX Plus 37.0.3.1 or NGINX Plus R36 P7

If you cannot patch immediately, F5’s interim mitigation is to rewrite affected map blocks to use named captures ((?P<name>...)) instead of numbered ones. Shaw notes this closes the main exploitation path but leaves a narrower variant open when the same named group appears in both the location regex and the map block. Upgrading is the only complete fix.

Plesk Obsidian 18.0.79, released July 3, included an nginx update as part of its third-party component refresh. If you are already on 18.0.79, verify the nginx version actually running on your server — the update may already have you covered.

What this means for kalfaoglu.net customers

nginx is the reverse proxy and web server fronting virtually every site hosted here. We have already begun rolling out the patched packages. If you want to confirm the version running on your account, open a support ticket and we will check.

If you manage your own nginx configuration — on a custom VPS or through manual nginx directives in Plesk — review your map blocks for the pattern described above and upgrade. As of July 20, CVE-2026-42533 was not in CISA’s Known Exploited Vulnerabilities catalog, but Rift’s trajectory last May showed that exploitation follows quickly once a PoC is public. That window closes around August 5.