GHSA-G27R-R6PH-VF5R: Authentication Bypass via Policy Hash Truncation in sequoia-git

The sequoia-git library and its corresponding sq-git command-line tool provide OpenPGP-based commit authentication for Git repositories. These tools evaluate cryptographic signatures against a project-defined security policy to establish the authenticity and integrity of the commit history. Vulnerability GHSA-G27R-R6PH-VF5R affects all versions of sequoia-git prior to 0.6.0.

The vulnerability exists within the performance optimization routines responsible for caching policy evaluation results. To reduce the computational overhead of repeatedly parsing and validating OpenPGP policies during repository traversal, sq-git implements a key-value caching mechanism. This cache keys previously evaluated policy states using a cryptographic hash of the policy contents.

A logic flaw in the hash generation implementation causes the policy hash to be truncated to zero bytes. This truncation fundamentally breaks the caching architecture by destroying cache key uniqueness. Consequently, the tool fails to accurately track policy state changes across the commit history, specifically failing to carry forward hard revocations of compromised cryptographic keys.

The resulting security impact allows an attacker to bypass commit authentication mechanisms under specific conditions. If an attacker successfully introduces a commit that temporarily strips a hard revocation from the policy file, the caching bug causes sq-git to permanently drop the historical revocation state. Subsequent commits signed with the compromised key will pass authentication checks.

The root cause of RUSTSEC-2026-0109 is a software defect in the generation of cache keys for OpenPGP policy objects. The sequoia-git library attempts to hash the contents of the active signing policy to uniquely identify the policy state at any given point in the Git history. This hash acts as the lookup index for the evaluation cache.

During the execution of the hashing routine, a logic error prevents the calculated digest from being properly written to the output buffer. The implementation yields an empty, zero-byte array instead of a valid cryptographic hash. Because the output is consistently empty regardless of the input policy data, every distinct policy state generates the exact same cache key.

This uniform key generation results in deterministic cache collisions during repository processing. When sq-git evaluates a new commit, it computes the zero-byte hash for the current policy and queries the cache. The tool invariably retrieves a mismatched, previously cached policy state or incorrectly matches an empty initialization state.

Because the tool relies on the retrieved cache object to enforce cryptographic constraints, it loses visibility into cumulative policy changes. Specifically, the tool evaluates hard revocations only against the immediate target commit rather than applying the persistent revocation state accumulated throughout the repository history. The zero-byte collision effectively blinds the tool to historical key revocations.

The vulnerable code path involves the sq-git subsystem responsible for ingesting OpenPGP policy files and indexing them for performance optimization. Prior to version 0.6.0, the hashing function initialized a buffer but failed to properly populate it with the computed digest of the policy structure. The function returned a zero-length byte slice to the cache manager.

The fix, implemented in commit f9c9074bd80023456221f09c3c4ff19957ee9c58, corrects the buffer handling logic within the hashing routine. The patched code ensures that the complete, variable-length cryptographic digest is written to the buffer and accurately returned to the calling function. This restores the one-to-one mapping between policy states and cache keys.

By enforcing accurate hash calculation, the patch eliminates the cache collisions that caused the vulnerability. When a project policy is updated to include a hard revocation, the resulting hash correctly reflects the new state. The caching mechanism can successfully differentiate between the pre-revocation and post-revocation policy objects during repository traversal.

The remediation strategy addresses the root cause comprehensively without requiring architectural changes to the caching system itself. The patch data confirms that the vulnerability was strictly an implementation defect in the hashing utility rather than a fundamental design flaw in the OpenPGP evaluation logic.

Exploiting this vulnerability requires an attacker to possess a compromised OpenPGP key that the project administrators have already formally revoked. The target repository must actively utilize sequoia-git for commit signature verification. The attacker must also possess the capability to submit code changes to the repository, typically via a pull request or merge request workflow.

The attack sequence initiates with the attacker crafting a malicious commit using the compromised key. Within this commit, the attacker deliberately modifies the project's signature policy configuration file. The modification specifically removes the hard revocation entry corresponding to the compromised key, effectively attempting to reinstate the key's authorization.

The attacker must then rely on social engineering or procedural oversight to trick a repository maintainer into approving and merging the malicious request. The vulnerability cannot be exploited autonomously; it strictly requires active user interaction from a privileged maintainer. Once the maintainer merges the policy modification, the repository baseline is updated.

Due to the zero-byte hash collision bug, sq-git fails to properly evaluate the policy downgrade against the historical repository state. The caching subsystem incorrectly validates the current, compromised policy state. Consequently, the attacker can submit subsequent commits signed with the revoked key, and the automated signature checks will pass without raising an alert.

The fundamental impact of this vulnerability is the potential circumvention of cryptographic authentication controls within Git repositories. An attacker can successfully forge commit signatures using a revoked key, allowing them to inject unauthorized code into a protected codebase. This compromises the integrity guarantees provided by repository signature enforcement.

Despite the severity of the theoretical impact, the vulnerability is classified with a Low severity rating, carrying a CVSS v4.0 score of 1.8. The exploitability is severely constrained by the prerequisites and attack requirements. The attacker must already possess a previously trusted key and must successfully execute a social engineering attack against a project maintainer.

The requirement for High Privileges (a known, albeit revoked, key) and Active User Interaction (maintainer approval) mitigates the risk of widespread, automated exploitation. The vulnerability cannot be weaponized into a mass-exploitation tool or wormable payload. It requires targeted, manual execution tailored to a specific repository and its maintainers.

Organizations relying on sequoia-git for strict compliance or regulatory requirements face the highest risk. In these environments, the assumption of non-repudiation and cryptographic integrity is critical. A successful attack undermines the audit trail and invalidates the core security properties of the version control system.

The definitive remediation for GHSA-G27R-R6PH-VF5R is upgrading the sequoia-git library and the associated sq-git binary to version 0.6.0 or later. This release contains the corrected hashing implementation and fully resolves the cache collision vulnerability. All downstream projects and deployment pipelines utilizing the library must be recompiled and deployed with the patched version.

Repository administrators should implement procedural mitigations to detect and prevent exploitation attempts during the patching window. Maintainers must establish stringent review requirements for any modifications targeting OpenPGP policy files or related configurations. Changes to policy definitions should mandate multiple independent approvals and out-of-band verification.

Development teams should actively audit their repository histories for unauthorized policy modifications. Specifically, security engineers should search for commits that remove hard revocations or unexpectedly alter the authorized key lists. Identifying such commits may indicate a historical compromise or an ongoing exploitation attempt.

Furthermore, organizations should consider implementing automated checks within their continuous integration pipelines to monitor policy file integrity. Rejecting any unapproved modifications to security policies at the pipeline level provides a defense-in-depth measure against both malicious exploitation and accidental misconfiguration.