Aider asks before running a shell command the model suggests — unless stdin happens to be closed, in which case it just... runs it. No prompt answer needed, no -y flag required. A security researcher found the gap and filed exact reproduction steps.
What the source says
Per the GitHub issue (filed 2026-11-06 against aider-chat up to v0.86.2): Aider's confirm_ask() helper in aider/io.py catches EOFError — raised when stdin is closed, redirected from empty input, or the session has simply ended — and treats it as if the user had accepted the prompt's default answer, which is "y". That happens even when the caller passed explicit_yes_required=True, the flag Aider's own shell-command gate sets specifically to demand a real answer. handle_shell_commands() in aider/coders/base_coder.py, the function that stands between a model's suggested command and your shell, never overrides that default to "n" first.
The reporter's PoC makes it concrete: point Aider at a local OpenAI-compatible server that always returns a bash block running touch /tmp/aider-poc-marker. Pipe explicit n answers in, and the command is correctly blocked — the confirmation works as designed. Run the exact same invocation with stdin closed (</dev/null) instead, and Aider prints [Yes], executes touch /tmp/aider-poc-marker && echo ran, and exits 0 — with zero characters ever typed. The same default-to-yes path also governs Aider's prompts for editing files outside the chat and creating new ones.
A fix (PR #5957) is open but unmerged, and the issue carries no maintainer confirmation as of publication.
What it doesn't establish
This isn't a report of real-world exploitation — nobody has shown a case where a poisoned file or fetched page got a model to actually suggest a destructive command through this path in production. It's a demonstrated flaw in the confirmation mechanism itself, not a confirmed breach. There's also no vendor acknowledgment yet; the fix PR hasn't been reviewed or merged.
Why it matters anyway
The exploit chain needs one more ingredient Aider can't control — something getting the model to propose a harmful command in the first place (a crafted repo file, a scraped page, a compromised dependency's README). But the bug removes the one step that was supposed to catch that before it runs, on any non-interactive Aider invocation — CI, scripts, piped input — that doesn't explicitly set --yes-always. If you run Aider outside an interactive terminal, that's worth checking today, not after the PR merges.
Scored 8/10 (high) on severity: broad scope (any non-interactive run is affected), fully recoverable once patched, not yet realized as a real exploit, limited direct impact absent that second ingredient. Full scoring and source: https://www.stupidllm.com/incident/STUPID-2026-0160/
Top comments (0)