Just one month after NGINX Rift (CVE-2026-42945) moved from public disclosure to confirmed active exploitation in under three days, F5 has issued another out-of-band advisory for two more critical vulnerabilities in NGINX. Neither has been confirmed as exploited in the wild yet, but the precedent set by NGINX Rift makes the race to patch these a short one.
NGINX is the web server software that handles incoming traffic for roughly a third of all internet-facing websites and applications. It acts as the front door for web services, API platforms, and the Kubernetes infrastructure running modern cloud applications. When a customer visits your website, submits a form, or uses your mobile app, there is a high chance an NGINX server is processing that request.
On June 17, 2026, F5 released emergency security patches for two critical flaws in NGINX. These were not part of a scheduled update cycle; F5 issued them ahead of their normal release schedule, which is a signal in itself. Vendors do not do that without good reason.
The practical risk is straightforward. Both vulnerabilities can be triggered by any attacker who can reach an affected NGINX server over the internet, with no login required. The immediate result is that the NGINX server crashes and restarts, disrupting service for users. On systems where a specific security setting is disabled, an attacker can go further and take full control of the server.
Neither vulnerability requires a sophisticated attacker. Proof-of-concept exploit code for CVE-2026-42530 is already publicly available on GitHub. Last month, similar code for NGINX Rift was published on the same day as the advisory, and real-world attacks followed within three days.
The good news is that while these are serious and the window for unhurried response is narrow, the patches are available now.
The two vulnerabilities
CVE-2026-42530: Use-after-free in the HTTP/3 module (ngx_http_v3_module)
CVSS v4: 9.2 (Critical)
This vulnerability exists in NGINX's HTTP/3 implementation. HTTP/3 is the newest version of the web protocol, designed to be faster than its predecessors, and NGINX added support for it as part of its mainline development track.
The flaw is a use-after-free condition, a class of memory vulnerability where a piece of software continues to hold a reference to memory it has already released. In this case, the problem lies in how NGINX handles a component of the HTTP/3 protocol called the QPACK encoder stream. QPACK is the header compression mechanism HTTP/3 uses to reduce the amount of data sent with each request.
An HTTP/3 connection uses a dedicated stream to carry QPACK encoder instructions. That stream is supposed to be opened once per connection and stay open. The vulnerability occurs when a malicious client reopens that stream mid-session using a specially crafted HTTP/3 exchange. When this happens, the NGINX worker process ends up holding a pointer to a stream-level memory object that has already been freed. When that stale pointer is next accessed, the result is memory corruption.
CyStack researcher Trung Nguyen, credited alongside several others for discovering and reporting this flaw, described the root cause as a "lifetime mismatch": a session-level pointer holds a reference to memory that belongs to a short-lived unidirectional stream. When the stream closes and its memory is freed, the session-level pointer is not cleared, leaving it dangling.
The immediate result of a successful exploitation attempt is a crash and automatic restart of the affected NGINX worker process: a denial-of-service condition that can be sustained by repeated requests. On systems where Address Space Layout Randomization (ASLR) is disabled, or where an attacker can find a way around it, the memory corruption can be turned into arbitrary code execution on the server.
Affected versions: NGINX Open Source 1.31.0 and 1.31.1. This is the mainline branch, adopted specifically for HTTP/3 support, so anyone who has updated to access HTTP/3 functionality is in this window.
Exposure condition: The HTTP/3 QUIC module must be enabled in the NGINX configuration. HTTP/3 support is not active by default; it requires explicit configuration with listen ... quic and http3 on. Deployments that have not enabled HTTP/3 are not exposed to this specific flaw.
Fixed in: NGINX Open Source 1.31.2.
Public proof-of-concept exploit code for this vulnerability has already been published on GitHub.
CVE-2026-42055: Heap-based buffer overflow in the HTTP/2 proxy and gRPC modules (ngx_http_proxy_v2_module and ngx_http_grpc_module)
CVSS v4: 9.2 (Critical)
This vulnerability affects NGINX when it is acting as a reverse proxy forwarding traffic to upstream services over HTTP/2 or gRPC. It is a heap-based buffer overflow: a condition where data written into a buffer exceeds the space allocated for it, overwriting adjacent memory regions.
The root cause involves a size miscalculation in the HPACK header encoding logic. When NGINX builds the request it will forward upstream, it reserves a fixed four bytes for the length prefix of each HPACK string. However, the HPACK variable-length integer encoder outputs five bytes when a string length exceeds approximately 2 MB. The result is that each oversized header field causes a write to run slightly past the allocated region, placing attacker-controlled HPACK data in memory the server has not set aside for it.
Three specific configuration conditions must all be present simultaneously for the vulnerability to be reachable:
- A location block is configured with
proxy_http_version 2orgrpc_pass(NGINX is proxying to an HTTP/2 or gRPC upstream) - The
ignore_invalid_headersdirective is set tooff(this is not the default; the default ison, which means NGINX silently discards headers with non-standard characters before they reach the proxy logic) - The
large_client_header_buffersdirective is configured with a per-buffer size above 2 MB (the default is four buffers of 8 KB each, well below the threshold)
Deployments using the NGINX default configuration are not exposed. The conditions required are non-default, but they are realistic in API gateway and gRPC infrastructure deployments, where operators sometimes relax header restrictions to accommodate legacy or non-standard client behavior, and increase header buffer sizes to handle large request payloads.
Sustained exploitation creates a crash loop in the NGINX worker process. On systems where ASLR is disabled or can be bypassed, the overflow gives an attacker control over execution.
Affected versions: NGINX Open Source 1.13.10 through 1.31.1 and NGINX Plus R33 through R36 (and R37.0.0 through R37.0.1). The version range here is broader than CVE-2026-42530, reaching back to 2017.
Fixed in: NGINX Open Source 1.30.3 and 1.31.2; NGINX Plus R36 P6 and R37.0.2.1.
The ASLR caveat
Both vulnerabilities carry a note that code execution requires ASLR to be disabled or bypassed. Some coverage of these flaws has used that caveat to suggest the risk is limited. That framing is worth pushing back on.
ASLR is enabled by default on modern Linux distributions, and most internet-facing NGINX deployments are not running with ASLR disabled. So the code execution path is genuinely harder to reach for the majority of targets. That is accurate.
What that framing underweights is the DoS path, which requires no such conditions. An attacker who can reach the server and trigger either flaw reliably crashes and restarts NGINX worker processes. For organizations where web availability is directly tied to operations, revenue, or user access, a sustained crash loop is a significant operational incident, regardless of whether code execution is achieved.
Additionally, ASLR is not an absolute barrier. Techniques to bypass or defeat ASLR exist and are documented in public research. For a motivated attacker, "requires ASLR to be disabled or bypassed" is a constraint that raises the effort level; it does not make exploitation impossible. The lower-severity CVE-2026-48142, a heap buffer over-read in the charset module patched in the same advisory, has been noted by researchers as a potential information-disclosure primitive that could be chained to defeat ASLR ahead of the more critical flaws.
The CVSS v4 score of 9.2 reflects the full picture. Treat the ASLR caveat as a mitigating factor that affects the realistic population of at-risk systems, not as a reason to delay patching.
A word on timing
F5 did not wait for its scheduled quarterly security release cycle to publish these patches. An out-of-band advisory signals that F5 judged the severity high enough to warrant an unscheduled release. The same was true of NGINX Rift last month, and exploitation of that flaw began within three days of its advisory being published.
CVE-2026-42530 is particularly likely to attract rapid exploit development. It affects only NGINX 1.31.0 and 1.31.1, which are recent mainline releases adopted specifically for HTTP/3 support. Operators who updated for that feature are running the vulnerable versions by definition. The affected configuration (HTTP/3 enabled) is a forward-looking deployment choice, not an obscure edge case, and proof-of-concept code is already public.
Neither vulnerability had confirmed in-the-wild exploitation at the time this article was written. That window is likely to be short.
Affected products
CVE-2026-42530
| Product | Affected Versions | Fixed In |
|---|---|---|
| NGINX Open Source | 1.31.0 – 1.31.1 | 1.31.2 |
| NGINX Gateway Fabric | 1.3.0 – 1.6.2 and 2.0.0 – 2.6.3 | 2.6.4+ |
| NGINX Instance Manager | 2.17.0 – 2.22.0 | Pending |
| NGINX Ingress Controller | 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.5.0 | Pending |
CVE-2026-42055
| Product | Affected Versions | Fixed In |
|---|---|---|
| NGINX Open Source | 1.13.10 – 1.30.2 and 1.31.1 | 1.30.3 and 1.31.2 |
| NGINX Plus | R33 – R36 and R37.0.0 – R37.0.1 | R36 P6 and R37.0.2.1 |
| NGINX Gateway Fabric | 1.3.0 – 1.6.2 and 2.0.0 – 2.6.3 | 2.6.4+ |
| NGINX Instance Manager | 2.17.0 – 2.22.0 | Pending |
| NGINX Ingress Controller | 3.5.0 – 3.7.2, 4.0.0 – 4.0.1, 5.0.0 – 5.5.0 | Pending |
| F5 WAF for NGINX | 5.9.0 – 5.13.1 | Pending |
| NGINX App Protect WAF | 4.10.0 – 4.16.0 and 5.2.0 – 5.8.0 | Pending |
| F5 DoS for NGINX / NGINX App Protect DoS | 4.9.0 and 4.3.0 – 4.7.0 | Pending |
Products listed as "Pending" for fix versions have not yet received patches from F5. Apply interim mitigations and monitor F5's advisory portal for updates.
What should you do?
1. Identify your exposure
For CVE-2026-42530, check whether HTTP/3 is enabled in your NGINX configuration:
grep -rn 'quic\|http3' /etc/nginx/
If listen ... quic or http3 on appears in your configuration and you are running NGINX Open Source 1.31.0 or 1.31.1, you are exposed.
For CVE-2026-42055, check whether all three trigger conditions are present:
# Check for HTTP/2 proxying or gRPC
grep -rn 'proxy_http_version 2\|grpc_pass' /etc/nginx/
# Check for ignore_invalid_headers off
grep -rn 'ignore_invalid_headers' /etc/nginx/
# Check large_client_header_buffers size
grep -rn 'large_client_header_buffers' /etc/nginx/
You are exposed to CVE-2026-42055 only if all three of the following are true: HTTP/2 proxying or gRPC is configured, ignore_invalid_headers is set to off, and large_client_header_buffers is configured with a per-buffer size above 2 MB.
2. Patch immediately
For NGINX Open Source:
# Ubuntu / Debian
sudo apt-get update && sudo apt-get install nginx
# RHEL / Rocky / AlmaLinux / Amazon Linux
sudo dnf update nginx
# SUSE / openSUSE
sudo zypper update nginx
# Arch Linux
sudo pacman -Syu nginx
Target version: NGINX Open Source 1.31.2 (resolves both CVEs). For those on the stable branch, 1.30.3 resolves CVE-2026-42055.
For NGINX Plus: target R36 P6 or R37.0.2.1. Consult the F5 security advisory portal for the full matrix across Instance Manager, App Protect, Gateway Fabric, and Ingress Controller.
After upgrading, verify the running version and reload:
nginx -v
sudo nginx -t && sudo systemctl reload nginx
3. If you cannot patch immediately: apply interim mitigations
For CVE-2026-42530: Disable HTTP/3 by removing the quic parameter from all listen directives and removing or commenting out http3 on. After making changes, test and reload:
# Before (vulnerable)
listen 443 quic;
http3 on;
# After (mitigated)
listen 443 ssl;
# http3 on;
sudo nginx -t && sudo systemctl reload nginx
This eliminates the attack surface entirely since the vulnerability is only reachable when HTTP/3 is active.
For CVE-2026-42055: Either remove the ignore_invalid_headers off directive from your configuration (restoring the default behavior of on), or reduce the large_client_header_buffers per-buffer size below 2 MB. You only need to change one of these two settings; both are not required.
If your environment genuinely requires both large header buffers and permissive header handling for legitimate traffic, the only available mitigation is patching. These configurations together are the prerequisite for the vulnerability, and removing either one eliminates the trigger condition.
4. For Kubernetes environments
If you are running NGINX Ingress Controller or NGINX Gateway Fabric in Kubernetes, the vulnerable configuration may be managed through Ingress annotations or HTTPRoute resources rather than direct nginx.conf editing. Review your Ingress resources for relevant configuration, and update to patched versions of Ingress Controller and Gateway Fabric as soon as they are available from your distribution channel.
5. Monitor for exploitation
For CVE-2026-42530, look for HTTP/3 connection errors and worker process crashes in the NGINX error log:
grep "worker process" /var/log/nginx/error.log | grep -E 'exited|signal'
journalctl -u nginx --since "24 hours ago" | grep -i "started\|stopped\|failed"
Repeated short-interval worker restarts associated with unusual HTTP/3 traffic are a strong signal of exploitation attempts.
For CVE-2026-42055, monitor for similar worker crash patterns correlated with HTTP/2 proxy or gRPC traffic.
The broader pattern
This is the second and third time in five weeks that NGINX has been the subject of a critical advisory. NGINX Rift (CVE-2026-42945) in May, and now two more critical flaws in June. None of this reflects a sudden change in the security of the codebase; it reflects a research community actively examining NGINX following the high-profile disclosure of NGINX Rift, and an F5 team processing multiple submissions arriving close together.
What it does mean practically is that NGINX patch cadence, configuration audits, and detection coverage are worth treating as recurring operational priorities rather than one-off responses. Three critical advisories in five weeks is not a pace that fits comfortably into quarterly maintenance windows.
Summary
| CVE-2026-42530 | CVE-2026-42055 | |
|---|---|---|
| CVE | CVE-2026-42530 | CVE-2026-42055 |
| CVSS v4 Score | 9.2 (Critical) | 9.2 (Critical) |
| Type | Use-after-free (CWE-416) | Heap-based buffer overflow (CWE-122) |
| Affected Module | ngx_http_v3_module | ngx_http_proxy_v2_module, ngx_http_grpc_module |
| Affected Versions | NGINX Open Source 1.31.0 – 1.31.1 | NGINX Open Source 1.13.10 – 1.31.1; NGINX Plus R33 – R36, R37.0.0 – R37.0.1 |
| Exposure Condition | HTTP/3 QUIC module enabled | HTTP/2 proxying or gRPC, ignore_invalid_headers off, large_client_header_buffers > 2 MB |
| Immediate Impact | Unauthenticated DoS (worker crash loop) | Unauthenticated DoS (worker crash loop) |
| Full RCE? | Yes, if ASLR is disabled or bypassed | Yes, if ASLR is disabled or bypassed |
| Public PoC? | Yes — multiple on GitHub | Not confirmed at time of writing |
| Active Exploitation? | Not confirmed at time of writing | Not confirmed at time of writing |
| Interim Mitigation | Disable HTTP/3 (remove quic from listen directives) |
Remove ignore_invalid_headers off, or reduce large_client_header_buffers below 2 MB |
| Full Fix | NGINX Open Source 1.31.2 | NGINX Open Source 1.30.3 or 1.31.2; NGINX Plus R36 P6 or R37.0.2.1 |
| Disclosed | June 17, 2026 (out-of-band) | June 17, 2026 (out-of-band) |
| Credited Researchers | Trung Nguyen (CyStack), Zhenpeng Lin (depthfirst), Evan Hellman (Trail of Bits / OpenAI collaboration), AntAISecurityLab, Nebula Security | Mufeed VH (Winfunc Research), Trung Nguyen (CyStack), Feng Xue and XGPT (ThreatBook), Hcamael and others (aipyapp), Zhen Yan (AntAISecurityLab) |
F5 has not flagged either vulnerability as exploited in attacks, but the out-of-band release, the availability of public proof-of-concept code for CVE-2026-42530, and the precedent of NGINX Rift all argue strongly against waiting. Interim mitigations are a one-line configuration change in most cases and can be applied without a full maintenance window.
If you need help auditing your NGINX configurations for exposure to either vulnerability, reviewing your Kubernetes ingress controller versions, or building detection coverage for exploitation attempts across your fleet, get in touch. Two critical NGINX advisories in one month is the kind of pattern that deserves a systematic look at your NGINX security posture, not just a pair of individual patch tickets.