NGINX Plus and NGINX Open Source have a vulnerability in the ngxhttpv3module module. When using HTTP/3 with OpenSSL versions <= OpenSSL 3.5.0 under certain configurations, a limited heap buffer overflow could happen while processing a TLS handshake. This can happen in a non-deterministic manner that is beyond the attacker's control. This may cause a heap buffer overflow in the NGINX worker process leading to a restart and/or limited data corruption.

Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or limited data corruption. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

A vulnerability exists in NGINX JavaScript where a malformed HTTP response received by ngx.fetch() can crash an NGINX worker when trusted JavaScript reads Response.statusText. Exploitation requires control or influence over the fetched HTTP response.

Impact: This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description

NGINX JavaScript (njs) has a vulnerability in the XML module's namespace prefix list parser, reachable through the xml.exclusiveC14n() method. An unauthenticated remote attacker can trigger it when an affected NGINX configuration passes an externally controlled XML namespace prefix list to that method. Both the njs and the QuickJS (qjs) engines are affected. A crafted prefix list causes an out-of-bounds write past the end of a heap allocation. With the njs engine, which is the engine used when the jsengine directive is absent, this corrupts adjacent objects and crashes the NGINX worker. With the QuickJS engine, the same call additionally leaks the prefix list on every invocation, causing worker memory to grow across requests. The official nginxinc/nginx-saml reference implementation is affected during SAML signature verification. It reads InclusiveNamespaces/@PrefixList from an untrusted SAML message and passes it to xml.exclusiveC14n() before the signature has been verified, so a valid SAML signature is not required. A crafted SAML Response, Assertion, LogoutRequest, or LogoutResponse is sufficient. Code execution has not been demonstrated and cannot be ruled out for all platforms, as the effect of the out-of-bounds write depends on conditions beyond the attacker's control.

Impact

This vulnerability allows remote attackers to cause a denial of service on the NGINX system, either through repeatable worker restarts or through worker memory growth or possibly trigger code execution. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description

NGINX JavaScript (njs) and QuickJS (qjs) engines have a vulnerability when a jsaccess handler performs asynchronous request body processing and an exception is thrown during asynchronous access-control evaluation before an explicit access denial is returned. An unauthenticated attacker can exploit this vulnerability by sending a crafted HTTP request that triggers an error condition in the access validation logic. This may cause the jsaccess phase to fail open, allowing the request to proceed instead of being denied, resulting in an authentication or authorization bypass and unauthorized access to protected resources.

Impact

This vulnerability may allow remote attackers to bypass jsaccess controls. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Description: When NGINX Plus is configured as the data plane for NGINX Gateway Fabric, an injection vulnerability exists in the NGINX configuration generator component of NGINX Gateway Fabric. User-supplied string values from the Authentication Filter Custom Resource Definition clientID or cookieName fields, or in the clientSecret field of a Secret referenced by an Authentication Filter, are rendered directly into NGINX configuration templates without sanitization or escaping.

Impact: An authenticated attacker with permission to create or modify these resources may craft values that inject arbitrary NGINX configuration directives. This is a control plane issue; there is no data plane exposure.

When NGINX Ingress Controller is configured with Ingress annotations, an injection vulnerability exists in the configuration generator of NGINX Ingress Controller. Multiple user-controllable fields are written into the generated NGINX configuration without sanitization. An authenticated attacker with permission to create or modify these annotations may craft values that inject arbitrary NGINX configuration directives.

Impact: An authenticated attacker granted write access to NGINX Ingress Controller Ingress annotations through the Kubernetes API may be able to inject arbitrary NGINX configuration directives, create or delete files, or disable services. There is no data plane exposure; this is a control plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

This vulnerability allows remote attackers to execute arbitrary code on affected installations of NGINX. Authentication is not required to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.1. The following CVEs are assigned: CVE-2026-27654.

NGINX Plus and NGINX Open Source have a vulnerability in the ngxhttpslicemodule module. When the slice directive and unnamed regex captures are configured or when a background cache update happens, unauthenticated attackers can send requests that may cause uninitialized memory access in the NGINX worker process, leading to limited disclosure of memory or a restart.

Impact: This vulnerability may allow remote, unauthenticated attackers to have limited control to disclose memory contents or restart the NGINX worker process. There is no control plane exposure; this is a data plane issue only. Note: The ngxhttpslicemodule module is not enabled by default; it's enabled with the --with-httpslicemodule configuration parameter.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Last updated 20 July 2026

NGINX Plus and NGINX Open Source have a vulnerability in the ngxhttpssimodule module. This vulnerability may exist when the Server-Side Includes (SSI), proxypass, and proxybuffering off directives are configured. With this configuration, an unauthenticated attacker with man-in-the-middle (MITM) ability to control responses from an upstream server may be able to cause a heap buffer over-read in the NGINX worker process. This issue may lead to limited modification of memory or a restart of the NGINX worker process.

Impact: This vulnerability may allow remote attackers to have limited control to modify memory contents or restart the NGINX worker process. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Plus is configured to use the Message Queuing Telemetry Transport (MQTT) filter module (ngxstreammqttfiltermodule), unauthenticated attackers can send requests with conditions beyond the attacker's control to cause a heap buffer over-read in the NGINX worker process, leading to a restart.

Impact: This vulnerability may allow remote unauthenticated attackers to have limited control to restart the NGINX worker process. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

Last updated 20 July 2026

A vulnerability exists in NGINX Plus and NGINX Open Source when a map directive uses regex matching and a string expression references the map's regex capture variables before referencing the map output variable. Alternatively, the same result could be achieved by using a non-cacheable variable in a string expression under certain conditions. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

When NGINX Ingress Controller processes Ingress or TransportServer resources, an authenticated, remote attacker with permission to create or modify Ingress or TransportServer resources can cause the NGINX Ingress Controller process to terminate.

Impact: The NGINX Ingress Controller control plane process terminates and enters a persistent crash loop while the malformed Ingress or TransportServer resource remains in the cluster. This vulnerability allows a remote, authenticated attacker with at least Ingress or TransportServer resource write access to cause a denial-of-service (DoS) on the NGINX Ingress Controller system. There is no data plane exposure; this is a control plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Ingress Controller is configured with Custom Resource Definitions (CRDs) or Ingress annotations, an injection vulnerability exists in the configuration generator of NGINX Ingress Controller. Multiple user-controllable fields are written into the generated NGINX configuration without sanitization. An authenticated attacker with permission to create or modify these CRDs or annotations may craft values that inject arbitrary NGINX configuration directives.

Impact: An authenticated attacker granted write access to NGINX Ingress Controller CRDs or Ingress annotations through the Kubernetes API may be able to inject arbitrary NGINX configuration directives, create or delete files, or disable services. There is no data plane exposure; this is a control plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Gateway Fabric is configured using GRPCRoutes, an authenticated, remote attacker with permission to create or modify GRPCRoute resources can cause the NGINX Gateway Fabric control plane to terminate by sending undisclosed GRPCRoute configurations containing backendRef filters.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Plus or NGINX Open Source is configured as the data plane for NGINX Gateway Fabric, an injection vulnerability exists in the NGINX configuration generator component of NGINX Gateway Fabric. User-supplied string values from the NginxProxy Custom Resource Definition (CRD) access log format setting are rendered directly into NGINX configuration templates without sanitization or escaping. An authenticated attacker with permission to create or modify these CRDs may craft values that inject arbitrary NGINX configuration directives. This is a control plane issue; there is no data plane exposure from the vulnerability trigger itself.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Open Source has a vulnerability in the ngxhttpv3module module. When NGINX Open Source is configured to use the HTTP/3 QUIC module, a remote unauthenticated attacker along with conditions beyond their control can use a specially crafted HTTP/3 session to reopen a QPACK encoder stream. This may cause a Use-after-Free in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Plus and NGINX Open Source have a vulnerability in the ngxhttpproxyv2module and ngxhttpgrpcmodule modules. This vulnerability exists when the proxyhttpversion to 2 or grpcpass directives are used to proxy HTTP/2 traffic, the ignoreinvalidheaders directive is set to off, and the largeclientheaderbuffers directive size is larger than 2 megabytes. A remote, unauthenticated attacker, along with conditions beyond their control, could send large headers while creating an upstream request. This may cause a heap-based buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

When NGINX Plus is configured as the data plane for NGINX Gateway Fabric, an injection vulnerability exists in the NGINX configuration generator component of NGINX Gateway Fabric. User-supplied string values from the NginxProxy Custom Resource Definition serverTokens field and the AuthenticationFilter Custom Resource Definition extraAuthArgs field are rendered directly into NGINX configuration templates without sanitization or escaping. An authenticated attacker with permission to create or modify these Custom Resource Definitions may craft values that inject arbitrary NGINX configuration directives. This is a control plane issue; there is no data plane exposure from the vulnerability trigger itself.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX Open Source has a vulnerability in the ngxhttpv3module module. When NGINX Open Source is configured to use the HTTP/3 QUIC module, a remote unauthenticated attacker along with conditions beyond their control can use a specially crafted HTTP/3 session to reopen a QPACK encoder stream. This may cause a Use-after-Free in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

NGINX ngxhttpcharsetmodule vulnerability

We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against most major web servers, including:

nginx

Apache httpd

Microsoft IIS

Envoy

Cloudflare Pingora

The vulnerable behavior exists in each server's default HTTP/2 configuration.

The attack was discovered by Codex, which chained two techniques known to humans for a decade: a compression bomb and a Slowloris-style hold. The bomb targets HPACK, HTTP/2's header compression scheme: one byte on the wire becomes one full header allocation on the server, repeated thousands of times per request. The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it.

A curious search on Shodan revealed 880,000+ websites supporting HTTP/2 and running one of these servers, though many sit behind a CDN, which is much harder to bring down.

A home computer on a 100Mbps connection can render a vulnerable server inaccessible within seconds. Against Apache httpd and Envoy, a single client can consume and hold 32GB of server memory in roughly 20 seconds.

On 6/2/26 19:36, Alan Coopersmith wrote: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says: The fix commits above are public and disclose the vectors directly; any capable AI model can turn those diffs into a working exploit, which is exactly how we found that Microsoft IIS, Envoy, and Pingora are also vulnerable. We've notified their maintainers. Given how short the commit-to-exploit path now is, we're releasing this writeup to provide users with the mitigations below. Additional patches have since been released by envoy & h2o. Posts on twitter by @califio continue to discuss whether other packages are vulnerable or not.

https://github.com/envoyproxy/envoy/security/advisories/GHSA-22m2-hvr2-xqc8 says: HTTP/2 memory exhaustion via cookie header size bypass and HPACK amplification

phlax published GHSA-22m2-hvr2-xqc8 Jun 3, 2026

Package: github.com/envoyproxy/envoy Affected versions: <1.39 Patched versions: 1.35.11 1.36.7 1.37.3 1.38.1

Summary -------

A vulnerability in Envoy's HTTP/2 downstream request processing allows an unauthenticated remote client to trigger excessive memory consumption, potentially resulting in OOM termination of the Envoy process and denial of service.

The issue arises from the combination of two behaviors:

1. Cookie header bytes are not fully accounted for during request header size validation in Envoy. 2. HPACK header block limits in oghttp2/quiche are enforced on encoded bytes without a corresponding limit on total decoded header size.

Together, these behaviors allow a malicious client to cause large decoded header allocations while bypassing the intended request header size protections.

Affected Components -------------------

Envoy HTTP/2 downstream request processing Cookie header size accounting during header validation HPACK header block size enforcement in oghttp2/quiche

Details -------

During HTTP/2 request processing, cookie header fragments are buffered separately and merged only after request header size validation has completed. Because these buffered cookie bytes are not fully included in the effective header size check, oversized cookie data can bypass maxrequestheaderskb enforcement.

Separately, oghttp2/quiche enforces header block limits on encoded HPACK bytes rather than on the fully decoded header size. A malicious client can exploit this asymmetry by using dynamic table references to keep the encoded representation relatively small while causing the decoded cookie header value to become much larger in memory.

When these behaviors are combined, a client can force Envoy to retain large per-stream allocations. Under sustained concurrency, this can rapidly increase process memory usage and lead to OOM termination.

Flow-control stalling can further increase the effectiveness of the attack by prolonging stream lifetime and delaying reclamation of per-stream memory.

Impact ------

An unauthenticated remote attacker can cause denial of service by exhausting memory in the Envoy process.

In testing against envoyproxy/envoy-google-vrp-dev:latest (v1.36.0-dev), the Envoy edge process was OOM-killed under a 3 GiB memory limit within a few seconds using a limited number of HTTP/2 connections and streams.

Additional testing showed that the attack remained effective with significantly fewer connections and streams than initially required, indicating that exploitation can be efficient even under tighter attacker-side resource constraints.

A secondary operational effect observed during testing was that oversized decoded cookies forwarded upstream could exceed the upstream service's own header limits, potentially causing upstream HTTP/2 connection resets and transient request failures.

Attack Vector -------------

A malicious downstream HTTP/2 client sends specially crafted cookie headers that combine:

incomplete cookie-size accounting during request validation; and HPACK decoded-size amplification via small encoded representations.

The impact can be amplified further by using HTTP/2 flow-control behavior to extend stream lifetime and delay memory reclamation.

Patches -------

A complete fix requires addressing both contributing issues:

include buffered cookie bytes in request header size accounting before request acceptance; and enforce limits on decoded header size, not only on encoded HPACK block size.

Fixing only one side may reduce exploitability but does not fully address the underlying issue.

Workarounds -----------

No complete workaround is known short of applying a fix.

Possible temporary mitigations include:

disabling downstream HTTP/2 where operationally feasible; enforcing stricter request header and cookie limits before traffic reaches Envoy; and monitoring Envoy memory usage for abnormal growth under HTTP/2 traffic.

Detection ---------

Potential indicators of exploitation include:

rapid or sustained abnormal memory growth in the Envoy process; OOM termination, including exit status 137 in containerized environments; and unusual HTTP/2 traffic patterns involving repeated indexed cookie references.

Credits ------- Credit: Ryoga Yamashita.

Severity: High, 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID: CVE-2026-47774 https://github.com/h2o/h2o/security/advisories/GHSA-qcrr-wrhc-pgq9 says: HTTP/2 state amplification

kazuho published GHSA-qcrr-wrhc-pgq9 Jun 3, 2026

Package: h2o Affected versions: commits up to 8dc37cb Patched versions: 9265bdd and above

Impact ------

Recently, an attack against HTTP/2 servers was published that combines state amplification caused by HPACK decompression with Slowloris-style stream stalling: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb.

H2O reduces HPACK state amplification by representing HTTP header names and values internally as references where possible. However, in light of this attack, additional limits may be needed, depending on the configuration, to bound decoded header state and prevent amplified state from being retained by stalled HTTP/2 streams.

Patches ------- Mitigations were added in #3597 and landed on master as 9265bdd: https://github.com/h2o/h2o/pull/3597 https://github.com/h2o/h2o/commit/9265bdd9a996ed992681055e3996baf3e09d2063

References ---------- https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

Severity: High, 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID: No known CVE -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says: We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against most major web servers, including:

- nginx - Apache httpd - Microsoft IIS - Envoy - Cloudflare Pingora

The vulnerable behavior exists in each server's default HTTP/2 configuration. The blog tells the story of how it was found and provides technical details and PoCs.

It also says: Credits

Quang Luong for discovering the exploit. He'll be presenting his techniques at the upcoming Real World AI Security conference at Stanford in June.

Jun Rong and Duc Phan for confirming the attack on other web servers. and: Disclosure

We disclosed the issue to nginx in April. They responded by importing the maxheaders directive from freenginx, shipping it in 1.29.8 the next day: https://github.com/nginx/nginx/commit/365694160a85229a7cb006738de9260d49ff5fa2 At this point, we consider the attack public.

We disclosed to Apache on May 27, and Stefan Eissing fixed it on the same day by making cookie headers count against LimitRequestFields: https://github.com/apache/httpd/commit/47d3100b252dc6668a9e46ae885242be9eeca9cd The issue was assigned CVE-2026-49975.

The fix commits above are public and disclose the vectors directly; any capable AI model can turn those diffs into a working exploit, which is exactly how we found that Microsoft IIS, Envoy, and Pingora are also vulnerable. We've notified their maintainers. Given how short the commit-to-exploit path now is, we're releasing this writeup to provide users with the mitigations below.

Mitigations

nginx: Upgrade to 1.29.8+, which adds the maxheaders directive with a default of 1000. If you can't upgrade, disable HTTP/2 with http2 off;.

Apache httpd: The fix is in modhttp2 v2.0.41, available from the standalone modhttp2 releases and in httpd trunk but not yet in a 2.4.x release. If you can't upgrade, set Protocols http/1.1 to disable HTTP/2. Lowering LimitRequestFieldSize shrinks the per-stream blast radius (it caps the merged cookie, and so the crumb count), but it's only a partial mitigation, since an attacker can still multiply the effect across streams and connections. Lowering LimitRequestFields does nothing here: the duplicate cookie crumbs never count against it.

Microsoft IIS, Envoy, Cloudflare Pingora: No patch available at the time of writing. Disable HTTP/2 if you can, or front the server with something that enforces a hard cap on header count per request.

Generally: "Maximum decoded header size" and "maximum header count" are two different limits, and a server needs both. Any HTTP/2 termination point should cap the number of header fields per request, including cookie crumbs, independent of their total size, and should bound the lifetime of a stalled stream regardless of WINDOWUPDATE activity. And if you can't do any of that today: cap per-worker memory (cgroups, ulimit -v, container limits) tight enough that a bombed worker gets OOM-killed and respawned before it drags the box into swap. A worker process rarely needs gigabytes; letting the kernel kill one early is a better failure mode than letting the attacker hold the whole machine at 95%.

Takeaways

RFC 7541 has an entire section on this threat. §7.3 Memory Consumption opens with "an attacker can try to cause an endpoint to exhaust its memory," then explains that HPACK bounds the dynamic table via SETTINGSHEADERTABLESIZE and considers the matter handled. But when five independent implementations all read that section and still ship the same class of bug, the defect is in the spec.

The deeper miss is that the spec frames memory risk purely as an amplification ratio, and ratio is only half the equation. A 70:1 amplifier is harmless if the memory is freed when the request completes. It becomes an attack because HTTP/2 lets the client hold the connection open almost for free, pinning every allocated byte for as long as they like.

The other thing worth noting is how this exploit was found. Both halves have been public for a decade. What Codex did was read the codebases, recognize that the two compose, and build the combined attack. That combination is obvious once you see it, and yet as far as we can tell no human had put it together against these servers.

Red Hat OpenShift Data Foundation 4.14.33 security, enhancement & bug fix updateFIXED BUGS:==========DFBUGS-6993: RHODF 4.14.33 releaseNGINX: Arbitrary Code Execution Vulnerability (CVE-2026-42945)

Anthropic posted a blog yesterday giving an update on their Project Glasswing efforts to find, report, and disclose vulnerabilities in a wide range of software: https://www.anthropic.com/research/glasswing-initial-update

In it, they link to their new disclosure dashboard at: https://red.anthropic.com/2026/cvd/

It currently says: "As of May 22, 2026, we've disclosed 1,596 vulnerabilities across 281 open source projects. To our knowledge, 97 of these have been patched. Of those, 88 have been assigned a Common Vulnerabilities and Exposure (CVE) record or a GitHub Security Advisory (GHSA). In other cases, maintainers have shipped a fix without publishing an advisory. The number of vulnerabilities we've disclosed is a subset of the total number of vulnerabilities that Mythos Preview has found, since the process of independent human triage and review is the rate limiting step."

In their chart below that, they clarify that in this case, "disclosed" means "reported to maintainers", not made public.

They include a list of identifiers of their reports (currently up to 1611 entries), but do not show the project name or bug type until the project has fixed the bug.

They also include lists of CVE's and GHSA's that have been published for the issues they've found. The CVE list currently includes CVE's from nginx, jq, wolfSSL, and more. The GHSA list includes libyang, mastodon, freerdp, and more.

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

[Disclaimer: while my employer is identified in the blog post as a partner, I am not personally involved with Project Glasswing, and know nothing more about it than what has been publicly disclosed.]

https://github.com/nginx/nginx/releases announces releases 1.31.1 and 1.30.2 containing a fix for a "buffer overflow vulnerability in the ngxhttprewritemodule (CVE-2026-9256)."

https://my.f5.com/manage/s/article/K000161377 gives this additional detail: NGINX Plus and NGINX Open Source have a vulnerability in the ngxhttprewritemodule module. This vulnerability exists when a rewrite directive uses a regex pattern with distinct, overlapping Perl-Compatible Regular Expression (PCRE) captures (for example, ^/((.))$) and a replacement string that references multiple such captures (for example, $1$2) in a redirect or arguments context. An unauthenticated attacker along with conditions beyond their control can exploit this vulnerability by sending crafted HTTP requests. This may cause a heap buffer overflow in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. (CVE-2026-9256)

Impact

This vulnerability may allow remote attackers to cause a denial-of-service (DoS) on the NGINX system or to possibly trigger a code execution. There is no control plane exposure; this is a data plane issue only.