Description

Fleet is an open-source device management platform built on osquery. In versions prior to 4.85.0, the global policy read endpoint (GET /api/latest/fleet/policies/{policy_id}) fails to verify team ownership of the requested policy, allowing an authenticated user with observer-level access on any single team to read the full details of policies belonging to any other team and bypass Fleet's team isolation model. The handler authorizes the request against an empty policy object whose TeamID is nil, which an authorization rule permits for any user holding a role on any team, and then fetches the policy by ID with no team filter and returns it without any post-fetch scope check. Because policy IDs are sequential integers, an attacker can enumerate them to read other teams' policy SQL queries, host pass and fail counts, and associated software-installer and script metadata, exposing security-monitoring strategies and compliance posture across team boundaries. This issue is fixed in version 4.85.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-26T19:16:50.480Z",
  "pubdate": "2026-08-26T19:16:50.480Z",
  "executiveSummary": "This vulnerability is an Improper Authorization flaw within the Fleet device management platform, specifically affecting the policy management module. Versions prior to 4.85.0 fail to enforce team-based access control (TBAC) constraints on the global policy read endpoint (GET /api/latest/fleet/policies/{policy_id}).\nThe vulnerability allows an authenticated user with observer-level privileges assigned to a single team to bypass logical isolation boundaries. By exploiting this authorization deficiency, an attacker can access sensitive policy configurations, security-monitoring queries, and infrastructure metadata belonging to any other team within the Fleet instance.\nThe risk is elevated due to the sequential nature of policy identifiers, which facilitates automated enumeration. Impact includes the exposure of internal compliance posture, security-monitoring strategies, and sensitive metadata associated with software installers and automation scripts. The issue is resolved in version 4.85.0 by enforcing rigorous team ownership validation during the request lifecycle.",
  "technicalDetails": "The root cause of this vulnerability lies in an inadequate authorization check within the Fleet API handler for the GET /api/latest/fleet/policies/{policy_id} endpoint. The application performs initial authorization against an empty policy object where the TeamID attribute is nil. Because the internal authorization rule interprets a nil TeamID as globally accessible to any authenticated user with team-level privileges, the request is incorrectly permitted to proceed.\nFollowing the flawed authorization check, the backend fetches the requested policy object directly by ID without applying any subsequent server-side filters based on the requester's team scope. The application fails to verify if the retrieved policy belongs to the same team(s) as the requesting user, resulting in a complete failure of the platform's multi-tenancy isolation model.\nThe exploitation flow is straightforward: 1) An attacker authenticates as a user with at least observer-level access on any team. 2) The attacker identifies the policy ID sequence, which uses incrementing integers. 3) The attacker submits authenticated GET requests to the policy endpoint for arbitrary IDs. 4) The API returns the full JSON representation of the target policy, including potentially sensitive SQL queries utilized by osquery, host-level pass/fail statistics, and metadata linked to software-installer or script resources.\nBecause there is no post-fetch scope validation, the server blindly trusts the request context, returning objects regardless of their actual owner. This allows a malicious actor to systematically crawl the platform to exfiltrate proprietary security-monitoring strategies and infrastructure details from every team partition. The vulnerability affects all versions of Fleet prior to 4.85.0, where the implementation of the policy retrieval logic lacked the necessary cross-reference checks between the requester's user object and the policy's associated TeamID field."
}