Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label AI Coding Agents. Show all posts

Researchers Escape OpenAI Codex Sandbox to Run Commands on Host


In OpenAI Codex, security researchers have identified two sandbox escape vulnerabilities, one of which allows developers to execute commands on their machine without prompting them. The vulnerabilities, Heapjack and Overpatch, affect different parts of the coding agent's security boundary. 

The vulnerability was reported to OpenAI by Accomplish AI on August 12. According to the researcher, Codex fixed both issues within eight days. The more serious Heapjack vulnerability demonstrated that malicious code could move beyond the restrictions imposed by Codex's sandbox, even when the agent was running as a read-only application. 

Heapjack Breaks the Sandbox Boundary

The node_repl component installed with Codex Desktop is targeted by heapjack. Although both OpenAI and untrusted agent code are run in separate JavaScript contexts, both operate within the same Node.js process and share the same memory heap, the separation was not sufficiently effective in preventing a security token from coming into contact with an untrusted environment. 

By inspecting the process heap, it was possible to obtain the token generated for the trusted context that remained in shared memory. When the token was obtained, the untrusted code could interact with a native parent process outside the sandbox using the communication channel used by the trusted context. As part of the demonstration of the technique, the researchers launched an application outside of Codex's process tree by utilizing the open command. 

A Unix socket as well as other system-level interfaces could also be reached through this access. This demonstration was especially important since it occurred while Codex was running in a strict read-only sandbox mode, where the agent was not expected to have any writing access to the wider system. 

The attack could be triggered by a seemingly routine development process. The researchers demonstrated a scenario in which malicious content contained in a repository, created by a third party, could exploit the vulnerability after the repository was opened in Codex and a query about its code was made. 

Overpatch Expands Write Access

Second, a vulnerability known as Overpatch affects the open-source Codex command line utility, and it takes an alternative route outside the sandbox. The vulnerability affects the application_patch tool used by Codex to modify files. 

In workspace-write mode, Codex is intended to limit file changes to the project directory. Researchers discovered that apply_patch, instead of expanding write permissions, could expand them based on paths included in patches. By using a path such as /tmp, the tool was able to treat the root of the file system as an accessible parent directory. In addition to the permission extension, researchers modified .zshrc by creating a symbolic link to the user's home directory so that it would be modified as well.

A successful write was not required for the /tmp entry; its presence extended the permissions granted to the patch operation. A modified shell configuration resulted in a file modification outside of the permitted workspace without an approval prompt. When a new terminal session was launched, attacker-controlled content ran. 

Two Flaws, One Security Boundary Problem

It is important to note that though Heapjack and Overpatch affect different parts of the Codex, both expose weaknesses in the way in which the security boundary of the agent was enforced. In the case of Overpatch, the tool responsible for applying changes also determined the scope from which it had access to data. 

In heapjack, trust boundaries were similarly compromised, as the token separating trusted and untrusted execution remained accessible in the same Node.js process and memory space as the untrusted code. The findings suggest that AI coding agents can be restricted in other ways than just controlling their abilities to execute commands. 

Untrusted agent activity must also be prevented from influencing the mechanisms that enforce those restrictions by the tools, processes and interfaces surrounding the model. On August 12, 2026, OpenAI was notified of the issues, and they were both addressed within eight days by Accomplish, who stated that Overpatch was addressed in Codex CLI 0.149.0, while Heapjack had been addressed in Codex Desktop build 26.818.21641.

A later statement by OpenAI confirmed that both issues had been resolved in August, and that additional measures were being taken to strengthen file-write controls and expand sandbox testing across platforms. These findings emphasize the security challenges associated with maintaining strong isolation in AI coding environments. Codex Desktop and Codex CLI have been updated to address both vulnerabilities.

Plugin4Shell: The Zero-Click Flaw That Broke Every Prominent AI Coding Agent at Once



The security promise was simple. A plugin marketplace reviews a piece of code, locks it to a specific, verified version, and every AI coding agent that installs it gets exactly what was reviewed. No surprises or swaps. That promise just got broken, simultaneously, across every major AI coding agent on the market.

On September 17, cybersecurity startup AIR Security publicly disclosed Plugin4Shell, a zero-click, high-severity remote code execution vulnerability affecting Anthropic's Claude Code, OpenAI's Codex, Microsoft's GitHub Copilot, and Google's Gemini CLI. The name is a deliberate echo of Log4Shell, the 2021 Apache flaw that shook enterprise security teams for months. This one hits a faster-moving target: the plugin ecosystems that have quietly become critical infrastructure for millions of software developers.

The researchers who found it, Or Nevo, Dor Granat, and Niv Hoffman, describe it as the first supply-chain vulnerability of the AI agent ecosystem. That is not a small claim, and the technical details back it up.


How the Attack Works

To understand Plugin4Shell, you need to understand SHA pinning, the mechanism it breaks. When a marketplace approves a plugin, it records a cryptographic commit hash, a 40-character string that uniquely identifies an exact snapshot of the plugin's code. From that point forward, every agent that installs the plugin is supposed to check out precisely that commit. Reviewed code, nothing else, forever.

The vulnerability is a single missing verification step. Affected agents fetch the pinned commit during installation but never confirm that the code they actually land on matches it. That gap opens the door to a Git reference resolution trick.

For Claude Code, Codex, and GitHub Copilot, an attacker who controls a plugin repository can create a branch whose name is the exact 40-character pinned commit hash, set it as the repository's default branch, and point it at malicious code. When the agent runs its checkout, Git resolves the branch name instead of the commit object, because Git prefers a matching reference when the name is ambiguous. The agent installs attacker-controlled code, reports a clean install at the trusted hash, and nothing looks wrong.

Gemini CLI has a slightly different variant. Its installer fetches the target commit and then checks out FETCH_HEAD, but if the repository's default branch is itself named FETCH_HEAD, that checkout resolves to the branch instead. The fetched commit gets silently discarded.

What makes this zero-click is auto-update. Claude Code and Codex update installed plugins in the background by default. When a plugin's pinned commit is swapped upstream, an already-installed, already-trusted plugin gets silently replaced with a malicious version. No prompt. No reinstall. Nothing for the user to notice or decline.

Plugins run with the permissions of the developer operating the agent. That means an attacker who succeeds here lands in the developer's machine with access to source code, cloud credentials, SSH keys, internal repositories, and production systems.


The Context Makes It Worse

Plugin4Shell is the third installment in a series of findings from AIR Security, each one showing a different layer of the AI plugin ecosystem collapsing under scrutiny.

In earlier research called "The Story of Skills," the team published a malicious skill to a trusted marketplace and watched it spread to over 26,000 agents. In SkillJacking, they found 925 skills already in active use had been quietly hijacked from their original maintainers, affecting 134,000 agents, by taking over the repositories behind them.

The industry's answer to SkillJacking was SHA pinning. Plugin4Shell is the answer to that answer. The takeovers AIR demonstrated in SkillJacking can now be combined with Plugin4Shell to bypass the exact safeguard that was supposed to contain them. The chain is proven end to end.


Vendor Responses

AIR found the vulnerability in May 2026, built working proof-of-concept exploits against all four agents, and disclosed everything to the vendors in June. What happened next drew a clear line between the companies that acted and the ones that did not.

Anthropic patched Claude Code in version 2.1.179. OpenAI patched Codex in version 0.146.0. Both confirmed fixes after disclosure.

Microsoft has not shipped a fix for GitHub Copilot. GitHub has argued that its platform blocks branch and tag names that resemble commit hashes, which limits the attack surface for GitHub-hosted plugins. AIR's counter is that Copilot also supports marketplaces hosted on Bitbucket and self-hosted git servers, which permit such names, and that GitHub's restriction does nothing for those configurations. The two positions describe different scopes. Copilot users currently have no patch.

Google's response was to deprecate Gemini CLI entirely. The company confirmed in August that no fix would ship, directing users to migrate to an alternative product called Antigravity. Every existing Gemini CLI installation remains permanently vulnerable.


What Users Should Do Now

The fix, technically, is a single line of verification that every affected agent was missing: after checkout, compare the actual HEAD commit against the pinned hash and abort if they do not match. Because the check runs inside the agent rather than at the marketplace, no marketplace can enforce this guarantee on its own. Only an agent-side fix closes it.

Claude Code users should update to version 2.1.179 or later. Codex users should update to version 0.146.0 or later. Gemini CLI users should migrate away from the product. GitHub Copilot users have no patch available and no confirmed timeline for one.

For enterprise teams that have built internal vetting processes around SHA pinning, Plugin4Shell is a harder problem. The review passed. The pin was written. Different code got installed. Every downstream security process built on that guarantee inherits the failure.

The most striking detail in AIR's disclosure is not the vulnerability itself. It is that four independent engineering teams at four separate companies all made the same mistake, building the same flawed assumption into their auto-update pipelines, and none of them caught it until an outside lab did. That is not an implementation error in one product. That is a design assumption the entire industry shared, and nobody questioned it.

1 Folder Was All It Took: Security Researchers Find AI Coding Agents Can Be Hijacked Before a Single Prompt Is Typed




Opening a folder should not be a security event. For users of at least seven popular AI coding agents, until recently, it could be one. A newly documented set of vulnerabilities, tracked under the name GitSpawn, shows that pointing an AI coding assistant at a project folder was enough to hand an attacker code execution on the developer's own machine. No prompt had to be typed. No permission dialog had to be clicked. In some cases, the user had not even logged in yet.

The affected tools include Anthropic's Claude Code, OpenAI's Codex, Cursor, Block's Goose, Nous Research's Hermes Agent, Alibaba's Qwen Code, and xAI's Grok Build. These products sit on an enormous number of developer machines. Claude Code's npm package sees more than 77 million downloads a month. The tools examined most closely in the disclosure carry a combined GitHub following approaching half a million stars. This flaw reached deep into the software supply chain.


What actually happens when you open a folder

An AI coding agent needs context the moment it launches inside a project: what branch is checked out, which files changed, what the codebase looks like. The fastest way to get that information is to ask git, the version control system nearly every software project runs on. So these agents run background commands like `git status` or `git diff` as soon as a folder opens, often before the assistant has said anything to the user.

That part is normal. The danger sits in a git feature called `core.fsmonitor`, a performance setting built to let large repositories speed up status checks by handing file-change detection to an external helper program instead of scanning every file each time. Git learns which helper to run by reading the repository's own configuration file, `.git/config`. That file ships with the project. It does not live on the user's machine.

Anyone who builds a repository controls that file, which means anyone who builds a repository can set `core.fsmonitor` to run whatever command they want. Nearly every git command that touches a project's working files triggers something called an index refresh, and that refresh is what reads the setting and runs it. So the moment an AI coding agent runs an ordinary git command inside a booby-trapped folder, git executes the attacker's command on the developer's machine, under the developer's own account. Because the agent's own code is making that subprocess call rather than something routed through its interface, none of the approval prompts or sandboxing built into these tools ever sees it happen.

There is a limit worth knowing. A standard `git clone`, `fetch`, or `pull` will not trigger this, because those operations do not carry the repository's local configuration along with them. The malicious repository has to reach a victim as a set of files with its `.git` directory already inside: a zipped folder sent over email, a shared drive, a synced folder, a USB stick passed at a meeting. Developers, contractors, and consultants hand off projects this way constantly, which is what makes the delivery method plausible.


Which vendors fixed it, and which did not

Eight distinct findings were reported privately across the seven agents before this went public. Four of them were still unpatched at the time of publication.

Goose, maintained by Block, shipped a fix in version 1.44.0. The issue was catalogued as CVE-2026-72718, with a severity score of 7.0. Cursor and OpenAI's Codex both carried variants of the same flaw and have since patched them, though in both cases the vulnerability had already reached the vendors through other researchers' independent reports. Anthropic fixed the core.fsmonitor path in Claude Code with version 2.1.196. A second issue in the same product, tied to the `claude ultrareview` command and a different git configuration key, was still working as of version 2.1.252 at publication time. That configuration key has not been made public while the issue stays open, so as not to hand out a working template.

Two vendors had shipped nothing. Alibaba's security response center accepted the report on Qwen Code but had not resolved it by publication. xAI's Grok Build remained vulnerable through version 1.0.13; an earlier, related report had been closed by the company as merely informative before this disclosure connected it to the same bug. Hermes Agent's maintainers never triaged the report despite six separate contact attempts across five channels. The flaw was eventually assigned CVE-2026-71963 by VulnCheck, an independent numbering authority that can step in when a vendor stays silent.


This bug has been seen before

The shape of GitSpawn is not new to anyone who has followed git security for a while. Independent researcher Justin Steven documented abuse of the fsmonitor hook back in 2022. Visual Studio Code built its workspace trust model in 2021 to stop untrusted folders from running code the second they were opened in an editor. AI coding agents brought a version of that same exposure back by running git commands in the background before any of those trust protections had a chance to apply.

That is the part worth sitting with. Nothing about how these models reason or respond caused this. The exploit runs entirely in ordinary software plumbing, the subprocess call an agent makes to figure out where it is, firing before any of the safeguards a user assumes are in place actually engage.


What to do about it

If you receive a project as raw files rather than through a direct git clone, whether by email, shared drive, or a USB stick, check `.git/config` before opening it in an AI coding agent or any development tool. Anything in that file that names an external program to run deserves a second look.

If you build one of these tools, the fix is narrow: disable risky configuration keys like `core.fsmonitor` on every background git call, for example by running commands with the flag `-c core.fsmonitor=false` instead of trusting whatever the repository hands you.

AI coding agents keep taking on components they did not write and did not choose: plugins, extensions, connections to outside services, most of which arrive as files carrying their own settings and get trusted the moment they load. GitSpawn shows what happens when that trust runs ahead of the checks meant to govern it. The next version of this bug probably will not look like a git command at all.

AI Agents Built to Detect Malware Can Be Manipulated Into Running It


 

AI agents capable of identifying malicious software can be manipulated by the AI Now Institute to execute it, according to new research. The proof-of-concept attack, known as "Friendly Fire," demonstrates that autonomous AI coding agents, such as Claude Code from Anthropic and Codex from OpenAI, can be deceived into running malicious code while performing open-source security reviews. 

AI agents can approve and execute commands independently of the user without requiring user confirmation for every action, which is what this attack targets. Researchers contend that the vulnerability does not lie in the software version used by these agents, but rather in the way they interpret and react to instructions embedded within untrusted repositories rather than exploiting a software vulnerability. 

A comparison with conventional supply-chain attacks that hide malicious code within a repository was made by the researchers, who noted that when static analysis and manual review are performed, the repository itself can appear to be completely free of malicious code. By introducing the malicious payload at execution time, the AI agent follows embedded instructions, so traditional security tools cannot detect this technique.

By adding a seemingly harmless README.md instruction to an open-source project that recommended running a script entitled security.sh before submitting a pull request, attackers modified it. By launching a malicious binary hidden within a legitimate compiled Go file, the script silently executed on the host computer without triggering security warnings or approval prompts, allowing the malicious binary to execute on the system. 

According to the researchers, the attack is successful because the AI agent recognizes the instructions as a legitimate step in the process of installing software rather than an attempt to exploit the system maliciously. Once the recommended script has been executed, the payload will run under the same permissions that were provided for the developer or AI agent, potentially exposing credentials, environment variables, and other sensitive information. 

The procedure differs from previous prompt injection attacks, which relied on configuration files and often generated trust warnings, as this technique hides instructions inside standard documentation that is regularly read by developers and AI agents. It has been reported that both Claude Code and OpenAI Codex followed the embedded instructions during testing, while newer AI models executed the disguised binary upon detecting differences between the source file and the compiled executable. 

A laboratory proof-of-concept has been demonstrated, with no evidence of active exploitation in the field. In addition to excluding the malicious payload, the publicly released demonstration code does not attempt privilege escalation or lateral movement. These findings indicate that autonomous AI agents pose a greater challenge in terms of design rather than a problem that can be resolved by simply updating software. 

It is becoming more common for organizations to employ AI-powered coding assistants to review third-party software. Researchers recommend treating AI coding agents as privileged software, rather than simply assistants. Autonomous agents should not be permitted to execute commands on untrusted repositories, least-privilege access policies should be enforced, AI workflows should be isolated in sandboxed environments, and human approval should be required before running scripts or binaries recommended by project documentation. 

In accordance with the researchers, the issue is not related to any particular AI model, but a broader trust problem affecting autonomous coding assistants capable of executing shell commands. In addition to creating new attack surfaces if they are unable to reliably distinguish legitimate instructions from content controlled by the attacker, AI agents are becoming increasingly capable of cloning repositories, installing dependencies, and resolving setup issues independently. 

As autonomous AI systems are increasingly adopted in the software development and cybersecurity sectors, prompt injection attacks remain a major security threat. This study adds to a growing body of evidence that prompt injection attacks remain one of the greatest security risks. In light of the increasing autonomy of AI agents, organizations must balance automation and strong oversight in order to balance automation and security workflows. 

AI-driven attack techniques cannot be effectively countered until artificial intelligence (AI) systems can reliably discriminate between trusted and malicious instructions. Human verification and secure execution environments will therefore remain critical safeguards.