Eclipse api-gateway EUVD-2026-102029

Exploitable only when the gateway runs the shipped default configuration using ClientIpKeyResolver as the rate-limit key resolver AND rate limiting is enabled on the route(s), because the resolver derives the bucket key from the leftmost, client-controlled X-Forwarded-For element without validating it against a trusted-proxy list. No authentication, no user interaction, and no non-default feature flag is required beyond that default. LIMITING FACTORS: deployments that replace ClientIpKeyResolver with a custom resolver, enforce a trusted-proxy allowlist, or terminate/sanitize X-Forwarded-For at an upstream proxy before the gateway are not affected; routes without rate limiting configured gain nothing to bypass.

This is a genuine but moderate-priority issue, best characterized as a security-control (rate-limiting) bypass rather than a high-impact system compromise. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) correctly reflects that exploitation is remote, low-complexity, unauthenticated, and requires no user interaction - a single attacker simply varies the leftmost X-Forwarded-For value. However, the signals are mild: EPSS is 0.15% (4th percentile), there is no CISA KEV listing, no public exploit code, and CISA SSVC rates Exploitation as 'none' with only 'partial' Technical Impact (though 'Automatable: yes', consistent with trivial header manipulation). One signal conflict worth flagging: NVD/vendor scored impact as C:N/I:H/A:N (Integrity High), but the described effect - defeating per-client request throttling - is functionally an availability/abuse-protection bypass enabling flooding, brute-force, and resource exhaustion of downstream routes, not a data-integrity violation; the I:H choice looks questionable and the 7.5 score likely overstates direct impact. Net: real and easy to trigger against default configs, but the consequence is erosion of a defensive control rather than direct code execution or data loss, so prioritize patching where the gateway is internet-facing and relies on rate limiting for abuse/DoS protection, below any RCE/auth-bypass work.

An attacker targeting an internet-facing Eclipse Connected Services Platform api-gateway (default config using ClientIpKeyResolver) sends each request with a different spoofed X-Forwarded-For value (e.g. incrementing a fake IP). Because the gateway trusts the leftmost client-supplied header element without a trusted-proxy check, every unique value gets its own fresh rate-limit bucket, so the attacker issues effectively unlimited requests and nullifies per-client throttling, enabling high-volume brute-force or request-flooding of protected routes. No public exploit code is identified, but the technique requires only trivial header manipulation.