CVE-2026-85674 in Aider
Summary
by MITRE • 09/04/2026
aider (aider-chat) automatically loads a .aider.conf.yml configuration file from the root of the git repository it is launched in. A crafted repository can set test-cmd (executed at startup) or lint-cmd (executed on the first file edit), which aider runs through a shell (subprocess with shell=True) without any user confirmation, LLM interaction, or API key. Consequently, a user who clones and runs aider inside an attacker-supplied repository achieves arbitrary command execution on their machine. The behavior is long-standing and was confirmed on 0.86.3.dev (current main).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the aider tool represents a critical security flaw rooted in insecure configuration file handling and improper shell invocation practices. Aider, an AI-powered coding assistant, automatically loads a .aider.conf.yml configuration file located at the root of any git repository where it is launched. This automatic loading mechanism lacks sufficient validation or user consent mechanisms for potentially dangerous commands defined within this configuration file. Specifically, two parameters in the YAML file, test-cmd and lint-cmd, are executed via subprocess calls with shell=True enabled without requiring explicit user confirmation, interaction with a Large Language Model, or authentication through an API key. This design choice creates a significant attack vector where malicious actors can exploit unsuspecting users by embedding harmful commands within these configuration fields.
From a technical perspective, the core issue lies in the combination of automatic execution and shell interpretation. When subprocess is invoked with shell=True, it passes the command string to the system's default shell for parsing and execution. This allows an attacker to inject arbitrary shell metacharacters such as semicolons, pipes, or backticks into the test-cmd or lint-cmd fields within a crafted .aider.conf.yml file. Upon cloning this malicious repository and launching aider inside it, the tool will immediately execute these commands during startup (for test-cmd) or upon the first file edit (for lint-cmd). Since there is no sandboxing, privilege restriction, or user prompt involved, the executed code runs with the same permissions as the user running the application. This effectively results in arbitrary command execution on the victim's machine, allowing for data exfiltration, system compromise, installation of malware, or other malicious activities depending on what commands are embedded by the attacker.
The operational impact of this vulnerability is severe due to its ease of exploitation and lack of mitigation controls. An attacker only needs to distribute a repository containing the poisoned .aider.conf.yml file through common channels such as GitHub pull requests, code sharing platforms, or social engineering tactics that encourage cloning specific repositories for development purposes. Because many developers frequently clone external repositories to test contributions or explore new projects, this vulnerability can be triggered inadvertently by any developer who runs aider in the context of a malicious repository. The long-standing nature of this flaw indicates it has likely affected numerous users over time without widespread detection because the execution happens silently and automatically. There is no visual indicator that commands are being executed from configuration files, making forensic analysis difficult after an incident occurs.
This vulnerability aligns with several well-known industry standards for software security flaws. It corresponds to CWE-78 Improper Neutralization of Special Elements used in an OS Command commonly known as OS Command Injection. The failure to validate or sanitize input derived from a configuration file before passing it to the operating system shell is a classic example of this weakness. Additionally, under the MITRE ATT&CK framework, this behavior maps to T1059 Command and Scripting Interpreter, specifically leveraging automatic execution mechanisms that bypass user interaction. It also reflects CWE-20 Improper Input Validation since the application fails to restrict or validate commands sourced from external configuration files before execution.
Mitigation strategies must address both immediate remediation and long-term architectural changes. The most effective short-term solution is for users to avoid running aider in repositories obtained from untrusted sources until a patched version is available. Developers should manually inspect .aider.conf.yml files in any cloned repository before launching the tool, ensuring no suspicious commands are present in test-cmd or lint-cmd fields. For long-term resolution, the developers of aider must implement strict validation rules for configuration parameters to prevent shell metacharacters from being interpreted as executable code. Alternatively, they should remove the use of shell=True and instead pass command arguments directly to subprocess using a list format, which prevents shell injection attacks entirely. Implementing explicit user confirmation prompts before executing any commands defined in configuration files would also significantly reduce risk by ensuring users are aware when external scripts or commands are being run.