| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| github.com/fleetdm/fleet/v4 | < 4.84.2 | 4.84.2 |
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 [email protected] Join #fleet in osquery Slack
Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン