Eclipse API Gateway EUVD-2026-102030

Exploitation requires the gateway to run the shipped DEFAULT configuration where ClientIpKeyResolver is the active rate-limit key resolver, and applies to every route using that default rate-limiting. The specific trigger is any attacker-controlled X-Forwarded-For request header, since the leftmost element is used verbatim as the bucket key with no trusted-proxy validation. No authentication, user interaction, or special privileges are needed (PR:N/UI:N). The key LIMITING factor is configuration-dependence: deployments that replace the default key resolver, configure a trusted-proxy list, or do not enable rate limiting on their routes are not exposed; the flaw also only degrades availability, not confidentiality or integrity.

This is a genuine but moderate-priority availability issue, not a confidential-data or code-execution emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5) is internally consistent with the description: any remote, unauthenticated attacker can trivially vary the X-Forwarded-For header, and the only impact is to availability (C:N/I:N), reflecting a bypass of the gateway's rate-limiting protection rather than a breach of authentication or data. The CISA SSVC signals align - Exploitation: none (no observed in-the-wild activity), Automatable: yes (a scripted header-rotation loop is trivial to mass-produce), Technical Impact: partial - which matches a protection-mechanism bypass that degrades availability without fully compromising the system. There is no CISA KEV listing and no EPSS score was provided, so there is no evidence of widespread or active exploitation; the fix PR #330 is public but no standalone proof-of-concept exploit was supplied. Net: a real, easily-automatable defensive gap that should be patched, but it enables denial-of-service / rate-limit evasion rather than system takeover, so it ranks below critical RCE/auth-bypass flaws despite the 7.5 'High' rating. Note a labeling tension worth verifying with the vendor: the CWE-290 classification and 'Authentication Bypass' tag frame this as a spoofing/auth-bypass issue, whereas the description and CVSS impact describe a rate-limit (availability) bypass.

An attacker sends a flood of requests to any default-configured route, assigning a unique, forged value to the X-Forwarded-For header on each request. Because ClientIpKeyResolver trusts the leftmost (client-supplied) element without checking a trusted-proxy list, every unique value is granted its own fresh rate-limit bucket, so the per-client throttle never trips and the attacker overwhelms the protected backend. No proof-of-concept exploit was provided, but the official fix (PR #330) is public and the technique is trivially scriptable given AV:N/AC:L/PR:N.