Eclipse Foundation Eclipse Connected Services Platform vulnerabilities
🔔 Create alert RSS Version checker
Published CVEs affecting Eclipse Foundation Eclipse Connected Services Platform: 3 record(s), with affected versions and fixes.
CVE-2026-110724
Unknown
CWE-269 Oct 15, 2026
Improper Privilege Management in Eclipse Foundation Eclipse Connected Services Platform
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.
CVE-2026-110723
High · 7.5
CWE-290 Oct 15, 2026
Authentication Bypass by Spoofing in Eclipse Foundation Eclipse Connected Services Platform
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.
CVE-2026-110726
Medium · 6.5
CWE-348 Oct 15, 2026
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver…
In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.