Fleet’s IP extraction logic interprets the headers True‑Client‑IP, X‑Real‑IP, and X‑Forwarded‑For as trusted client addresses without verifying their origin. An unauthenticated attacker can craft requests that rotate these headers, causing Fleet to assign each request a different perceived IP. The rate‑limiting mechanism relies on the extracted IP to throttle repeated requests, so this manipulation allows an attacker to circumvent per‑IP limits on sensitive endpoints such as the login API, effectively creating an open channel for brute‑force attempts. The vulnerability does not immediately expose data or alter state; its primary consequence is facilitating credential theft or account compromise through automated attack streams.

The flaw exists in all versions of fleetdm/fleet earlier than 4.80.1. Instances exposed directly to the public internet without a trusted, reversing proxy are affected. Those configured behind a correctly set reverse proxy or Web Application Firewall that rewrites or rejects forwarded‑IP headers are less impacted.

With a CVSS score of 6.9, the security impact is moderate; the EPSS score is unavailable, but the lack of a KEV listing suggests that known exploits are not widespread in the wild. The vulnerability is exploitable over the public network when an instance is exposed without additional filtering or a reverse proxy. An attacker only needs to send crafted HTTP requests with rotating IP headers, a technique that is straightforward to automate. The consequence is potentially unlimited credential‑guessing or credential‑stuffing on sensitive Fleet endpoints. Given these conditions, admins should address this issue promptly, especially for publicly exposed deployments.