A gateway can enforce authentication perfectly and still fall over before authentication becomes the interesting question. CVE-2026-94250 is a useful reminder that API gateway security is also resource accounting. When APISIX exposes the batch-requests endpoint, one external request can cause the gateway to assemble and retain work for multiple internal requests. On affected releases, that aggregation can push a worker into out-of-memory failure. That turns a convenience feature into an availability boundary. The security review cannot stop at “who can reach the API?” It also has to ask “how much work can one reachable request force the gateway to perform?” **In practical terms, it is a good time to:** - inventory APISIX instances and verify the running version, not just the package or image tag - identify routes exposing `/apisix/batch-requests` or a custom URI mapped to it - inspect `conf/config.yaml` and deployed route configuration for `batch-requests` and `public-api` - compare configured batch body, pipeline-item, and response-size limits with realistic production traffic - load-test batch routes while watching worker RSS, OOM events, latency, and upstream amplification How many gateway reviews in your environment explicitly test resource amplification rather than only authentication and routing? #LinuxSecurity #APISIX #CloudSecurity #DevSecOps #InfrastructureSecurity https://linuxsecurity.com/news/security-vulnerabilities/apisix-denial-of-service-attack-batch-requests