CVE-2026-46370 in Fleet
Summary
by MITRE • 08/26/2026
Fleet is an open-source device management platform built on osquery. In versions up to and including 4.84.1, the labels host-listing endpoint (GET /api/v1/fleet/labels/{id}/hosts) allowed an authenticated user with the lowest-privilege Observer role to extract host enrollment secrets through a sort-order oracle. The endpoint accepted a user-supplied order_key parameter that was not validated against a column allowlist, so an attacker with Global or Team Observer access could set the sort column to a sensitive field such as h.node_key and combine it with the cursor-based after parameter to binary-search the value one character at a time; the targeted value never appeared in the response, but the presence or absence of results revealed each character. Because node_key and orbit_node_key are the long-lived shared secrets that osquery and Orbit agents use to authenticate to the Fleet server, an attacker who reconstructed them could impersonate enrolled hosts, submit fabricated query results and inventory, retrieve pending scripts and MDM commands, and poison compliance and policy results across the deployment. This issue is fixed in version 4.84.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified as CVE-2023-6195 represents a critical information disclosure flaw within Fleet, an open-source device management platform built on osquery. In versions up to and including 4.84.1, the API endpoint responsible for listing hosts associated with specific labels, specifically GET /api/v1/fleet/labels/{id}/hosts, contained a logic error that allowed authenticated users with even the lowest-privilege Observer role to extract sensitive host enrollment secrets. The core technical flaw lies in the handling of the order_key parameter, which determines the sorting column for the returned results. This parameter was not validated against a strict allowlist of permissible database columns, thereby permitting an attacker to specify arbitrary fields from the underlying database schema as sort keys.
By exploiting this lack of input validation, an adversary could set the sort column to sensitive internal fields such as h.node_key or orbit_node_key. These fields contain long-lived shared secrets that osquery and Orbit agents use to authenticate with the Fleet server. The exploitation technique employed a time-based or count-based oracle attack combined with cursor-based pagination. Specifically, the attacker utilized the after parameter for pagination in conjunction with the custom sort order to perform a binary search on the secret value character by character. Although the actual value of the node key was never directly returned in the API response, the presence or absence of results at specific sorting positions revealed each subsequent character of the secret through side-channel information leakage.
This vulnerability is classified under CWE-209 as an Information Exposure Through an Error Message and aligns with ATT&CK technique T1530, Data from Cloud Storage Object, due to the exfiltration of sensitive configuration data via API endpoints. The operational impact of this flaw is severe because node_key and orbit_node_key serve as the primary authentication mechanism for agents connecting to the Fleet server. Once an attacker reconstructs these secrets through the described binary search method, they gain the ability to impersonate enrolled hosts within the network infrastructure. This unauthorized access allows the adversary to submit fabricated query results and inventory data, effectively polluting the integrity of system monitoring and asset management processes.
Furthermore, possession of these enrollment secrets enables a malicious actor to retrieve pending scripts and Mobile Device Management commands intended for legitimate devices. By injecting false compliance reports or policy violations, an attacker can poison the organization's security posture assessments, potentially triggering automated remediation actions against healthy systems while masking their own activities. This capability undermines trust in the entire device management ecosystem, as administrators can no longer rely on the authenticity of data reported by agents. The vulnerability was addressed and fixed in version 4.84.2 of Fleet, which implements proper input validation for sort parameters to prevent arbitrary column selection. Organizations running affected versions should immediately upgrade to the patched release and rotate all host enrollment secrets to invalidate any potentially compromised keys obtained prior to the fix.