Eclipse api-gateway CVE-2026-110726

Applies to deployments that run the shipped default rate-limiting configuration using ClientIpKeyResolver as the key resolver on one or more routes, where the gateway is reachable by clients that can set arbitrary X-Forwarded-For headers and no trusted-proxy allowlist validates that header. The decisive condition is the absence of trusted-proxy validation on the leftmost X-Forwarded-For element. Limiting factors: deployments that replace the default key resolver, enforce a trusted-proxy list, or strip/normalize X-Forwarded-For at an upstream proxy are not affected; routes without rate limiting enabled are unaffected. No authentication is required to spoof the header, despite the vendor's PR:L rating.

This is a medium-severity (CVSS 6.5) rate-limiting bypass (CWE-348, reliance on an untrusted source). The attack surface is favorable to an attacker: AV:N/AC:L/UI:N means remote, trivial, non-interactive exploitation. The vendor assigned PR:L, but spoofing a client-supplied X-Forwarded-For header requires no credentials, so realistically this is unauthenticated (PR:N) - I diverge from the vendor here. Impact is availability-only (C:N/I:N/A:H): the flaw removes an abuse/DoS protection rather than exposing or altering data, so it is an enabler for resource-exhaustion attacks, not a direct compromise. No EPSS score, KEV listing, or POC was provided in the input, so there is no evidence of active or at-scale exploitation - this is a design weakness with a clear root cause (confirmed in source), not a demonstrated in-the-wild threat. Net: a legitimate fix-it priority for internet-facing gateways running the shipped default configuration, but tempered by availability-only impact and the product's narrow deployment footprint; it is not a drop-everything emergency absent exposure data.

An attacker repeatedly calls a rate-limited gateway route, setting a unique/random X-Forwarded-For value on each request. Because the default ClientIpKeyResolver keys each bucket off that attacker-controlled leftmost header element, every distinct value gets its own fresh quota, so the per-client limit never trips and the attacker can flood backend services unbounded. No public exploit code was identified, but the root cause and fix are documented in the vendor's pull request.