CVE-2026-96628

## Summary Arcane v2.10.2 contains an authorization inconsistency in `AuthMiddleware.managerAuth`. When a request supplies a valid environment access token through the `X-Arcane-Agent-Token` header, `managerAuth` resolves the associated environment, installs an environment-scoped permission set, and immediately calls `next(c)`. This occurs before the middleware evaluates the `AdminRequired` option and verifies that the caller is a global administrator. As a result, an environment-scoped access token can access routes protected with `WithAdminRequired()`, despite the corresponding `EnvironmentPermissionSet` intentionally containing no global or sudo permissions. In v2.10.2, the affected admin-only surface is the manager's Go `pprof` diagnostic interface under: `/api/debug/pprof/*` This exposes diagnostic and runtime profiling information that the application explicitly intends to restrict to global administrators. The issue is an incorrect authorization vulnerability (CWE-863). ## Details ### 1. Environment access tokens are accepted by the manager authentication middleware The production authentication middleware is configured with an environment access-token resolver: `backend/internal/di/providers.go` Conceptually, the middleware is constructed as: ```go auth.NewAuthMiddleware(authService, cfg). WithApiKeyValidator(apiKey). WithEnvironmentAccessTokenResolver(env). WithPermissionResolver(role) ``` Therefore, the `X-Arcane-Agent-Token` authentication path is active in the production manager. ### 2. The environment-token path returns before authorization options are evaluated The relevant logic is in: `backend/internal/auth/middleware.go` `managerAuth` first checks the `X-Arcane-Agent-Token` header. When the token resolves to an environment, the middleware installs an environment-scoped permission set and immediately continues processing: ```go if agentToken := req.Header.Get(utils.HeaderAgentToken); agentToken != "" { if env, ok