| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/fleetdm/fleet | ≥ 4.75.0, < 4.75.2≥ 4.76.0, < 4.76.2≥ 4.77.0, < 4.77.1≥ 4.78.0, < 4.78.3 | 4.75.24.76.24.77.14.78.3 |
| github.com/fleetdm/fleet/v4 | ≥ 4.75.0, < 4.75.2≥ 4.76.0, < 4.76.2≥ 4.77.0, < 4.77.1≥ 4.78.0, < 4.78.3< 4.78.3-0.20260112221730-5c030e32a3a9 | 4.75.24.76.24.77.14.78.34.78.3-0.20260112221730-5c030e32a3a9 |
| fleet | = 4.77.0≥ 4.75.0, < 4.75.2≥ 4.76.0, < 4.76.2≥ 4.78.0, < 4.78.3< 4.53.3 | 4.75.24.76.24.78.34.53.3 |
A broken access control issue in Fleet allowed authenticated users to access debug and profiling endpoints regardless of role. As a result, low-privilege users could view internal server diagnostics and trigger resource-intensive profiling operations.
Fleet’s debug/pprof endpoints are accessible to any authenticated user regardless of role, including the lowest-privilege “Observer” role. This allows low-privilege users to access sensitive server internals, including runtime profiling data and in-memory application state, and to trigger CPU-intensive profiling operations that could lead to denial of service.
If an immediate upgrade is not possible, users should put the debug/pprof endpoints behind an IP allowlist.
If you have any questions or comments about this advisory:
Email us at [email protected] Join #fleet in osquery Slack
We thank @secfox-ai for responsibly reporting this issue.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free