CVE-2026-74877

CVE-2026-74877 exposes a dangerous pattern: cryptographic signature verification was added to a key revocation function without a corresponding authorization check. The library correctly proves 'this client signed this request' but never asks whether that client has permission to revoke the key being targeted. An attacker who possesses a validly-signed key need only submit that signature to revoke someone else's key — the crypto is sound, the authorization is absent. The critical misconception is treating signature verification as a complete security boundary. It is not. It establishes authenticity, which is a separate concern from authorization. A developer who implemented ML-DSA verification has solved the hard cryptographic problem; what they appear to have skipped is the question of what an authenticated client is permitted to do. This is the authentication/authorization conflation that produces consistent, high-severity CVEs across JWT, OAuth, SSH, and now ML-DSA implementations — the pattern is not novel, which means the fix is not novel either, but the institutional memory to prevent it keeps rotting away. To assess your exposure: locate the revoke_key method in your ML-DSA library and verify whether it contains an explicit ownership check — the signer must not only provide a valid signature but must be the owner of the key being revoked. If the method accepts any valid signature and proceeds, you have this vulnerability. The remediation is a one-line ownership assertion; the harder problem is that the API contract now trains downstream consumers that signature verification suffices, which creates compounding risk across your dependency tree. Review your library version against the CVE disclosure, prioritize upgrading to any version that adds the ownership gate, and audit adjacent methods in the same trust boundary for the same pattern.

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