gitoxide does not detect SHA-1 collision attacks

CISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.

No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.

gitoxide is an implementation of git written in Rust. Before 0.42.0, gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. This vulnerability is fixed in 0.42.0.

Source published

4 Apr 2025 14:41:56 UTC

Source modified

23 Jan 2026 17:08:57 UTC

Saved here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

gitoxide is an implementation of git written in Rust. Before 0.42.0, gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. This vulnerability is fixed in 0.42.0.

Source published

Apr 4, 2025, 2:41:56 PM (timezone not stated)

Source modified

Jan 23, 2026, 5:08:57 PM (timezone not stated)

Saved here

15 Nov 2026 03:40:48 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

EUVD CVSS 3.1 · 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

gitoxide is an implementation of git written in Rust. Before 0.42.0, gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. gitoxide uses the sha1_smol or sha1 crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. This vulnerability is fixed in 0.42.0.

Source published

4 Apr 2025 15:15:48 UTC

Source modified

17 Jun 2026 09:09:54 UTC

Saved here

25 Oct 2026 02:24:48 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS 3.1 · [email protected] · Secondary · 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

### Summary gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. ### Details gitoxide uses the `sha1_smol` or `sha1` crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the [sha1collisiondetection](https://github.com/crmarcstevens/sha1collisiondetection) algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes. ### PoC The following program demonstrates the problem, using the two [SHAttered PDFs](https://shattered.io/): ```rust use sha1_checked::{CollisionResult, Digest}; fn sha1_oid_of_file(filename: &str) -> gix::ObjectId { let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1); hasher.update(&std::fs::read(filename).unwrap()); gix::ObjectId::Sha1(hasher.digest()) } fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> { // Matches Git’s behaviour. let mut hasher = sha1_checked::Builder::default().safe_hash(false).build(); hasher.update(&std::fs::read(filename).unwrap()); match hasher.try_finalize() { CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())), CollisionResult::Mitigated(_) => unreachable!(), CollisionResult::Collision(digest) => Err(format!( "Collision attack: {}", gix::ObjectId::Sha1(digest.into()).to_hex() )), } } fn main() { dbg!(sha1_oid_of_file("shattered-1.pdf")); dbg!(sha1_oid_of_file("shattered-2.pdf")); dbg!(sha1dc_oid_of_file("shattered-1.pdf")); dbg!(sha1dc_oid_of_file("shattered-2.pdf")); } ``` The output is as follows: ``` [src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a) [src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a) [src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err( "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a", ) [src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err( "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a", ) ``` The latter behaviour matches Git. Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources. ### Impact An attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities. This vulnerability affects any user of gitoxide, including `gix-*` library crates, that reads or writes Git objects.

Source published

4 Apr 2025 16:06:08 UTC

Source modified

10 Sep 2026 03:50:56 UTC

Saved here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N

Publisher rating · MODERATE

### Summary gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. ### Details gitoxide uses the `sha1_smol` or `sha1` crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the [sha1collisiondetection](https://github.com/crmarcstevens/sha1collisiondetection) algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes. ### PoC The following program demonstrates the problem, using the two [SHAttered PDFs](https://shattered.io/): ```rust use sha1_checked::{CollisionResult, Digest}; fn sha1_oid_of_file(filename: &str) -> gix::ObjectId { let mut hasher = gix::features::hash::hasher(gix::hash::Kind::Sha1); hasher.update(&std::fs::read(filename).unwrap()); gix::ObjectId::Sha1(hasher.digest()) } fn sha1dc_oid_of_file(filename: &str) -> Result<gix::ObjectId, String> { // Matches Git’s behaviour. let mut hasher = sha1_checked::Builder::default().safe_hash(false).build(); hasher.update(&std::fs::read(filename).unwrap()); match hasher.try_finalize() { CollisionResult::Ok(digest) => Ok(gix::ObjectId::Sha1(digest.into())), CollisionResult::Mitigated(_) => unreachable!(), CollisionResult::Collision(digest) => Err(format!( "Collision attack: {}", gix::ObjectId::Sha1(digest.into()).to_hex() )), } } fn main() { dbg!(sha1_oid_of_file("shattered-1.pdf")); dbg!(sha1_oid_of_file("shattered-2.pdf")); dbg!(sha1dc_oid_of_file("shattered-1.pdf")); dbg!(sha1dc_oid_of_file("shattered-2.pdf")); } ``` The output is as follows: ``` [src/main.rs:24:5] sha1_oid_of_file("shattered-1.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a) [src/main.rs:25:5] sha1_oid_of_file("shattered-2.pdf") = Sha1(38762cf7f55934b34d179ae6a4c80cadccbb7f0a) [src/main.rs:26:5] sha1dc_oid_of_file("shattered-1.pdf") = Err( "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a", ) [src/main.rs:27:5] sha1dc_oid_of_file("shattered-2.pdf") = Err( "Collision attack: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a", ) ``` The latter behaviour matches Git. Since the SHAttered PDFs are not in a valid format for Git objects, a direct proof‐of‐concept using higher‐level APIs cannot be immediately demonstrated without significant computational resources. ### Impact An attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in the logic of programs using gitoxide to cause further vulnerabilities. This vulnerability affects any user of gitoxide, including `gix-*` library crates, that reads or writes Git objects.

Source published

3 Apr 2025 12:00:00 UTC

Source modified

9 Nov 2026 11:00:02 UTC

Saved here

9 Nov 2026 12:02:17 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

Source: osv · OSV · upstream source license applies. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N