Arcane agent token slips past admin check on debug endpoint
An advisory published on 16 October 2026 says environment-scoped tokens in Arcane v2.10.2 can reach Go profiling routes meant for global administrators only.
By The Agentic Times ·

A GitHub security advisory published on 16 October 2026 describes an authorisation flaw in Arcane v2.10.2 that lets an environment-scoped access token reach administrator-only diagnostic routes. The advisory, tracked as GHSA-mp22-58ff-6fhr and CVE-2026-96628, affects the Go package for Arcane's backend. The exposed surface is the manager's Go pprof interface at /api/debug/pprof/*, which returns diagnostic and runtime profiling information the application intends to restrict to global administrators.
According to the advisory, the problem sits in the managerAuth function of Arcane's authentication middleware. When a request carries a valid environment access token in the X-Arcane-Agent-Token header, the middleware resolves the matching environment, installs an environment-scoped permission set, and then immediately passes the request on to the next handler. That happens before the middleware evaluates its AdminRequired option and confirms the caller is a global administrator.
The result, the advisory says, is an inconsistency between Arcane's two authentication paths. Ordinary user or session authentication still reaches the check that returns a 403 "FORBIDDEN" response when the caller is not a global admin. The environment-token path never gets there. In practice, the advisory states, calling WithAdminRequired() on a route has no effect when authentication succeeds through a valid environment access token.
The advisory stresses that environment tokens were never meant to carry administrator rights. The function that builds their permissions, EnvironmentPermissionSet, grants only environment-scoped permissions for one specified environment and deliberately includes no global or sudo permissions. The early return in managerAuth therefore crosses an intended privilege boundary rather than reflecting a design decision.
The advisory also confirms that the environment-token path is live in shipped builds, not just in test configurations. Arcane's dependency injection setup wires the authentication middleware with an environment access-token resolver alongside its API key validator and permission resolver, so the X-Arcane-Agent-Token route is active in the production manager.
The diagnostic routes themselves are registered with the stricter gate. The advisory quotes the route registration, which creates a /debug/pprof group protected by WithAdminRequired(), and notes that the source code documents this stricter intent. The group exposes the standard Go profiling handlers, including the index, cmdline, profile, symbol, trace, heap, goroutine, allocs, block, mutex and threadcreate, with named profiles dispatched through pprof.Handler.
Other middleware does not catch the gap, according to the advisory. The cross-site request forgery middleware treats X-Arcane-Agent-Token as a header-based credential and skips its usual cross-origin validation for such requests. The environment proxy middleware passes through any request that does not target an /environments/{id}/... path, which includes /api/debug/pprof/*. A request can therefore travel from the header, through the token resolver, into the environment branch, and out to the profiling handler without any further global-administrator check.
The advisory classifies the issue as incorrect authorisation, CWE-863. It describes the flaw as an information exposure problem, with profiling and runtime data as the affected asset in version 2.10.2, rather than a route to code execution. The advisory does not state that the flaw has been exploited.
Sources
- github.comhttps://github.com/advisories/GHSA-mp22-58ff-6fhr
