CVE-2025-31130: gitoxide SHA-1 Collision Vulnerability

CVE-2025-31130 Overview

CVE-2025-31130 affects gitoxide, a pure Rust implementation of Git. Versions prior to 0.42.0 use standard SHA-1 hash implementations from the sha1_smol and sha1 crates without any collision detection mitigations. Two distinct Git objects with colliding SHA-1 hashes can therefore break the Git object model and integrity checks when processed by gitoxide. The weakness is classified as [CWE-328] (Use of Weak Hash) and impacts the integrity of Git repositories consumed by any tool built on gitoxide. The issue is resolved in version 0.42.0, which switches to the sha1-checked crate.

Critical Impact
An attacker able to craft SHA-1 colliding Git objects can subvert repository integrity guarantees in tools that rely on gitoxide.

Affected Products

gitoxide versions prior to 0.42.0
Rust projects depending on gix-* crates that use sha1_smol or sha1
Downstream tools embedding gitoxide for Git object handling

Discovery Timeline

2025-04-04 - CVE-2025-31130 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-31130

Vulnerability Analysis

Git identifies every object (blob, tree, commit, tag) by its SHA-1 hash. When two different objects produce the same hash, the object database, pack index, and integrity checks all fail to distinguish them. gitoxide computed these hashes using the sha1_smol and sha1 crates, both of which implement plain SHA-1. Neither crate detects the cryptanalytic patterns used in known SHA-1 collision attacks such as SHAttered.

Git itself uses sha1dc (SHA-1 with collision detection) to abort hashing when a colliding block structure is observed. Because gitoxide lacked this mitigation, a repository containing a crafted colliding object would be accepted by gitoxide even though canonical Git would reject it. This creates a divergence between Git implementations that an attacker can weaponize to smuggle malicious content past code review or signature workflows.

Root Cause

The root cause is the direct use of unmitigated SHA-1 for security-relevant object identity. The Cargo.toml and Cargo.lock shipped with vulnerable releases pin sha1 and sha1_smol as the hashing backends. Neither implementation raises an error on the disturbance vectors characteristic of chosen-prefix SHA-1 collisions.

Attack Vector

Exploitation requires an attacker to produce two Git objects with a colliding SHA-1 and introduce one variant into a repository consumed by gitoxide. Because the attack complexity is high, it is not opportunistic. However, the network attack vector and lack of privilege or user interaction requirements mean any code path that fetches, clones, or verifies remote objects with gitoxide is exposed.

text

// Patch: Cargo.lock removes plain SHA-1 crates
  "once_cell",
  "parking_lot",
  "prodash 29.0.1",
- "sha1",
- "sha1_smol",
  "thiserror 2.0.12",
  "walkdir",
 ]

text

// Patch: Cargo.toml switches to sha1-checked
 gix-actor = { opt-level = 3 }
 gix-config = { opt-level = 3 }
 miniz_oxide = { opt-level = 3 }
-sha1 = { opt-level = 3 }
-sha1_smol = { opt-level = 3 }
+sha1-checked = { opt-level = 3 }

Source: GitoxideLabs commit f253f02

Detection Methods for CVE-2025-31130

Indicators of Compromise

Two Git objects in a repository sharing identical SHA-1 hashes but differing byte content.
Discrepancies between gitoxide-based tooling and canonical Git (sha1dc) when validating the same repository.
Unexpected object replacement observed after fetch or clone operations performed by gitoxide clients.

Detection Strategies

Inventory Rust build manifests for direct or transitive dependencies on gitoxide, gix-*, sha1_smol, or sha1 at versions below 0.42.0.
Cross-validate suspicious repositories by hashing objects with sha1dc and comparing against gitoxide output.
Scan CI/CD pipelines and developer workstations for tools that embed vulnerable gitoxide releases.

Monitoring Recommendations

Track dependency updates via software composition analysis to flag gitoxide < 0.42.0.
Alert on Git fetch operations that produce objects failing canonical git fsck validation.
Log and review any process that reads pack files or object databases using gitoxide in high-trust environments.

How to Mitigate CVE-2025-31130

Immediate Actions Required

Upgrade gitoxide and all gix-* crates to version 0.42.0 or later.
Rebuild and redeploy any binary that statically links vulnerable gitoxide versions.
Validate repositories cloned by vulnerable clients using canonical Git with sha1dc enabled.

Patch Information

The fix is committed in f253f02a6658b3b7612a50d56c71f5ae4da4ca21 and released in gitoxide0.42.0. The patch replaces the sha1 and sha1_smol crates with sha1-checked, which implements collision detection equivalent to sha1dc. Details are documented in GitHub Security Advisory GHSA-2frx-2596-x5r6.

Workarounds

Where upgrading is not immediately possible, route Git operations through canonical Git (git with sha1dc) rather than gitoxide.
Restrict gitoxide-based tooling to trusted repositories under access control until the upgrade is deployed.
Enforce signed commits and tags so tampered objects fail signature verification even if hash integrity is bypassed.

bash

# Update gitoxide in a Rust project
cargo update -p gix
cargo add gix@^0.42
# Verify no vulnerable transitive dependency remains
cargo tree -i sha1_smol || echo "sha1_smol not present"
cargo tree -i sha1 || echo "sha1 not present"