help request: Will APISIX be affected by the vulnerability CVE-2026-49975?

[twobunches]

Description

APISIX is developed based on Nginx. Nginx versions < 1.29.8 are affected by this vulnerability. Then, does the APISIX version need to be upgraded?

Environment

• APISIX version (run apisix version):
• Operating system (run uname -a):
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[janiussyafiq]

Thanks for raising this. Short answer: yes, APISIX is affected, because of the nginx core it currently bundles.

CVE-2026-49975 ("HTTP/2 Bomb") is fixed in nginx 1.29.8 via the new max_headers directive (nginx CHANGES). APISIX runs on apisix-runtime, built from OpenResty 1.29.2.4, whose bundled nginx core is 1.29.2 which is older than that fix. This applies to all current releases including 3.17.0, so upgrading APISIX does not resolve it today.

Since the vulnerable code lives in the nginx core that OpenResty bundles, the fix needs to arrive through OpenResty first. OpenResty has not yet shipped a release based on nginx ≥ 1.29.8 (tracked in openresty/openresty#1128); once it does, APISIX can pick it up through an apisix-runtime upgrade.

In the meantime, practical mitigations:

1. Disable HTTP/2 if your workload allows: set apisix.enable_http2: false in config.yaml (default is true). Note this breaks gRPC proxying, which requires HTTP/2.
2. Front APISIX with an already-patched HTTP/2 terminator (an updated CDN/LB that enforces header-count limits) and forward HTTP/1.1 to APISIX.
3. Cap worker memory (cgroups/container limits) so an attack OOM-kills a worker process rather than the host; nginx respawns workers automatically.
4. The attack is HTTP/2-specific; HTTP/1.1 and HTTP/3 paths are not affected by this CVE.

Hope this helps!