Where
-Infinity
0

Vendor Risk Score

See how git-annex compares to other vendors in security performance

View Risk Score →
Severity
4

[Unknown description]

First published (updated )

I have released git-annex 10.20261026, which fixes a cross-repository data exfiltration attack.

https://git-annex.branchable.com/download/

There are also backported patches for several past versions available as branches in the git repository: CVE-2026-112818-patch-10.20250416 CVE-2026-112818-patch-10.20251029 CVE-2026-112818-patch-10.20261006

https://git-annex.branchable.com/security/crossrepositorydataexfiltrationviaspecialremote/

To perform these attacks, the attacker needs to have control over one of the remotes of the victim's git-annex repository. For example, they may provide a git-annex repository that the victim clones.

The attacker also needs to have a certian amount of information about the victim's private repository that they have obtained in some way. For example, the victim may have published a git repository but be keeping the annexed files private.

In the simplest form of the attack, the attacker provides a git-annex repository that includes in its tree annexed files that the attacker knows are present in the victim's private git-annex repository. When git-annex is initialized in the victim's clone, git-annex autoenables a special remote that the attacker has configured to access the victim's private git-annex repository. When the victim runs a command such as git-annex sync --content, their private files are retrieved from the special remote and sent to the attacker.

In another form of the attack, autoenable of special remotes is not needed. Instead, the attacker provides a special remote (eg a S3 bucket) along with their git-annex repository. The attacker waits for the victim to clone the repository and manually enable and use their special remote. Then they update the configuration of the special remote, retargeting it to access the victim's own special remote (eg the victim's private S3 bucket). When the victim runs a command such as git-annex sync --content, their private files are retrieved from their special remote and sent to the attacker.

A third form of the attack only requires that the attacker knows the location of the victim's private git repository. The attacker provides a git-annex repository that the victim clones. When git-annex is initialized in the victim's clone, it autoenables a git remote pointing to the victim's private git repository. The first time the victim runs a command such as git-annex sync --content, the attacker learns what git-annex keys are used by annexed files in the private git repository, and adds them to the tree. The second time the victim runs such a command, their private files are retrieved from their private git repository and sent to the attacker.

Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

git-annex had a bug in the S3 and Glacier remotes where if embedcreds=yes was set, and the remote used encryption=pubkey or encryption=hybrid, the embedded AWS credentials were stored in the git repository in (effectively) plaintext, not encrypted as they were supposed to be. This issue affects git-annex: from 3.20121126 before 5.20140919.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203