git-annex CVE-2026-112818

Exploitation requires three concrete preconditions stated in the advisory: (1) the attacker must control one of the victim's git-annex remotes, typically by supplying a git-annex repository that the victim clones; (2) the attacker must already have obtained information about the victim's private repository - either specific annexed keys/files known to be present, or the network location of the victim's private git repository; and (3) the victim must run a content-transferring command such as git-annex sync --content against a special or git remote that was autoenabled on init (variants 1 and 3) or manually enabled and then retargeted by the attacker (variant 2). Limiting factors: the attack needs victim interaction (cloning the hostile repo and running a sync-with-content command), prior attacker reconnaissance of the private data, and the special-remote autoenable or manual-enable path; it is not a remote unauthenticated hit against a default service. The fix makes git-annex enableremote display the special-remote configuration and require the user to verify it is safe before use, and restricts how autoenabled special remotes may be used; updating is the complete fix.

No CVSS vector, EPSS score, KEV listing, or SSVC technical-impact decision is provided; the vuln.today priority is explicitly 'awaiting_data', so quantitative signals are absent and the following is derived from the vendor advisory text alone. The flaw is a genuine confidentiality breach - cross-repository private data exfiltration - but exploitation is conditional rather than trivial: the attacker must already control one of the victim's git-annex remotes (e.g., supply a repository the victim clones) AND must already possess specific knowledge of the victim's private repository (which annexed keys/files exist, or the location of the private git repo), AND the victim must enable the remote and run a content-transferring command such as git-annex sync --content. This combination of attacker precondition (foothold as a remote plus prior reconnaissance) and required victim interaction makes it closer to a targeted, high-complexity attack than mass-exploitable. There is no high CVSS to contradict - none was assigned - so this is better characterized as a real but narrow-surface confidentiality risk affecting a niche tool, not a widespread emergency. Patch promptly, especially where repositories are cloned from untrusted sources, but the attack is not automatable against default internet-facing deployments.

An attacker publishes a malicious git-annex repository and waits for a victim to clone it; on initialization git-annex autoenables an attacker-configured special remote (or git remote) that points at the victim's own private data store. When the victim later runs git-annex sync --content, their private annexed files are retrieved and transferred to the attacker. No public exploit code is identified at time of analysis; the vendor (Joey Hess) describes the technique in detail but references are advisories, not weaponized PoC.