> A zero-click RCE flaw in AI coding agents could have exposed enterprise systems

Popular AI coding agents such as OpenAI’s Codex, Anthropic’s Claude Code, Google’s Gemini CLI, and Microsoft-owned GitHub Copilot were vulnerable to a zero-click attack that enabled attackers to execute malicious code, even without developer interaction, by swapping a trusted plugin from an online marketplace for a malicious one, potentially giving them a foothold in enterprise development environments. Researchers at cybersecurity startup AIR found and reported the flaw, which they are calling Plugin4Shell, to the vendors concerned, and most of them have now released a patch for it, the researchers wrote in a blog post on Thursday. It’s “a flaw no marketplace can fix, so users must update their agent,” the researchers wrote How Claude Code, Codex, and GitHub Copilot were exploited Enterprises typically use plugins to extend the capabilities of their AI coding agents, giving the agent access to additional tools, commands, and external services that can help it perform tasks beyond generating or modifying code. When a developer installs a plugin, the agent typically downloads its code from a Git repository and uses a Git commit to determine if it is running an approved copy of the code, one that has been reviewed and cleared by the developer. That check is done with the help of a secure hash algorithm (SHA), a unique cryptographic identifier assigned to each Git commit. Developers can give the agent the SHA of the reviewed commit, telling it to run that specific copy of the plugin. However, Claude Code, Codex, and GitHub Copilot can be tricked into running malicious code instead of the trusted plugin code associated with the SHA because they pass the SHA directly to Git to check out the plugin code but do not subsequently verify that Git has actually checked out the commit corresponding to that SHA, the researchers wrote. That means an attacker who controls the plugin’s repository, either by publishing a benign plugin and later turning it malicious or by taking over the repository behind an existing trusted plugin, can exploit the gap by creating a new version of the repository containing malicious code and using the SHA of the legitimate commit as its name, the researchers explained. As a result, when the agent asks Git to check out the SHA, Git resolve it to the attacker-controlled version, causing the agent to execute the malicious code even though it was instructed to use the reviewed commit, they said. How Plugin4Shell compromised the Gemini CLI The attack works differently in Gemini’s CLI, although the underlying problem of the agent not verifying that Git has checked out the requested commit stays the same. Gemini CLI first uses the SHA to tell Git which legitimate version of the plugin to retrieve. After retrieving it, Gemini CLI tells Git to check out that code using the name “FETCH_HEAD.” An attacker who controls the repository can exploit this by creating a malicious version of the plugin and giving it the same “FETCH_HEAD” name, effectively creating a second version that Git can return when Gemini CLI asks for the code. The vulnerability, which was first discovered in May and disclosed to vendors in June, has since been addressed in some of the affected coding agents. Anthropic fixed the issue in Claude Code version 2.1.179 and OpenAI addressed it in Codex version 0.146.0, the researchers wrote. Google said it has deprecated the Gemini CLI and so will not issue a fix, suggesting instead that users to move to Antigravity. GitHub has not yet release a fix for its Copilot, the researchers said. A representative of GitHub told The Register that it already applied restrictions on creating version or tag names that resemble commit SHAs, preventing the reported vulnerability from being exploited on GitHub or on plugins from its marketplace. However, AIR researchers told the publication that GitHub’s naming restrictions might not be enough to thwart Plugin4Shell attacks because plugin marketplaces can also be hosted on other platforms, such as Bitbucket. Plugin4Shell could widen exposure to enterprise systems That gap, coupled with the likelihood that enterprises running affected coding agents are yet to patch or update them, could leave development environments exposed to attacks through compromised plugins, according to Pareekh Jain, principal analyst at Pareekh Consulting. “Enterprises using AI coding agents with third-party plugins are likely to be most exposed, especially when those agents have access to source code, credentials, cloud systems or CI/CD tools as these plugins mostly run with the same access the developer or employee has,” he said. That means that these malicious plugins could help attackers access source code, steal API keys or cloud credentials, change repositories, or potentially reach CI/CD and other corporate systems, Jain added. What can enterprises do to mitigate risk? “Security teams should examine machines that runs these vulnerable agents. Important warning signs include unusual processes or network connections, unexpected plugin files, changed source repositories, suspicious Git activity and unusual use of developer or cloud credentials,” Jain said. “EDR, Git, CI/CD, cloud IAM and authentication logs are good places to investigate,” he added. Other measures, according to the analyst, includes checking if their coding agents update automatically to ensure they have received the patches from the vendors that applied it.   However, these steps only reduce the risk but doesn’t fix the underlying vulnerability. “The underlying vulnerability is ultimately a vendor responsibility because it stems from how the agents verify the code they are instructed to execute. They need to ensure that the code being executed is actually the code that was reviewed and approved,” Jain said. “Enterprises can put controls around plugin usage, but they cannot fix a flaw in the way the coding agent validates the code it checks out,” he added. This article first appeared on InfoWorld.