DEV Community

Ramdai Bista
Ramdai Bista

Posted on Originally published at stupidllm.com

Aider Hands Your Model-Provider API Key to Every Test, Lint, and Git Command It Runs

If you set OPENAI_API_KEY so Aider can talk to the model, that same variable is also visible to every test runner, lint command, and git subprocess Aider shells out to on your behalf. A GitHub issue says that's not a hardening gap — it's the current, unmodified behavior.

What the source says

GitHub issue #5658, filed against Aider-AI/aider, traces the leak to two specific code paths against commit 5dc9490bb35f9729ef2c95d00a19ccd30c26339c. run_cmd_subprocess() in aider/run_cmd.py — used by /run, /test, and configured lint commands — calls subprocess.Popen() without a restricted env argument, so those commands inherit Aider's entire process environment. Aider's /git handling does the same thing more explicitly, building env = dict(subprocess.os.environ) and passing the unmodified copy straight to the git subprocess.

The reporter (younaman) demonstrated it directly: set OPENAI_API_KEY=aider-provider-sentinel, then run /run test -n "$OPENAI_API_KEY" && echo OPENAI_API_KEY_PRESENT inside an Aider session. The credential shows up in the child process. As of publication, the issue has no visible maintainer response.

What it doesn't establish

This is one reporter's filing, not a confirmed real-world exfiltration. Nothing in the issue claims anyone's key was actually stolen this way — the risk is conditional: a test suite, lint config, or git hook has to be controlled by an attacker (a malicious dependency, a poisoned repository) before there's anything to exfiltrate to. That's a real and already-common way untrusted code runs with a user's authority, but it's a precondition, not a proof of exploitation.

Why it's still worth logging

Model-provider credentials and the commands Aider shells out to serve different purposes, and the second category has no legitimate need for the first. A test runner, a linter, and git don't need to see the key Aider uses to talk to its LLM API — but right now they all can, by default, with no restricted environment involved. That turns "run untrusted repository content" — already a routine part of using a coding agent on someone else's code — into a second, separately monetizable payoff for whoever controls that content: a valid API key billable under the victim's own account. Two distinct code paths, one cited commit, one reproducible command. No fix yet.

Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0120/

Top comments (0)