ShellHub is a centralized SSH gateway. Prior to 0.24.2, 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. This vulnerability is fixed in 0.24.2.

Affected: Go: github.com/shellhub-io/shellhub

## 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…