gix-transport
An idiomatic, lean, fast & safe pure Rust implementation of Git
Activity
- Latest release
- 1w ago
- Total releases
- 60
- Cadence
- ~19 days
- Last 12 months
- 19
Reach
- Downloads
- 40.3M
- Stars
- 11.9k
Details
- License
- MIT OR Apache-2.0
- First release
- Feb 17, 2023
| Version | Released | |
|---|---|---|
0.59.2
patch
|
0.59.2
patch
Dependencies (23)
+ 15 more
Changelog
Compare changes
|
|
0.59.1
patch
|
0.59.1
patch
Dependencies (23)
+ 15 more
Changelog
Compare changes
|
|
0.59.0
minor
|
0.59.0
minor
Dependencies (24)
+ 16 more
Changelog
Compare changes
|
|
0.58.1
patch
|
0.58.1
patch
Dependencies (24)
+ 16 more
Changelog
Compare changes
|
|
0.58.0
minor
|
0.58.0
minor
Dependencies (24)
+ 16 more
Changelog
Compare changes
|
|
0.57.2
patch
|
0.57.2
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.57.1
patch
|
0.57.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.57.0
minor
|
0.57.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.56.0
minor
|
0.56.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.55.1
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.55.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.55.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.55.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.54.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.54.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.53.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.53.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.52.1
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.52.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.52.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.52.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.51.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.51.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.50.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.50.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.49.1
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.49.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.49.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.49.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.48.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.48.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.47.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.47.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.46.1
patch
yanked
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.46.1
patch
yanked
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.46.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.46.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.45.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.45.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.44.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.44.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.43.1
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.43.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.43.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.43.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.42.3
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.42.3
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.42.2
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.42.2
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.42.1
patch
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.42.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.42.0
minor
1 CVE
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.42.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.41.3
patch
yanked
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.41.3
patch
yanked
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.41.2
patch
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.41.2
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.41.1
patch
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.41.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.41.0
minor
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.41.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.40.1
patch
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.40.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.40.0
minor
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.40.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.39.0
minor
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.39.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.38.0
minor
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.38.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.37.1
patch
yanked
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.37.1
patch
yanked
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.36.1
patch
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.36.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.37.0
minor
2 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev |
0.37.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.36.0
minor
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.36.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.35.0
minor
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.35.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.34.2
patch
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.34.2
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.34.1
patch
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.34.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.34.0
minor
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.34.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.33.1
patch
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.33.1
patch
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.33.0
minor
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.33.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|
|
0.32.0
minor
3 CVEs
GHSA-9857-6mw7-fq2m
May 05, 2026
gix-transport: HTTP credentials leaked to redirected host in curl backend
6.8
/ 10
Medium
Network
High
None
Required
Unchanged
High
High
None
SummaryThe curl-based HTTP transport in The reqwest backend is not affected. Its custom redirect policy at DetailsThe vulnerability involves two components in 1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs) After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, 2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)
The Attack flow: cross-domain credential leak
Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide. Secondary vector: HTTPS-to-HTTP downgradeThe cleartext protection at
This only validates the original URL's scheme, not the effective URL after redirect. A redirect from
PoCA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses To run: Create the project next to the gitoxide checkout so path dependencies resolve, then
Output:
The GET (from redirect) has no ImpactAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend ( Suggested Fix
Fixed in
0.56.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-32884
GHSA-98p4-xjmm-8mfh
RUSTSEC-2024-0335
Apr 15, 2024
gix-transport indirect code execution via malicious username
6.4
/ 10
Medium
Network
High
Low
None
Unchanged
High
Low
Low
Summary
DetailsThis is related to the patched vulnerability https://github.com/advisories/GHSA-rrjw-j4m2-mf34, but appears less severe due to a greater attack complexity. Since https://github.com/Byron/gitoxide/pull/1032, As in Git, when an address is a URL of the form This is harder to exploit than GHSA-rrjw-j4m2-mf34, because the possibilities are constrained by:
However, an attacker who is able to cause a specially named This scenario is especially plausible because programs that operate on git repositories are often run in untrusted git repositories, sometimes even to operate on another repository. Situations where this is likely, such that an attacker could predict or arrange it, may for some applications include a malicious repository with a malicious submodule configuration. Other avenues of exploitation exist, but appear to be less severe. For example, the PoCTo reproduce the known case that facilitates arbitrary code execution, first create a file in the current directory named
where (Although the syntax permitted in the value of Then run:
Or:
(The In either case, the payload specified in Other cases may likewise be produced, in either of the above two forms of SSH addresses. For example, to create or append to the file
ImpactAs in https://github.com/advisories/GHSA-rrjw-j4m2-mf34, this would typically require user interaction to trigger an attempt to clone or otherwise connect using the malicious URL. Furthermore, known means of exploiting this vulnerability to execute arbitrary commands require further preparatory steps to establish a specially named file in the current directory. The impact is therefore expected to be lesser, though it is difficult to predict it with certainty because it is not known exactly what scenarios will arise when using the Users who use applications that make use of
Fixed in
0.42.0
References Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-53158
GHSA-rrjw-j4m2-mf34
RUSTSEC-2023-0064
Sep 25, 2023
gix-transport code execution vulnerability
4.1
/ 10
Medium
Local
High
None
Required
Changed
Low
Low
None
The PoC: This will launch a calculator on OSX. See https://secure.phabricator.com/T12961 for more details on similar vulnerabilities in Thanks for vin01 for disclosing this issue. Fixed in
0.36.1
References Updated Jul 28, 2025 · Source: OSV.dev |
0.32.0
minor
Dependencies (22)
+ 14 more
Changelog
Compare changes
|