gitoxide CVE-2026-82249

Exploitation requires all of the following to be true simultaneously: the target environment must use gitoxide (not standard git) as the Git client; a credential helper must be actively configured in the gitoxide or system Git configuration - environments with no credential helper are unexploitable; the attacker must be able to supply or influence a URL that gitoxide processes and forwards to the helper (e.g., via a malicious remote URL, submodule reference, or redirected fetch); and the user must initiate a gitoxide operation (clone, fetch, push) that triggers the credential lookup against the malicious URL (CVSS UI:P). Exploitation is further constrained by CVSS AC:H and AT:P, meaning opportunistic or automated attacks are not feasible without the specific environment alignment described above. The following limit exploitation in practice: most production CI/CD pipelines use standard git rather than gitoxide; credential helpers are an opt-in configuration; and the attack produces only low-confidence credential exposure, not arbitrary command execution.

The CVSS 4.0 score of 2.3 (AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) accurately characterises the constrained risk profile. While the attack originates over the network and requires no privileges on the attacker side (PR:N), it demands high attack complexity (AC:H), specific attack prerequisites (AT:P - credential helper must be configured), and user interaction (UI:P - the developer must initiate a git operation against the malicious URL). The confidentiality impact is limited to low (VC:L) because only the credentials for one mistargeted host are exposed; integrity and availability are unaffected. No EPSS data was included in the provided intelligence, and the vulnerability is absent from CISA KEV, confirming no verified active exploitation at time of analysis. No proof-of-concept was identified. The primary realistic threat is targeted credential theft against developers who clone or fetch from attacker-influenced sources while using gitoxide with a credential helper - opportunistic mass exploitation is unlikely given the complexity constraints.

An attacker publishes a malicious Git repository - or compromises a submodule reference in a legitimate project - containing a remote URL with embedded carriage return characters in a position that gitoxide processes and relays to a credential helper. When a developer using an affected gitoxide version runs a clone or fetch operation, gitoxide constructs a credential helper request using the unsanitized URL, injecting the attacker-controlled host field into the protocol stream. The credential helper, interpreting the injected field as legitimate input, returns the developer's stored credentials for the attacker-specified host rather than the intended repository host, enabling the attacker to harvest those credentials passively. No public proof-of-concept was identified in the provided data, though the underlying carriage-return injection technique is well-documented in prior Git credential protocol research.