Question 1

How do I fix CVE-2026-78667 and CVE-2026-97031 in ShellHub Go images and failing Trivy scans?

Accepted Answer

Upgrade every Go build to Go 1.26.9, which includes fixes for both vulnerabilities. Update the `go` directive in all `go.mod` files to `go 1.26.9`, change Go builder images to `FROM golang:1.26.9-alpine3.24`, and set the agent Dockerfile argument to `ARG GOLANG_VERSION=1.26.9`. Apply the same change in the cloud repository and ensure CI uses `go-version-file` so jobs compile with the updated toolchain. Rebuild the server, gateway, openapi, agent, and test images, plus native agent binaries. Verify the fix with the existing `trivy-image` scans and `govulncheck`; CVE-2026-78667 and CVE-2026-97031 should no longer be reported.

Question 2

How do I fix "additional privileges requested: pass --allow=network.host" when running ./bin/docker-compose build?

Accepted Answer

Remove `network: host` from the dev image build configurations and stop passing module-proxy build args through Compose.

1. In `docker-compose.dev.yml` and `docker-compose.agent.yml`, remove the build-level `network: host` line for `server`, `ui`, `openapi`, and `agent`.
2. Remove the `GOPROXY=${SHELLHUB_GOPROXY:-}` and `NPM_CONFIG_REGISTRY=${SHELLHUB_NPM_REGISTRY:-}` build args.
3. Remove the corresponding `ARG GOPROXY`, `ARG NPM_CONFIG_REGISTRY`, and related `ENV` lines from the server, agent, gateway, openapi, and UI Dockerfiles.
4. Remove or leave unset `SHELLHUB_GOPROXY` and `SHELLHUB_NPM_REGISTRY` in `.env`.
5. Rebuild with the default network:

```bash
./bin/docker-compose build server
```

Go then uses `proxy.golang.org` and npm uses its default registry, so BuildKit no longer requires the `network.host` entitlement. If you need a proxy, set `GOPROXY` or `NPM_CONFIG_REGISTRY` in the container's runtime environment instead of injecting it as a build arg.

Question 3

How to fix "cannot use count (variable of type int64) as int value" after upgrading uptrace/bun to v1.3.0?

Accepted Answer

Upgrade both Bun modules to v1.3.0 and convert types at the PostgreSQL store boundary:

```sh
go get github.com/uptrace/bun@v1.3.0
go get github.com/uptrace/bun/dialect/pgdialect@v1.3.0
go mod tidy
```

In Bun v1.3.0, `Count` and `ScanAndCount` return `int64`, while `Limit` and `Offset` accept `int64`. Convert their values when adapting to an existing `int` store interface:

```go
count, err := query.Count(ctx)
if err != nil {
    return 0, err
}
return int(count), nil
```

For pagination:

```go
query = query.
    Limit(int64(pageSize)).
    Offset(int64((page - 1) * pageSize))
```

Apply the same `int64`-to-`int` conversion to values returned by `ScanAndCount`. Keeping the store interface, mocks, and callers on `int` limits the change to the Bun integration layer. Verify with the PostgreSQL store integration tests and enterprise build that compiles ShellHub against the cloud module.

Question 4

How to fix ShellHub agent stuck retrying '/api/devices/auth' with 'namespace not found' error?

Accepted Answer

The agent holds a tenant ID that does not resolve to any existing namespace, so the server returns 404 and the agent retries forever by design (a namespace 'may not exist yet'). Fix it: 1) Check agent logs with `docker logs ` for `failed to authenticate device ... namespace not found` — after PR #7077 this is logged at warn level every 10 attempts, including the tenant value and its origin. 2) Verify the tenant ID is the exact UUID of an existing namespace (a common cause is a typo such as `O` instead of `0` in a `TENANT_ID=` install). 3) If the tenant came from a previous pairing, delete the persisted `.tenant` file next to the agent's private key and re-enroll — the agent silently adopts this file when `SHELLHUB_TENANT_ID` is unset. 4) If set via environment, correct `SHELLHUB_TENANT_ID` and restart the container. 5) Upgrade to a release containing PR #7077 and #7661: the agent rejects non-UUID tenants immediately, and `install.sh` now exits non-zero and reports the real enrollment outcome instead of printing success for a doomed enrollment. Note: a syntactically valid UUID for a deleted/nonexistent namespace still retries indefinitely; only the log and installer now make it visible.

Question 5

How do I fix a ShellHub device showing online after it has disconnected because a queued heartbeat arrives late?

Accepted Answer

Upgrade the ShellHub server to a release containing the fix for issue #7401 (`fix(server): stop a late heartbeat from bringing a device back online`).

The race occurs because:
1. A keep-alive is queued when the tunnel registers or a pong is received.
2. The heartbeater flushes queued heartbeats every 2 seconds.
3. If the tunnel closes first, `OfflineDevice` sets `disconnected_at`.
4. The stale heartbeat is then written and unconditionally sets `disconnected_at = NULL`, making the device appear online until `last_seen` becomes older than the online threshold.

If maintaining a custom build, make two changes:

1. Keep the latest heartbeat timestamp per device in the batch instead of using one timestamp for the whole batch.
2. Clear `disconnected_at` only when the heartbeat is newer than the disconnect:

```sql
UPDATE devices
SET
  last_seen = $2,
  disconnected_at = CASE
    WHEN disconnected_at > $2 THEN disconnected_at
    ELSE NULL
  END
WHERE uid = $1;
```

A heartbeat older than `disconnected_at` therefore leaves the device offline. A real reconnect still works because authentication or the new tunnel sends a heartbeat after the disconnect time. Verify by stopping an agent immediately after it connects and confirming it does not briefly return online after the 2-second heartbeat flush window.

shellhub

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects