A vulnerability scanner can tell you that an NGINX package is old. It cannot tell you whether a request can reach the map, slice, SSI, proxy, and buffering combination that makes a specific bug exploitable.

On July 15, 2026, NGINX released open-source versions 1.30.4 and 1.31.3 with fixes for three vulnerabilities. One is rated major by NGINX and two are rated medium. None should be silently upgraded into a claim of universal remote code execution: each has configuration or attacker-position conditions that change the practical risk.

TL;DR

  • CVE-2026-42533 is a buffer overflow involving map and regular expressions; NGINX rates it major.
  • CVE-2026-60005 is a memory-disclosure issue in ngx_http_slice_module.
  • CVE-2026-56434 is a use-after-free involving SSI, proxy_pass, and proxy_buffering off; the official description also requires control of an upstream response through a man-in-the-middle position.
  • NGINX Open Source 1.30.4 and 1.31.3 are listed as not vulnerable to all three.
  • Patch first, but audit compiled modules and active configuration so you know which exposure actually existed.

Three Bugs, Three Different Preconditions

The fixed version boundary is easy. The vulnerable path is not.

CVENGINX severityRelevant featureFixed open-source versions
CVE-2026-42533Majormap with regular-expression behavior1.30.4+, 1.31.3+
CVE-2026-60005Mediumngx_http_slice_module1.30.4+, 1.31.3+
CVE-2026-56434MediumSSI with proxying and buffering disabled1.30.4+, 1.31.3+

CVE-2026-42533: map and Regex State

NGINX describes CVE-2026-42533 as a buffer overflow when using map and regex. The vulnerable open-source range is listed as 0.9.6 through 1.31.2. The configuration matters because map can derive a variable from request-controlled values such as a host name, URI, cookie, or header, and regex captures may then be reused elsewhere.

F5’s CVE record says crafted requests may restart the worker and that code execution is possible where Address Space Layout Randomization (ASLR) is disabled or the attacker can bypass it. That supports treating the bug as potentially code-executing under the stated conditions. It does not support labelling every old NGINX server “confirmed RCE” without checking its configuration and mitigations.

CVE-2026-60005: Slice-Based Memory Disclosure

The second issue affects ngx_http_slice_module, which divides a response into subrequests for byte ranges and can be used with caching. F5 says the flaw can occur when slice and unnamed regex captures are configured, or during a background cache update. Crafted requests may cause access to uninitialized memory, producing limited memory disclosure or a worker restart. NGINX lists versions 1.15.8 through 1.31.2 as vulnerable.

The module is not enabled in the default build; it requires the --with-http_slice_module configure option. The first exposure question is therefore not simply “Is NGINX installed?” It is “Was the slice module built, and did an attacker-reachable path satisfy the slice, regex-capture, or cache-update conditions?”

CVE-2026-56434: SSI, Proxying, and an Upstream Attacker

The third flaw is narrower. F5’s CVE description says the vulnerable configuration combines:

  • Server-Side Includes through ngx_http_ssi_module
  • proxy_pass
  • proxy_buffering off
  • an attacker able to control an upstream response through a man-in-the-middle position

Under those conditions, the attacker may trigger a use-after-free in an NGINX worker. The stated impact is limited memory modification or a worker restart, with no control-plane exposure. This is a data-plane issue.

That is serious, but it is not an unauthenticated internet client directly taking over every SSI-enabled server. Attacker position and upstream trust are part of the finding.

Audit What Is Running

Start by recording the binary and its build options:

Terminal window
nginx -v
nginx -V 2>&1

nginx -V shows configure arguments, including statically compiled modules. Dynamically loaded modules also need to be checked from configuration and package inventory.

Dump the effective configuration after all included files are resolved:

Terminal window
sudo nginx -T 2>&1 | less

Then search a saved configuration dump for the relevant directives. Keep this as an audit aid, not as proof by itself:

Terminal window
sudo nginx -T > /tmp/nginx-effective.conf 2>&1
rg -n 'map\s|slice\s|ssi\s+on|proxy_pass|proxy_buffering\s+off' \
  /tmp/nginx-effective.conf

For each match, answer four questions:

  1. Which public or internal listener reaches this block?
  2. Which part of the request or upstream response can an attacker control?
  3. Is the relevant module actually present in the running binary?
  4. Does traffic traverse this configuration in production, or is it dead configuration?

Delete the temporary dump after review if it contains private hostnames, upstream addresses, or other sensitive configuration data.

Package Versions Are Not Upstream Versions

Distribution maintainers often backport security fixes without changing the visible upstream version to the latest release. A package named nginx 1.26.x is not automatically vulnerable merely because nginx.org lists 1.30.4 and 1.31.3 as fixed upstream releases.

On CachyOS and other Arch-family systems, check the installed package and pending repository version:

Terminal window
pacman -Qi nginx
pacman -Si nginx

For container images, inspect the exact digest and the package database inside the image. A mutable tag such as nginx:stable does not prove which build is running. For NGINX Plus, ingress controllers, gateway products, and appliances embedding NGINX, use the specific vendor advisory; the open-source version boundary may not map cleanly to the product release.

Patch and Validate

A safe sequence is:

  1. Inventory NGINX Open Source, NGINX Plus, container, ingress, and embedded instances separately.
  2. Apply the vendor or distribution package containing the fixes.
  3. Validate syntax with nginx -t before reload.
  4. Reload through the service manager or deployment process used by that environment.
  5. Confirm the running binary and workers actually changed.
  6. Exercise representative map, cache-slice, SSI, proxy, HTTP/2, and HTTP/3 paths after the update.
  7. Review worker exits, segmentation faults, core dumps, and unexplained upstream-response errors from the pre-patch period.

Memory-safety bugs may leave only a crashed and automatically restarted worker. That is not proof of exploitation, but repeated worker deaths on attacker-reachable paths deserve investigation.

Version scanning is still useful. It identifies candidates quickly. Configuration analysis tells you whether the vulnerable code path was part of the service you were actually running.

Sources