Fleet CVE-2026-24000

The vulnerability requires that Fleet receive HTTP requests with client IP header injection. Specific conditions: (1) The attacker must be able to send HTTP requests to Fleet with custom headers; this is trivial for any network-accessible Fleet instance. (2) Fleet must be configured to extract client IP from headers (the default behavior); there is no mention of this being optional. (3) Rate limiting must be enforced on the target endpoint (authentication endpoints are typically rate-limited, making this a realistic condition). (4) The attacker must know or guess valid usernames or weak passwords to make the brute-force effective; however, password-spraying against common credentials is feasible. (5) Critically, if Fleet is deployed behind a trusted reverse proxy or load balancer that overwrites these headers before they reach Fleet, exploitation is prevented. Therefore, the primary limiting factor is deployment architecture: the vulnerability is only exploitable if Fleet receives untrusted network traffic directly or from an untrusted intermediary that does not rewrite IP headers.

This vulnerability presents a moderate real-world risk limited primarily by its scope and prerequisites. CVSS score is not available from vendor data, preventing direct comparison to industry baselines; however, the attack vector is network-accessible, requires no special privileges for unauthenticated exploitation, and has minimal complexity (simply injecting headers). The lack of CVSS and EPSS scores prevents quantification of exploitation probability, but the vulnerability has a clear, actionable exploit path: an attacker sends HTTP requests with spoofed IP headers to bypass rate limits on authentication endpoints. No public exploit code (POC) is referenced in the advisory, and there is no indication of active exploitation (KEV status not provided). The vulnerability is self-contained and does not enable privilege escalation, data disclosure, or RCE; it is specifically a rate-limiting bypass. Real-world impact depends heavily on the deployment architecture: if Fleet is deployed behind a trusted reverse proxy or load balancer configured to overwrite these headers (as recommended), exploitation is prevented regardless of the vulnerable code. Organizations running Fleet directly exposed to untrusted networks face the highest risk. The advisory explicitly states this 'does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own,' meaning an attacker still requires valid credentials or vulnerable endpoints (e.g., weak password policies) to realize harm. This limits the true risk to environments where brute-force attacks are feasible.

An attacker identifies that Fleet's authentication endpoint is rate-limited to, for example, 10 login attempts per IP per minute. Instead of waiting between attempts or rotating IP addresses through a botnet, the attacker simply sends 10 login attempts in rapid succession, each with a different value in the X-Forwarded-For header (e.g., 192.0.2.1, 192.0.2.2, 192.0.2.3, etc.). Fleet treats each request as coming from a different IP, so no single IP exceeds the rate limit, and the attacker's password-spraying attack proceeds unimpeded. This is especially effective against default credentials or weak passwords.