CVE-2026-103265 in Fleet
Summary
by MITRE • 10/01/2026
Fleet versions before 4.89.0 fail to properly filter MDM command results by team authorization in the commands/results endpoint. Team-scoped users can read MDM command results for hosts on other teams when a shared command UUID targets hosts across multiple teams, exposing host UUIDs, command payloads, and device responses.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in Fleet versions prior to 4.89.0 represents a critical failure in access control mechanisms within the Mobile Device Management (MDM) subsystem. Specifically, the flaw resides in the commands/results endpoint, which is responsible for retrieving the outcomes of MDM operations executed on managed devices. In environments where multiple teams operate under distinct security policies and data isolation requirements, this endpoint failed to enforce strict team-scoped authorization checks when processing requests associated with shared command Universally Unique Identifiers (UUIDs). This architectural oversight allows users who are scoped to a specific team to bypass intended boundaries and access sensitive operational data belonging to other teams.
The technical root cause of this issue stems from the logic used to filter results based on user permissions. When an MDM command is initiated with a shared UUID that targets hosts distributed across multiple organizational teams, the system incorrectly associates all resulting data with any valid request for that specific command ID. Consequently, instead of filtering the response payload to include only devices and outcomes relevant to the requesting user's team, the endpoint returns comprehensive details including host UUIDs, original command payloads, and device-specific responses from all targeted hosts regardless of their team affiliation. This behavior violates the principle of least privilege by granting read access to data that should remain strictly isolated within its respective organizational unit.
The operational impact of this vulnerability is significant for organizations relying on Fleet for centralized device management across diverse departments or subsidiaries. The exposure includes host UUIDs, which can be used to fingerprint and track specific devices in threat intelligence databases or targeted attacks. Furthermore, the leakage of command payloads reveals internal administrative procedures, software deployment strategies, and configuration details that could aid an attacker in crafting more effective exploits against those systems. Device responses may contain sensitive operational data, system configurations, or diagnostic information that compromises the integrity and confidentiality of the managed fleet. For regulated industries adhering to standards such as GDPR, HIPAA, or PCI-DSS, this unauthorized disclosure constitutes a serious compliance violation due to the potential exposure of personally identifiable information or protected health information embedded within device telemetry.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if shared identifiers are treated as implicit trust boundaries without proper validation. In terms of the MITRE ATT&CK framework, this behavior facilitates Initial Access or Discovery phases by allowing adversaries to gather intelligence about the network topology and administrative workflows through lateral movement within the management console itself. The ability to read cross-team data effectively breaks down logical segmentation strategies employed in multi-tenant or departmentalized IT environments.
To mitigate this risk, organizations running Fleet versions earlier than 4.89.0 must upgrade immediately to version 4.89.0 or later where these access control checks have been corrected. Until the upgrade is performed, administrators should audit logs for unusual queries against the commands/results endpoint and restrict network-level access to the Fleet server if possible. It is also advisable to rotate any credentials associated with shared command UUIDs that were used during the period of vulnerability exposure to ensure no lingering unauthorized sessions retain elevated privileges. Regular review of team-scoped user permissions and enforcement of strict data isolation policies in MDM configurations are recommended best practices to prevent similar access control failures in future deployments.