Aider's new CVE runs through shell=True lines Aider wrote itself

On October 23, VulnCheck published CVE-2026-115726 (opens in a new tab) against Aider, the open-source terminal coding agent (about 49,700 GitHub stars). It is rated 8.5 High on CVSS 4.0 and affects every version through 0.86.2, the latest release. Researcher Seoyoung Lee is credited with the find. The report went up as a public GitHub issue, #5885 (opens in a new tab), on October 20. As of Sunday afternoon it is still open, with no comments, no assignee and no linked fix.

How it works. Aider reads a file called .aider.conf.yml from your current folder, the git repository root and your home folder, and every command-line flag is also a valid key in that file. There is no trust prompt. Two of those keys hold commands. notifications-command is run through subprocess.run(..., shell=True) after the model replies, so once a malicious repo also sets notifications: true, the command fires on your next prompt and every turn after that. editor is passed to subprocess.call(..., shell=True) when you type /editor. Neither goes through the confirmation step Aider uses for shell commands the model suggests. Clone the wrong repo, start Aider, send one message: the repo's command runs as you.

Who wrote those lines. We read Aider's git history at the v0.86.2 tag. Aider's own docs (opens in a new tab) say that when Aider authors a change, "(aider)" is appended to the git author name. git blame on both sinks:

• The notifications-command feature landed in commit 65e059a7, "feat: Add notifications-command option to run custom notification commands," March 6, 2025, authored by "Paul Gauthier (aider)." The subprocess.run(..., shell=True) lines blame to the same author, same day. It shipped in v0.76.0, whose release notes say "Aider wrote 85% of the code in this release."
• The editor's subprocess.call(command_str, shell=True) line comes from commit 3714d554, February 24, 2025, also authored by "Paul Gauthier (aider)." It replaced a line carrying a human comment: # why does adding shell=True launch the editor without the filepath? ai?

To be fair about that second one: Aider's version quoted each part of the editor command with shlex.quote. About an hour later, a commit by Paul Gauthier, without the "(aider)" tag, simplified the function and dropped the quoting, so the configured value now goes to the shell as is. Human and agent each did half of it.

Our take

shell=True on a command the user typed is the feature, not the bug. Letting people run their own notification script is reasonable. The bug is that the same value can come from a file inside a repository someone else wrote, and nothing in the code, the commit or the review asked where the string comes from.

That's the kind of question a coding agent rarely asks, because the answer isn't in the diff. The commit did what its message says: it made notifications configurable. Whether the config file is trusted input was decided somewhere else, in how Aider loads its settings. When an agent writes most of a release, one feature request at a time, trust boundaries are the part nobody is asked to look at.

The other half is maintenance. Aider's last commit to its main branch was May 22, 2026, and its last release was February 12. A coding agent that runs inside strangers' repositories now has a public, unpatched command-execution bug and no visible response.

What to do

• Before starting Aider in a repo you didn't write, open .aider.conf.yml at its root and check notifications-command and editor. Delete the file or those keys if you don't trust them.
• Run coding agents on untrusted code in a container or VM, not on the machine that holds your keys.
• If you build an agent: treat any config that ships inside a repo as untrusted input, and ask before honoring keys that run commands.
• Watch issue #5885 (opens in a new tab) for a fix.

We read the CVE record, the GitHub issue and Aider's source and git history at v0.86.2. We did not run the exploit ourselves.