CVE-2026-72825

This vulnerability exposes a fundamental flaw in how Grav's authorization layers interact. An API key scoped to api.config.write—a token explicitly minted to limit damage—can be nullified by calling isSuperAdmin(), which interrogates a completely separate authorization store (access.api.super) that was never designed to respect token scope constraints. The result is a direct violation of least privilege at the architectural level: your limited token grants super-level privileges. The practical impact is worse than a typical auth bypass. Successful exploitation writes attacker-controlled entries to security.yaml, persisting the SSTI surface permanently. Revoking the API key does not close the backdoor—the modified config remains until manual audit. This transforms the threat model from "credential theft requiring ongoing access" to "one successful call creates a persistent compromise." Treat this as a systemic issue, not an isolated bug. The ReportsController mixes requirePermission() and isSuperAdmin() in the same code path, suggesting developers don't have clear guidance on which check to use where. The pattern—role-based checks silently bypassing scope restrictions—likely exists elsewhere. Your immediate priority: audit all endpoints that accept scoped API keys for any isSuperAdmin() or equivalent role checks that could nullify the scope. Replace them with requireSuper() if super access is genuinely required, but prefer scope-specific requirePermission() checks where fine-grained access is appropriate. The long-term fix requires formal documentation establishing that scope restrictions always dominate role checks, or deprecating role-based methods in scope-gated contexts entirely. Without that, the next developer under pressure will make the same mistake on a different endpoint.

Reviewed through automated stages and approved by a human before publication.