Arc has unauthenticated application log disclosure via `/api/v1/logs`GHSA-m3qr-fvp4-78xj
Fix: Basekick-Labs/arc#506GHSA-m3qr-fvp4-78xj is a security vulnerability in github.com/basekick-labs/arc. A fix is available for github.com/basekick-labs/arc — see the affected versions and patch details below.
Real-World Exposure
github.com/basekick-labs/arcReal-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
Arc exposes GET /api/v1/logs without authentication even when authentication is enabled by default. The route is registered before the global Fiber authentication middleware, and the handler returns recent buffered application logs without performing its own authorization check.
Details
Arc applies the global auth middleware after calling server.RegisterRoutes():
cmd/arc/main.go:1598-1599registers base routes viaserver.RegisterRoutes().cmd/arc/main.go:1601-1618configures and installsauth.NewMiddleware(...)later.
server.RegisterRoutes() registers GET /api/v1/logs as a base route:
internal/api/server.go:164-183registers base health, metrics, and logs routes, includings.app.Get("/api/v1/logs", s.logsHandler).
The logs handler returns buffered logs without checking authentication or authorization:
internal/api/server.go:537-567parseslimit,level, andsince_minutes, readslogger.GetBuffer().GetRecent(...), and returns JSON.internal/logger/buffer.go:9-16defines log entries returned to callers: timestamp, level, component, message, and caller.internal/logger/buffer.go:33-39creates a global log buffer holding the last 10,000 entries.internal/api/server.go:540-558permits up tolimit=1000andsince_minutes=1440in one unauthenticated request.
Authentication is enabled by default and /api/v1/logs is not listed as a public route:
internal/config/config.go:841-843defaults auth to enabled.internal/auth/middleware.go:29-41public defaults are/health,/ready,/api/v1/auth/verify, and/metricsprefix;/api/v1/logsis not public.
However, Fiber route/middleware order makes the later middleware ineffective for an earlier exact route. Local verification against Fiber v2.52.13 showed a route registered before app.Use(...) returns 200 and the later middleware is not reached. Fiber’s router walks routes in declaration order and stops after the first matching route unless the handler calls c.Next(); logsHandler does not call c.Next().
Proof of concept
Safe local reproduction only; do not scan external infrastructure.
- Start Arc with default authentication enabled.
- Request logs without an
Authorizationheader orx-api-keyheader:
curl -i 'http://127.0.0.1:8000/api/v1/logs?limit=1000&since_minutes=1440'
Expected vulnerable result:
HTTP/1.1 200 OK
Content-Type: application/json
{"timestamp":"...","count":...,"logs":[...]}
- Compare with a protected endpoint without credentials:
curl -i 'http://127.0.0.1:8000/api/v1/auth/tokens'
Expected protected result:
HTTP/1.1 401 Unauthorized
This demonstrates that default auth is active while /api/v1/logs bypasses it due to registration order.
Impact
An unauthenticated network attacker can retrieve recent application logs. Depending on deployment and log level, logs can disclose operational metadata such as component names, internal paths, database/measurement names, node identifiers, caller locations, request outcomes, and error details. This can assist further attacks and may expose sensitive data if any deployment logs secrets or user-controlled confidential data.
The audit did not confirm that the bootstrap admin token banner is captured by this endpoint; that banner is printed with fmt.Fprintf(os.Stderr, ...), while this endpoint reads the zerolog-backed application buffer.
Workarounds
Until patched, operators can restrict access to /api/v1/logs at a reverse proxy, firewall, ingress policy, or service mesh. If the endpoint is not needed, block it entirely.
Suggested fix
- Move
/api/v1/logsregistration after global auth middleware and require an authenticated administrator; or - Add explicit route-level middleware:
auth.RequireAdmin(authManager)for/api/v1/logs; and - Add a regression test that unauthenticated requests to
/api/v1/logsreturn 401/403 while/healthand/readyremain public.
References / evidence
cmd/arc/main.go:1598-1618internal/api/server.go:164-183internal/api/server.go:537-567internal/auth/middleware.go:29-41internal/config/config.go:841-843internal/logger/buffer.go:9-16internal/logger/buffer.go:33-39
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/basekick-labs/arc | all versions | 0.0.0-20260615165136-bb7d9761ad98go get github.com/basekick-labs/arc@v0.0.0-20260615165136-bb7d9761ad98 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/basekick-labs/arc, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/basekick-labs/arc to 0.0.0-20260615165136-bb7d9761ad98 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m3qr-fvp4-78xj is resolved across your whole dependency graph.
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.
Frequently Asked Questions
Is GHSA-m3qr-fvp4-78xj in your dependencies?
Find it across Go, including transitive dependencies.