GHSA-RXHG-VCWW-2MPW: SQL Injection via ORDER BY Column Injection in Fleet Activity List Endpoints

The Fleet Device Management platform exposes endpoints for querying global and host-specific activities. These feeds assist administrators in auditing system events and monitoring state changes across enrolled devices. The endpoints are exposed to authenticated users via the HTTP endpoints /api/v1/fleet/activities and /api/v1/fleet/hosts/{id}/activities.

A weakness in the sorting logic allows users to pass unvalidated column names to the query-sorting component. The underlying application database layer constructs dynamic queries incorporating the client-supplied sorting parameters. Because structural query components like column names cannot be bound via parameterized placeholders, the application was susceptible to sorting parameter manipulation.

An attacker with an authenticated session can exploit this behavior to reference database columns containing confidential details. This leads to unauthorized data access and information disclosure by bypassing standard data access controls.

The vulnerability stems from the use of unsafe dynamic SQL generation in the ListActivities and ListHostPastActivities database abstraction layer methods. Standard SQL parameters utilize placeholders to isolate values from the execution logic. However, structural query modifiers such as ORDER BY identifiers and direction directives do not accept parameter placeholders in MySQL.

To bridge this gap, Fleet utilized a helper function named platform_mysql.AppendListOptionsWithParams to build the query. This helper attempted to sanitize inputs by wrapping identifier strings with backticks to avoid immediate syntax anomalies. The logic lacked a validation mechanism to cross-reference input fields against a list of authorized database columns.

Consequently, any arbitrary column name or SQL function supplied to the order_key parameter was integrated directly into the ORDER BY clause. This permitted the construction of an inference oracle where boolean-based assertions alter the sequence of returned rows. Attackers leverage the variations in result sorting to deduce confidential database contents piece by piece.

The vulnerability was resolved in Pull Request #49624 by transitioning to an allowlist-based query builder. Developers introduced static validation maps (OrderKeyAllowlist) to explicitly limit the columns permitted in ORDER BY clauses.

// server/activity/internal/mysql/activity.go
 
var listActivitiesOrderKeys = platform_mysql.OrderKeyAllowlist{
  "id":              "a.id",
  "created_at":      "a.created_at",
  "user_id":         "a.user_id",
  "user_name":       "a.user_name",
  "name":            "a.user_name",
  "user_email":      "a.user_email",
  "activity_type":   "a.activity_type",
  "streamed":        "a.streamed",
  "fleet_initiated": "a.fleet_initiated",
}

The fix maps user-supplied keys directly to qualified column names, explicitly leaving out sensitive columns like details or host_only. The implementation substituted AppendListOptionsWithParams with a secure variant AppendListOptionsWithParamsSecure that enforces validation.

// Pre-patch call
// activitiesQ, args = platform_mysql.AppendListOptionsWithParams(activitiesQ, args, &opt)
 
// Post-patch call
activitiesQ, args, err := platform_mysql.AppendListOptionsWithParamsSecure(activitiesQ, args, &opt, listActivitiesOrderKeys)
if err != nil {
  return nil, nil, ctxerr.Wrap(ctx, err, "append list options")
}

This pattern guarantees that any unauthorized key triggers an immediate InvalidOrderKeyError. The API handler catches this exception and replies with an HTTP 422 Unprocessable Entity response, terminating execution before sending the query to the MySQL database engine.

Exploitation requires an active user session authorized to request the activities feed. The attacker targets either the global activity feed or a host-specific activities resource. The objective is to utilize the sorting output to infer values stored in columns containing credential configurations or secret parameters.

To construct the attack, the attacker crafts an HTTP request incorporating a conditional expression within the order_key parameter. This conditional expression tests a specific assertion against a target data field:

GET /api/v1/fleet/activities?order_key=(CASE+WHEN+(SELECT+SUBSTRING(details,1,1)+FROM+activities+WHERE+id=1)='a'+THEN+id+ELSE+created_at+END)&order_direction=asc HTTP/1.1
Host: target-fleet-server.com
Authorization: Bearer <token>

When the condition evaluates to true, the database orders results based on the id column. When false, ordering defaults to the created_at timestamp. By observing the structured arrangement of the array items in the response, the attacker verifies the validity of the hypothesized character. Repeating this mechanism across offset values allows the retrieval of entire strings from unprojected database cells.

The diagram below outlines the execution flow of an incoming malicious request, illustrating how the lack of validation allowed SQL injection and how the mitigation blocks unauthorized parameters before database execution.

With the patched version, the flow changes to discard invalid fields early in the processing loop:

The primary consequence of this flaw is the unauthorized extraction of database attributes. Because activities include a generic details field, they often store sensitive structural configurations, environmental variables, or internal session details. Compromising these attributes lowers the barrier for horizontal privilege escalation within the platform.

The attack vector is restricted to authenticated sessions, meaning threat actors must already have legitimate credentials or a hijacked token. This constraint reduces the immediate risk profile of the flaw compared to unauthenticated remote code execution. However, inside threats or compromised regular accounts can leverage this vulnerability to gain high-level privileges.

No public proof-of-concept exploits exist, and there are no signs of exploitation in the wild. The vulnerability does not allow modification of database contents or arbitrary command execution on the host OS.