hsec-2023-0013
Vulnerability from osv_haskell
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:
- 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.
- 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.
- 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=sharedin the first place when setting it up.
{
"affected": [
{
"database_specific": {
"human_link": "https://github.com/haskell/security-advisories/tree/main/advisories/published/2023/HSEC-2023-0013.md",
"osv": "https://raw.githubusercontent.com/haskell/security-advisories/refs/heads/generated/osv-export/2023/HSEC-2023-0013.json"
},
"package": {
"ecosystem": "Hackage",
"name": "git-annex"
},
"ranges": [
{
"events": [
{
"introduced": "0.20110401"
},
{
"fixed": "5.20140919"
}
],
"type": "ECOSYSTEM"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
],
"aliases": [
"CVE-2014-6274"
],
"database_specific": {
"home": "https://github.com/haskell/security-advisories",
"osvs": "https://raw.githubusercontent.com/haskell/security-advisories/refs/heads/generated/osv-export",
"repository": "https://github.com/haskell/security-advisories"
},
"details": "# *git-annex* plaintext storage of embedded credentials on encrypted remotes\n\n*git-annex* had a bug in the **S3** and **Glacier** remotes where if\n`embedcreds=yes` was set, and the remote used `encryption=pubkey` or\n`encryption=hybrid`, the embedded AWS credentials were stored in the\nGit repository in (effectively) plaintext, not encrypted as they\nwere supposed to be.\n\nThat means that anyone who gets a copy of the Git repository can\nextract the AWS credentials from it. Which would be bad.\n\nA remote with this problem cannot be enabled using `git annex\nenableremote`. Old versions of *git-annex* will fail with a GPG\nerror; the current version will fail with a pointer to this web\npage.\n\n## Remediation\n\nIf your repository has this problem, chose from one of these\napproaches to deal with it:\n\n1. Change your AWS credentials, so the ones stored in the clear in\n git won\u0027t be used.\n\n After changing the credentials, make sure you have a fixed\n version of git-annex, and you can then re-embed the new creds\n into the repository, encrypted this time, by setting the\n `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment\n variables, and running `git annex enableremote $remotename\n embedcreds=yes`.\n\n2. Fix the problem and then remove the history of the *git-annex*\n branch of the repository.\n\n Make sure you have a fixed version of *git-annex*, and force\n *git-annex* to rewrite the embedded creds, with encryption this\n time, by setting by setting the `AWS_SECRET_ACCESS_KEY` and\n `AWS_ACCESS_KEY_ID` environment variables, and running `git annex\n enableremote $remotename embedcreds=yes`.\n\n Then, to get rid of old versions of the *git-annex* branch that\n still contains the creds in cleartext, you can use `git annex\n forget`; note that it will remove other historical data too.\n\n Keep in mind that this will not necessarily delete data from\n clones you do not control.\n\n3. If you\u0027re sure that you\u0027re the only one who has access to the\n repository, you could decide to leave it as-is. It\u0027s no more\n insecure than if you had used `encryption=shared` in the first\n place when setting it up.\n",
"id": "HSEC-2023-0013",
"modified": "2025-11-14T14:45:34Z",
"published": "2025-11-14T14:45:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://git-annex.branchable.com/security/CVE-2014-6274/"
},
{
"type": "ARTICLE",
"url": "https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
}
],
"schema_version": "1.5.0",
"summary": "git-annex plaintext storage of embedded credentials on encrypted remotes"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.