CVE-2026-62667

When the Grav API plugin authenticates a request, it retrieves the owning user's complete identity and returns that — regardless of what scopes were declared when the API key was generated. A key issued with read-only access will work perfectly for administrative operations, because the scope array is stored but never consulted during authentication. This is not a logic error in one function; it's a disconnect between two components where security metadata is generated and persisted but never retrieved or evaluated. The ApiKeyManager generates keys with a scopes array and persists it to storage. The ApiKeyAuthenticator authenticates without reading this data. The developer likely believed the scope mechanism was functional — they wrote the code to declare and persist scopes, and the array appears in admin interfaces. That visibility created false confidence. There is no error, no warning, no log entry when a read-only key performs admin operations. The system works; the security control is invisible. This makes the vulnerability particularly insidious. The blast radius is bounded by the owning user's full ACL, not the declared scope. A read-only key for an administrator grants everything the administrator can do. The scope field was actively misleading because it implied a ceiling on damage that doesn't exist. Compounding this, the vulnerability is fundamentally undiscoverable by operators — there's no audit trail, no anomaly signal. A read-only key performing administrative actions leaves no trace that anything is wrong. The fix in version 1.0.6 adds scope validation to the authentication path. However, this creates a separate problem: keys issued under the broken version carry scope arrays that were never meaningful. The enforcement is now real, but the stored data is archaeological sediment from an era when those values were decorative. The upgrade path may require key regeneration — without it, old keys silently fall through to a system that believes it is enforcing scopes while reading data that was never authoritative. For defenders: audit all existing API keys and regenerate them after patching. Implement integration tests that verify read-only keys cannot perform write operations. The absence of such a test is itself evidence the vulnerability existed undetected. Monitor for the pattern of key age and scope, because keys issued before the fix carry implicit risk that the new enforcement may not map to their stored scope data.

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