Answer in brief
CVE-2026-46356 records a Medium severity (CVSS 0.0) vulnerability in Fleet: IP spoofing allows bypassing API rate limiting. The current sources do not mark it as known exploited. The current feed maps github.com/fleetdm/fleet/v4 (go). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 0.0. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps github.com/fleetdm/fleet/v4 (go). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fleetdm/fleet/v4go | <4.80.1 | 4.80.1 |
Published upstream
May 14, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Sep 6, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Sep 6, 2026
### Summary A vulnerability in Fleet's IP extraction logic allows unauthenticated attackers to bypass API rate limiting by spoofing client IP headers. This may allow brute-force login attempts or other abuse against Fleet instances exposed to the public internet. ### Impact Fleet extracted client IP addresses from request headers (`True-Client-IP`, `X-Real-IP`, `X-Forwarded-For`) without validating that those headers originate from a trusted proxy. The extracted IP is used as the key for rate limiting and IP ban decisions. As a result, an attacker could rotate the value of these headers on each request, causing Fleet to treat each attempt as coming from a different client. This effectively bypasses per-IP rate limits on sensitive endpoints such as the login API, enabling unrestricted brute-force or credential stuffing attacks. This issue primarily affects Fleet instances that are directly exposed to the internet without a reverse proxy that overwrites forwarded-IP headers. Instances behind a properly configured proxy or WAF are less affected. ### Workarounds If an immediate upgrade is not possible, administrators should ensure Fleet is deployed behind a reverse proxy (e.g., nginx, Cloudflare, AWS ALB) that overwrites `X-Forwarded-For` with the true client IP, and apply rate limiting at the proxy or WAF layer. ### For more information If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected]) Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) ### Credits We thank @fuzzztf for responsibly reporting this issue.
Quoted source text, attributed separately from HOL analysis.