### Summary 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. ### Impact 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: - Impersonate enrolled hosts to Fleet's osquery and Orbit endpoints - Submit fabricated query results and host inventory data - Retrieve pending scripts and MDM commands queued for the host - Poison compliance and policy results across the Fleet deployment 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. ### Patches - v4.85.0 ### Workarounds If an immediate upgrade is not possible, administrators should: - Restrict the Observer role to fully trusted users until the patch is applied - Rotate `node_key` and `orbit_node_key` for any host suspected of exposure by re-enrolling the affected hosts ### For more information If there are any questions or comments about this advisory: Email Fleet at [[email protected]](mailto:[email protected]) Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) ### Credits Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.
### Summary 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. ### Impact 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: - Impersonate enrolled hosts to Fleet's osquery and Orbit endpoints - Submit fabricated query results and host inventory data - Retrieve pending scripts and MDM commands queued for the host - Poison compliance and policy results across the Fleet deployment 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. ### Patches - v4.85.0 ### Workarounds If an immediate upgrade is not possible, administrators should: - Restrict the Observer role to fully trusted users until the patch is applied - Rotate `node_key` and `orbit_node_key` for any host suspected of exposure by re-enrolling the affected hosts ### For more information If there are any questions or comments about this advisory: Email Fleet at [[email protected]](mailto:[email protected]) Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) ### Credits Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.
Update github.com/fleetdm/fleet/v4 to 4.84.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFleet has observer-level enrollment secret extraction via ORDER BY oracle on labels host-listing endpoint affects github.com/fleetdm/fleet/v4 (go). Severity is medium. ### Summary 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. ### Impact 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: - Impersonate enrolled hosts to Fleet's osquery and Orbit endpoints - Submit fabricated query results and host inventory data - Retrieve pending scripts and MDM commands queued for the host - Poison compliance and policy results across the Fleet deployment 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. ### Patches - v4.85.0 ### Workarounds If an immediate upgrade is not possible, administrators should: - Restrict the Observer role to fully trusted users until the patch is applied - Rotate `node_key` and `orbit_node_key` for any host suspected of exposure by re-enrolling the affected hosts ### For more information If there are any questions or comments about this advisory: Email Fleet at [[email protected]](mailto:[email protected]) Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) ### Credits Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fleetdm/fleet/v4go | <=4.84.1 | 4.84.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/fleetdm/fleet/v4 to 4.84.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFleet has observer-level enrollment secret extraction via ORDER BY oracle on labels host-listing endpoint affects github.com/fleetdm/fleet/v4 (go). Severity is medium. ### Summary 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. ### Impact 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: - Impersonate enrolled hosts to Fleet's osquery and Orbit endpoints - Submit fabricated query results and host inventory data - Retrieve pending scripts and MDM commands queued for the host - Poison compliance and policy results across the Fleet deployment 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. ### Patches - v4.85.0 ### Workarounds If an immediate upgrade is not possible, administrators should: - Restrict the Observer role to fully trusted users until the patch is applied - Rotate `node_key` and `orbit_node_key` for any host suspected of exposure by re-enrolling the affected hosts ### For more information If there are any questions or comments about this advisory: Email Fleet at [[email protected]](mailto:[email protected]) Join #fleet in [osquery Slack](https://join.slack.com/t/osquery/shared_invite/zt-h29zm0gk-s2DBtGUTW4CFel0f0IjTEw) ### Credits Fleet thanks the Security Team at Palantir Technologies for responsibly reporting this issue.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fleetdm/fleet/v4go | <=4.84.1 | 4.84.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard