Description

Fleet before 4.89.0 contains an SQL injection vulnerability in the activity list endpoints (GET /api/v1/fleet/activities and GET /api/v1/fleet/hosts/{id}/activities). The deprecated cursor-pagination helper appendListOptionsWithCursorToSQL interpolated the caller-supplied sort/order key into the SQL ORDER BY clause without an allowlist, so an authenticated user with read access to Activity could order results by arbitrary columns. The impact is read-only and bounded to columns on the activity_past table that are not otherwise returned in these responses (e.g. details), allowing their values to be inferred through the resulting sort order; there is no write access, privilege escalation, or reachability of node_key or other host-join columns through these endpoints. Fixed in 4.89.0, which removes the deprecated helper and passes the sort column through SanitizeColumn.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-09-27T18:16:31.037Z",
  "pubdate": "2026-09-27T18:16:31.037Z",
  "executiveSummary": "Fleet versions prior to 4.89.0 contain an SQL injection vulnerability within specific activity list API endpoints.\nThe vulnerability originates from the improper handling of user-supplied sorting parameters within a deprecated cursor-pagination helper, leading to unauthorized data inference.\nSuccessful exploitation allows an authenticated attacker with read access to the Activity resource to manipulate ORDER BY clauses.\nThis enables the attacker to infer sensitive information from the activity_past database table that is not typically exposed in the API response, such as content within the 'details' column.\nThe scope of the impact is strictly read-only; the vulnerability does not grant write access, privilege escalation, or access to sensitive host-join columns or authentication keys.\nMitigation requires upgrading to version 4.89.0, which enforces strict input sanitization via SanitizeColumn.",
  "technicalDetails": "The vulnerability resides in the cursor-pagination helper function appendListOptionsWithCursorToSQL, which was responsible for dynamically constructing SQL queries based on client-provided parameters.\nThe root cause is the lack of an allowlist for the 'sort' and 'order' keys, which were directly interpolated into the SQL ORDER BY clause. This failure to sanitize or validate the input allows an attacker to inject arbitrary column identifiers into the database query.\nThe affected endpoints are GET /api/v1/fleet/activities and GET /api/v1/fleet/hosts/{id}/activities. By crafting requests containing malicious sort keys, an attacker can influence the ordering of the activity feed.\nExploitation involves a blind-inference technique. Because the API returns results sorted by an attacker-specified column, an attacker can submit a sort parameter targeting sensitive columns within the activity_past table. By observing changes in the order of the returned activity list, the attacker can effectively 'sort' hidden information and deduce the contents of the details column through iterative queries.\nAuthentication is required to trigger this vulnerability, as the attacker must possess valid read access to the Activity resource within the Fleet application. However, once authenticated, no special privileges are necessary to manipulate the sorting parameters.\nThe attack flow follows these steps: 1) The attacker identifies the target API endpoints. 2) The attacker sends a GET request with a 'order_key' parameter set to a sensitive, non-public column name on the activity_past table. 3) The backend server uses the vulnerable appendListOptionsWithCursorToSQL function to process the parameter, resulting in an unsanitized ORDER BY clause being executed against the database. 4) The database returns the activities sorted by the sensitive field. 5) The attacker analyzes the order of the results to infer the values held within the specified sensitive column. 6) The process is repeated until the desired data has been extracted.\nFleet version 4.89.0 remediates this issue by completely removing the deprecated appendListOptionsWithCursorToSQL helper and replacing it with a secure implementation that utilizes the SanitizeColumn function, ensuring that only expected and safe column identifiers are permitted in the SQL query construction."
}