Rust crate sequoia-git bug lets hard revocations slip past commit checks

A low CVSS score did not make this one small. RUSTSEC-2026-0109 showed that sequoia-git, the Rust crate for verifying signed Git commits and repository policies, could quietly miss a hard revocation and let a broken trust decision look valid.

The advisory was reported on April 21, 2026 and issued on April 24, 2026 with a CVSS score of 1.8, but the practical issue was integrity, not crash risk. Sequoia git is built to authenticate repository changes from a signing policy embedded in the repo itself, so projects do not need third-party authorities to check history. A commit is authorized only if it is signed and an immediate parent policy authorizes the signer’s certificate for that change. In that model, a hard revocation is supposed to slam the door on a compromised key.

The bug sat in the cache path. sq-git cached policy lookups by hash to avoid repeatedly parsing a policy that rarely changes, but the hash used for the cache key was truncated to 0 bytes. That meant the optimization effectively looked only at hard revocations in the target commit, not the broader policy context that should have been consulted. The advisory’s concrete example is the one that matters: Alice and Bob co-maintain a project, Bob’s certificate is compromised, and Bob later issues a hard revocation. Alice adds that revocation to the signing policy. An attacker with Bob’s key then sends a merge request that strips the revocation. If Alice merges it, the latest commit no longer carries the hard revocation, and sq-git can fail to notice the missing revocation when authenticating that commit or later ones.

That is the false reassurance problem. The workflow still looks signed, still looks policy-backed, and still looks like release engineering is doing its job, even though the very control meant to quarantine a stolen key has been undercut. Sequoia’s own documentation says hard revocations are meant to invalidate both earlier and later commits signed with that key, which is exactly why this class of bug matters in signed-history systems.

The fix is in sequoia-git 0.6.0 and later, with RustSec pointing to upstream commit f9c9074bd80023456221f09c3c4ff19957ee9c58. Hassan Sheet reported the issue, and Fedora has already opened an update tied to RUSTSEC-2026-0109. That reach fits the crate’s real-world footprint: Sequoia, The Tor Project’s system administration team, Kicksecure, Whonix, Chewing Input Method, and Framedly all use the tooling in production-style workflows. In signed Git, a cache bug that weakens revocation checks is not a footnote. It is the kind of flaw that can let compromised history keep passing review.