Fleet CVE-2026-46356

The vulnerability requires Fleet to be directly exposed to the internet or to a network where the attacker can inject or control HTTP request headers. Specifically, the instance must not be behind a reverse proxy that overwrites the X-Forwarded-For, True-Client-IP, and X-Real-IP headers with the real connecting client IP. Organizations using a properly configured reverse proxy, WAF, or load balancer (nginx, Cloudflare, AWS ALB, etc.) that validates and rewrites these headers before forwarding requests to Fleet are not vulnerable. Additionally, the attacker must be able to send HTTP requests to a rate-limited endpoint (such as the login API) on the Fleet instance. The vulnerability affects unauthenticated attackers and requires no special Fleet configuration or non-default settings to trigger; it is a default behavior flaw in how IP extraction is performed.

Without a provided CVSS vector, risk assessment relies on attack surface and exploit prerequisites. The vulnerability carries real operational risk because unauthenticated remote attackers on the internet can exploit it against internet-facing Fleet instances, and the attack complexity is trivial (rotating header values in HTTP requests requires no special privilege or user interaction). No CVSS score was provided in the input data, and no EPSS score is available. CISA KEV status is not indicated, though the advisory is from the vendor's official GitHub security channel, indicating responsible disclosure. The attack chain is straightforward: header spoofing is not blocked by network-level defenses and does not require authentication or special configuration of Fleet itself-the vulnerability exists in default deployments. However, the real-world blast radius is limited to instances deployed directly to the internet without an intervening reverse proxy; organizations using proper infrastructure patterns (proxy, WAF, or ALB) with header rewriting are protected. The lack of a CVSS score in the input suggests this vulnerability may not yet be in the NVD; availability of exploit code is not confirmed, though the technique (header rotation) is trivial to implement.

An attacker makes repeated login attempts against an internet-exposed Fleet instance, rotating the X-Forwarded-For header value on each request (e.g., 192.168.1.1, 192.168.1.2, 192.168.1.3, etc.). Fleet treats each request as coming from a different client IP and does not trigger per-IP rate limits or temporary IP bans, allowing credential stuffing or brute-force attacks to proceed unthrottled. If the attacker obtains valid credentials or guesses a weak password, they gain administrative access to the Fleet management interface.