A vulnerability in Fleet's labels host-listing endpoint allowed authenticated users with the lowest-privilege Observer role to extract host enrollment secrets (node_key, orbit_node_key) through a cursor-based binary search oracle. The endpoint accepted a user-supplied order_key parameter that was not validated against a column allowlist, permitting sort order to be driven by sensitive columns in a joined table.
The GET /api/v1/fleet/labels/{id}/hosts endpoint constructs its query using a deprecated helper that did not restrict which columns could appear in the ORDER BY clause. An attacker with Global Observer or Team Observer credentials could supply a sensitive column name (for example, h.node_key) as order_key and combine it with the cursor-based after parameter to binary-search the values of those columns one character at a time. The targeted values never appeared in the response body, but the presence or absence of results revealed each character.
The node_key and orbit_node_key values are the long-lived shared secrets used by osquery and Orbit agents to authenticate to the Fleet server. An attacker who extracted these keys could:
Exploitation required authenticated Observer access. Fleet deployments that restrict Observer roles to fully trusted users were at lower practical risk, but the secrets exposed are high-value and long-lived.
If an immediate upgrade is not possible, administrators should:
node_key and orbit_node_key for any host suspected of exposure by re-enrolling the affected hostsIf there are any questions or comments about this advisory:
Email Fleet at security@fleetdm.com Join #fleet in osquery Slack
Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.
{
"cwe_ids": [
"CWE-200",
"CWE-89"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T21:00:42Z",
"nvd_published_at": null,
"severity": "MODERATE"
}