🛡️ CVE-2014-6274 — git-annex
Description
git-annex plaintext storage of embedded credentials on encrypted remotes
# *git-annex* plaintext storage of embedded credentials on encrypted remotes
*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.
That means that anyone who gets a copy of the Git repository can
extract the AWS credentials from it. Which would be bad.
A remote with this problem cannot be enabled using `git annex
enableremote`. Old versions of *git-annex* will fail with a GPG
error; the current version will fail with a pointer to this web
page.
Remediation
If your repository has this problem, chose from one of these
approaches to deal with it:
1. Change your AWS credentials, so the ones stored in the clear in
git won't be used.
After changing the credentials, make sure you have a fixed
version of git-annex, and you can then re-embed the new creds
into the repository, encrypted this time, by setting the
AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID environment
variables, and running `git annex enableremote $remotename
embedcreds=yes`.
2. Fix the problem and then remove the history of the *git-annex*
branch of the repository.
Make sure you have a fixed version of *git-annex*, and force
*git-annex* to rewrite the embedded creds, with encryption this
time, by setting by setting the AWS_SECRET_ACCESS_KEY and
AWS_ACCESS_KEY_ID environment variables, and running `git annex
enableremote $remotename embedcreds=yes`.
Then, to get rid of old versions of the *git-annex* branch that
still contains the creds in cleartext, you can use `git annex
forget`; note that it will remove other historical data too.
Keep in mind that this will not necessarily delete data from
clones you do not control.
3. If you're sure that you're the only one who has access to the
repository, you could decide to leave it as-is. It's no more
insecure than if you had used encryption=shared in the first
place when setting it up.
Affected software
CVE-2014-6274 is recorded against 1 package.
- git-annex (from 0.20110401 up to 5.20140919)
Timeline and source
Published on 14 November 2025. No public exploit is currently recorded for this entry. Record sourced from OSV.
References
git-annex.branchable.com (Advisory)
git-annex.branchable.com (Article)
CVE-2014-6274 on other distributions
Each distribution ships its own build and its own fixed version. Pick the one you run:
Details
Affected Packages
| Software | From version | Fixed in |
|---|---|---|
| git-annex | 0.20110401 | 5.20140919 |
References
Similar Threats
- Unknown openSUSE-SU-2026:11087-1
- Unknown CVE-2017-12976
- Unknown CVE-2018-10857
- Unknown CVE-2018-10859
- Unknown HSEC-2023-0012
More CVE 2014 advisories
Browse all of CVE 2014 in the advisory index.
Free Vulnerability Check
Is your site affected by CVE-2014-6274?
BotEraser helps you identify potentially vulnerable plugins and themes by checking your installation against CVE-2014-6274 and other known CVE records.
Scan My Site Free →No credit card required · Results in minutes
ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.