GHSA-rxhg-vcww-2mpw
LOWGHSA-rxhg-vcww-2mpw is a low-severity (CVSS 3.1) vulnerability in github.com/fleetdm/fleet/v4. O3 Security confirms whether GHSA-rxhg-vcww-2mpw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Fleet: ORDER BY column injection on activity list endpoints
Real-World Exposure
github.com/fleetdm/fleet/v4Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
An authenticated user with read access to Activity could influence the ORDER BY clause of the activity list endpoints by supplying an arbitrary sort column:
GET /api/v1/fleet/activities(ListActivities)GET /api/v1/fleet/hosts/{id}/activities(ListHostPastActivities)
This originated from the deprecated cursor-pagination helper (appendListOptionsWithCursorToSQL), which interpolated the caller-supplied order key into SQL without an allowlist. The original report's node_key extraction scenario (/api/v1/fleet/labels/{id}/hosts) was remediated separately in #44385; these two activity endpoints were the residual call sites, neither of which joins the hosts table, so node_key was never reachable through them.
Impact
Read-only. Because the order key was interpolated, an authenticated user with Activity read could sort by columns not otherwise returned in these responses. The exposure was bounded to columns on activity_past (e.g. details on /api/v1/fleet/activities, which is not in that endpoint's SELECT; host-only activities are already excluded by WHERE host_only = false). There is no privilege escalation, write access, or reachability of node_key or other host-join columns through these endpoints.
Remediation
The deprecated helper was removed from the codebase. Both endpoints now pass the caller-supplied sort column through SanitizeColumn, which strips all characters except [\w-.] and backtick-quotes each identifier segment. This closes the injection vector: separators, whitespace, parentheses, and quotes cannot survive sanitization, so an expression-based ORDER BY oracle is not constructable.
Affected versions
< fleet-v4.89.0. Fixed in fleet-v4.89.0.
Credit
Thanks to @axel-corsiez for the report.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/fleetdm/fleet/v4 | all versions | 4.89.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/fleetdm/fleet/v4. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/fleetdm/fleet/v4 to 4.89.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rxhg-vcww-2mpw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rxhg-vcww-2mpw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rxhg-vcww-2mpw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rxhg-vcww-2mpw in your dependencies?
O3 detects GHSA-rxhg-vcww-2mpw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.