GHSA-m3qr-fvp4-78xj: Authentication Bypass and Log Disclosure in Basekick Labs Arc

Arc (github.com/basekick-labs/arc) is an open-source, SQL-native time-series database written in Go and developed by Basekick Labs. It exposes an HTTP API built on top of the Go Fiber web framework (github.com/gofiber/fiber/v2, version v2.52.13) to manage database operations, cluster telemetry, metrics collection, and administrative tasks. By default, Arc enables token-based authentication (internal/config/config.go:841-843) to restrict administrative and data-plane endpoints to authorized clients.

In versions prior to v26.06.2, Arc contains an authentication bypass and sensitive information disclosure vulnerability tracked as GHSA-m3qr-fvp4-78xj. The flaw is classified under CWE-306 (Missing Authentication for Critical Function) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). Specifically, the GET /api/v1/logs endpoint—which exposes an in-memory ring buffer of operational database logs—can be accessed by any unauthenticated client with network access to the Arc HTTP listener.

This exposure occurs despite authentication being enabled in the server configuration and despite /api/v1/logs being omitted from the explicit public route allowlists (middlewareConfig.PublicRoutes and middlewareConfig.PublicPrefixes). The vulnerability stems from how the Go Fiber routing engine dispatches incoming HTTP requests relative to the order in which route handlers and global middleware are registered during server startup.

An unauthenticated remote attacker who queries GET /api/v1/logs receives structured JSON responses containing recent application logs. These records include timestamps, severity levels, internal subsystem identifiers, Go source file paths and line numbers, error messages, and network peer metadata. The vulnerability was reported by @sondt99 and remediated by Ignacio Van Droogenbroeck (@xe-nvdk) in pull request #506 via commit bb7d9761ad9801e93837762ff7d37460f1df19dd.

The root cause of GHSA-m3qr-fvp4-78xj is an architectural route-ordering flaw in the initialization sequence between cmd/arc/main.go and internal/api/server.go. Arc relies on Go Fiber (github.com/gofiber/fiber/v2), which is built on top of valyala/fasthttp. In Fiber, the routing engine maintains an ordered stack of handlers and processes incoming HTTP requests strictly in the order in which routes and middleware were declared on the application instance.

When an HTTP request arrives at a Fiber server, the router iterates through its registered stack entries matching the request method and path. If a specific route handler is registered via app.Get(...) before a global middleware is mounted via app.Use(...), Fiber matches and executes the specific route handler first. Unless that route handler explicitly invokes c.Next(), Fiber marks the request context as complete as soon as the handler writes a response and returns nil, terminating traversal before execution ever reaches downstream app.Use(...) middleware.

Prior to commit bb7d9761ad9801e93837762ff7d37460f1df19dd, the base route registration in internal/api/server.go grouped /api/v1/logs alongside unauthenticated health and metrics endpoints inside RegisterRoutes(). In cmd/arc/main.go, the application invoked server.RegisterRoutes() before checking config.Auth.Enabled and attaching auth.NewMiddleware(middlewareConfig).

// Vulnerable initialization sequence in internal/api/server.go (lines 164-183)
func (s *Server) RegisterRoutes() {
    s.app.Get("/health", s.healthHandler)
    s.app.Get("/ready", s.readyHandler)
    s.app.Get("/metrics", s.metricsHandler)
    s.app.Get("/api/v1/metrics", s.metricsJSONHandler)
    s.app.Get("/api/v1/metrics/endpoints", s.endpointMetricsHandler)
    s.app.Get("/api/v1/metrics/timeseries/:type", s.timeseriesMetricsHandler)
 
    // VULNERABLE: Registered before global auth middleware is mounted in main.go.
    // Because logsHandler returns without calling c.Next(), auth middleware is bypassed.
    s.app.Get("/api/v1/logs", s.logsHandler)
}

The patch in commit bb7d9761ad9801e93837762ff7d37460f1df19dd resolves this by removing /api/v1/logs from RegisterRoutes() and creating a dedicated method, RegisterLogsRoute(authManager *auth.AuthManager). In addition to changing the registration sequence, the patch applies an explicit route-level administrative guard (withAdminAuth(authManager)) to ensure only administrative tokens—not standard read or write tokens—can access the logs endpoint when authentication is active.

diff --git a/internal/api/server.go b/internal/api/server.go
index 08079e18..cd33caa1 100644
--- a/internal/api/server.go
+++ b/internal/api/server.go
@@ -179,13 +180,27 @@ func (s *Server) RegisterRoutes() {
 	s.app.Get("/api/v1/metrics/endpoints", s.endpointMetricsHandler)
 	s.app.Get("/api/v1/metrics/timeseries/:type", s.timeseriesMetricsHandler)
 
-	// Application logs endpoint
-	s.app.Get("/api/v1/logs", s.logsHandler)
+	// NOTE: /api/v1/logs is intentionally NOT registered here. It exposes
+	// buffered application logs and must be admin-authenticated. Registering
+	// it among these public base routes (before the global auth middleware is
+	// installed) left it reachable unauthenticated, because Fiber matches
+	// routes in registration order and returns before reaching a later
+	// app.Use middleware (GHSA-m3qr-fvp4-78xj). It is now registered via
+	// RegisterLogsRoute() AFTER the auth middleware, from cmd/arc/main.go.
 
 	// API v1 routes will be added here
 	// MessagePack endpoint will be registered separately
 }
 
+// RegisterLogsRoute registers the admin-authenticated application logs
+// endpoint. It must be called AFTER the global auth middleware is installed so
+// the route sits later in the Fiber stack than the middleware. withAdminAuth
+// returns the admin guard when authManager is non-nil, or a passthrough when it
+// is nil (authentication disabled), preserving no-auth deployment behaviour.
+func (s *Server) RegisterLogsRoute(authManager *auth.AuthManager) {
+	s.app.Get("/api/v1/logs", withAdminAuth(authManager), s.logsHandler)
+}

In cmd/arc/main.go, server.RegisterLogsRoute(authManager) is now called strictly after server.GetApp().Use(auth.NewMiddleware(middlewareConfig)). If authentication is disabled in configuration (else branch), server.RegisterLogsRoute(nil) is called, where withAdminAuth(nil) acts as a passthrough handler to preserve functionality for unauthenticated local deployments.

diff --git a/cmd/arc/main.go b/cmd/arc/main.go
index 07cf3486..fd4f1ba9 100644
--- a/cmd/arc/main.go
+++ b/cmd/arc/main.go
@@ -1625,8 +1625,26 @@ func main() {
+		middlewareConfig.PublicPrefixes = append(middlewareConfig.PublicPrefixes, "/api/v1/metrics")
 		server.GetApp().Use(auth.NewMiddleware(middlewareConfig))
 
+		// Register the admin-authenticated logs route AFTER the auth
+		// middleware so it sits later in the Fiber stack and is actually
+		// gated (GHSA-m3qr-fvp4-78xj).
+		server.RegisterLogsRoute(authManager)
...
@@ -1797,6 +1815,12 @@ func main() {
+	} else {
+		// Authentication disabled: register the logs route unguarded so the
+		// endpoint still works for no-auth deployments.
+		server.RegisterLogsRoute(nil)
 	}

> [!NOTE] > Fix Completeness Assessment: During patch development, the maintainers also audited the remaining routes in RegisterRoutes(). They determined that /api/v1/metrics and its sub-paths were previously accessible without authentication only as a side effect of being registered before the middleware. To formalize this behavior and prevent accidental security regressions if route ordering changes in the future, /api/v1/metrics was explicitly added to middlewareConfig.PublicPrefixes, and automated unit tests were introduced in internal/api/logs_auth_test.go to verify 401 Unauthorized (unauthenticated) and 403 Forbidden (non-admin token) responses on /api/v1/logs. The fix is complete and enforces defense-in-depth via both global middleware ordering and route-specific withAdminAuth enforcement.

Exploiting GHSA-m3qr-fvp4-78xj requires no authentication credentials, session tokens, or special client tooling. The only prerequisite is network connectivity to the Arc HTTP API port (8000 by default). An attacker sends a standard HTTP GET request to /api/v1/logs.

The logsHandler function (internal/api/server.go:537-567) accepts optional query parameters that allow the caller to control the volume and time window of retrieved records from the in-memory ring buffer (internal/logger/buffer.go). While the ring buffer stores up to 10,000 entries in memory, the HTTP handler allows callers to specify limit (up to 1000 entries per request) and since_minutes (up to 1440 minutes, representing 24 hours of history).

# Unauthenticated request retrieving up to 100 log entries from the past 60 minutes
curl -i 'http://127.0.0.1:8000/api/v1/logs?limit=100&since_minutes=60'

On a vulnerable Arc instance (versions < v26.06.2) with authentication enabled, the server bypasses token verification and responds with HTTP/1.1 200 OK and a JSON payload containing the buffered log entries:

HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "timestamp": "2026-06-15T10:00:00Z",
  "count": 100,
  "logs": [
    {
      "timestamp": "2026-06-15T09:59:01Z",
      "level": "info",
      "component": "server",
      "caller": "api/server.go:120",
      "message": "listening on 0.0.0.0:8000"
    }
  ]
}

By contrast, querying any endpoint registered after the global authentication middleware on the same server—such as /api/v1/auth/tokens—triggers the authentication middleware and returns an HTTP 401 Unauthorized response ({"error": "missing or invalid authorization token"}). On patched instances (>= v26.06.2), unauthenticated requests to /api/v1/logs similarly fail with 401 Unauthorized, and authenticated requests bearing non-admin tokens fail with 403 Forbidden.

The security impact of GHSA-m3qr-fvp4-78xj is limited to unauthorized confidentiality exposure (C:L), with no direct impact on system integrity (I:N) or availability (A:N). The GitHub Advisory Database classifies the overall severity of this vulnerability as LOW.

Through the exposed /api/v1/logs endpoint, an unauthenticated attacker can observe internal operational telemetry generated by the zerolog logging subsystem. Disclosed fields include log timestamps, severity levels (info, warn, error, debug), internal component identifiers (such as the storage engine, write-ahead log (WAL), clustering, and Raft consensus modules), Go source file paths and line numbers (caller), internal execution error messages, and network peer connection details.

This information aids in target reconnaissance (T1592 / T1082). An attacker can poll the endpoint to monitor active client activity, determine internal directory paths and software versions, and observe backend failure conditions in real time.

However, critical secrets and user data are not exposed through this vector. Specifically, Arc prints the initial bootstrap administrative token directly to standard error via fmt.Fprintf(os.Stderr, ...), bypassing the zerolog in-memory ring buffer entirely. Furthermore, Arc does not log raw SQL query text, database names, measurement identifiers, or user credentials to the operational log stream.

Basekick Labs remediated this vulnerability in Arc version v26.06.2 (Go pseudo-version 0.0.0-20260615165136-bb7d9761ad98), corresponding to commit bb7d9761ad9801e93837762ff7d37460f1df19dd. Operators running Arc should upgrade their binary or container deployments to v26.06.2 or later.

For environments where an immediate upgrade is not possible, operators can block external access to /api/v1/logs at the reverse proxy, load balancer, or ingress controller layer. Because legitimate clients and monitoring dashboards do not require unauthenticated access to /api/v1/logs, dropping or rejecting traffic to this path does not disrupt database ingestion or query operations.

# NGINX configuration block to deny access to the vulnerable endpoint
location = /api/v1/logs {
    deny all;
    return 403;
}

In Kubernetes environments using Traefik or similar ingress controllers, apply a path-matching rule or middleware to drop requests targeting /api/v1/logs. Additionally, ensure that Arc HTTP API listeners (port 8000 by default) are bound to internal management interfaces, private subnets, or encrypted overlay networks rather than exposed directly to untrusted networks.