Quick Answer — In late January 2023, Git security lead Taylor Blau published a warning about a quiet class of credential-leak risks in git-credential helpers: configurations where 2FA/OATH tokens and passwords get stored — or logged — in plaintext files (like .git-credentials) or get handed to helpers that write them into world-readable stores. The finding wasn’t one CVE but a configuration foot-gun family: “store” as a credential helper, verbose logging that echoes secrets, and helpers that don’t lock files. The lesson: developer tooling is production security surface, and the safest secret is the one your tools never write to disk.
What the advisory flagged
- Git’s “store” helper: Saves credentials to ~/.git-credentials as plaintext — unencrypted, world-readable if umask is loose — and Git’s own docs tell you not to use it on shared machines.
- Verbose-mode logging: Debug flags (GIT_TRACE-style output) could echo credentials including 2FA OATH codes into terminal transcripts and CI logs where they survive indefinitely.
- Helper chaining: Systems invoking multiple helpers, or third-party helpers with sloppy file hygiene (no 0600 perms, no locking), widened the exposure: any process running as you (or a teammate on a shared box) could harvest tokens.
- Why it mattered in January 2023: A wave of supply-chain incidents involving developer endpoints (Lapsus$ screenshots, stealer-log markets) had just made “what’s readable in a dev’s home directory” a tier-1 question.
Exposure inventory
| Surface | What leaks |
|---|---|
| ~/.git-credentials (“store” helper) | Passwords and PATs in cleartext |
| Verbose/debug tracing | 2FA/OATH tokens and secrets echoed into logs |
| Third-party helper caches | Tokens in unlocked files or keyrings with weak ACLs |
| CI log echoes | Repo URLs embedding credentials, printed env values |
| Shared machines / multi-user hosts | Any of the above readable by other local users |
Why git-credential is a uniquely sensitive seam
The credential-helper protocol is elegant: Git asks a helper for a username/password for a host, and the helper answers. But the protocol’s assumptions are 2005-shaped. It passes secrets as argv and stdout, which means they transit process listings and pipe buffers; it treats local disk as a safe cache, which the stealer-log economy has falsified; and it predates token scope discipline — a single overpowered PAT in .git-credentials can mint commits, read private repos, and sometimes trigger workflows. Modern platform advice (GitHub’s own) pushes short-lived, scoped OAuth via git-credential-manager or the OS keyring-backed helpers, precisely because the blast radius of one leaked static credential is org-scale. The 2023 advisory’s value was forcing teams to inventory which helpers their developers actually ran — where the answer was too often “store, because it was in a Stack Overflow answer from 2014.”
Timeline
| Date | Event |
|---|---|
| 2023-01 (late) | Git project warning published on credential-helper hygiene: store-helper plaintext, world-readable files, verbose logging of OATH codes |
| 2023-01 → 02 | Coverage across developer media; GitHub/GitLab docs on scoped tokens and credential-manager guidance re-circulated |
| 2023 H1 | Repo-hygiene scanning tools add checks for .git-credentials in home-dir audits and pre-commit hooks for embedded secrets |
| 2023 → 2026 | Platform shift accelerates: fine-grained PATs, short-lived OIDC tokens in CI, OS-keyring-backed helpers become default guidance |
Developer-machine hardening checklist
- Ban the “store” helper. Use git-credential-manager or libsecret (OS keyring) so secrets live in locked stores, not dotfiles.
- Prefer short-lived, scoped tokens. Fine-grained PATs or OIDC-derived CI tokens limit what a theft is worth; org SSO policies enforce expiry.
- Kill secret-bearing verbose logs. Enable trace flags only in disposable shells; scrub transcripts before pasting; treat CI logs as public until scanned.
- Hunt for committed credentials. Secret-scanning on push (platform-native) plus periodic history audits catches the .git-credentials that accidentally landed in a repo.
- Assume the endpoint is the perimeter. Stealer logs pivot on exactly these caches; EDR, disk encryption, and screen-lock discipline are the actual mitigations.
Why it still matters in 2026
The 2023 advisory aged into the foundation of developer-endpoint security as its own discipline: the modern stack — OS-keyring credential helpers, OIDC-based CI auth (no stored secrets at all), fine-grained token scoping, push-time secret scanning — exists because “plaintext in the home directory” stopped being acceptable when infostealers industrialized the harvest. In 2026’s AI-assisted coding era the same seam reappears richer: agent configs hold registry tokens, cloud creds, and API keys for autonomous use, and the question Git’s warning posed returns verbatim — who can read what your tools cached, and how long does it live? The answer is still the same command away: audit your helpers today.
Is Git itself “vulnerable” here?
Not by CVE definition — the January 2023 item was an advisory about risky configurations and ecosystem hygiene, not a flaw in Git’s code with a patch number. The “store” helper is documented plaintext-by-design; the risk is choosing it. That’s why the fix shipped as guidance and tooling (better defaults, docs, scanning) rather than a release.
What about SSH keys instead of HTTPS tokens?
SSH keys avoid the argv/stdout seam but concentrate risk in ~/.ssh — protected by file permissions, not encryption, unless you add passphrases or hardware tokens (FIDO2/age-style). The platform answer in 2026 is heterogeneity: keys on hardware for humans, short-lived tokens for machines, and nothing long-lived in a dotfile either way.
How do I check if I’m exposed right now?
Three commands tell most of it: git config --show-origin --get-all credential.helper (what helpers run and from which config), ls -l ~/.git-credentials (does a plaintext store exist, and its permissions), and a grep of recent CI logs for token-shaped strings. If the first answer is “store,” fix it before reading the rest of this article.
Part of the hmmnm.com security-timeline series — one event per month, 2021–2024, indexed here.
