Cursorの脆弱性で承認したコマンドから任意コード実行、修正済み

"Anything that could get text in front of the agent, a README or a dependency or an issue comment, could use them to change environment variables silently. A command the developer then approved, something as ordinary as git branch, would run the attacker’s code instead."／"The commands that change them are shell built-ins, and Pillar’s research names export, typeset and declare specifically, a detail reported independently at disclosure. Built-ins are not programs sitting on disk, and the checker was looking for programs on disk, so they went through without ever being surfaced."／"The developer was shown an accurate prompt, approved a command that was genuinely harmless, and got arbitrary code execution anyway, because the meaning of that command had been changed a minute earlier by something they were never shown."／"Git looked up PAGER to work out how to show the branch list, found the attacker’s command sitting in it, and ran that instead."（Today’s Horror Story／The Problem 節）— Docker 公式ブログより

"But the name of a command does not tell you what that command will do. The check reads the name, waves it through, and the setting that decides what actually happens was changed a minute earlier by something the check was never shown."／"Cursor’s documentation now describes the allowlist as best-effort and warns that bypasses are possible. Pillar went further and argued that agents should be handed full command execution inside an isolated environment, and that the industry ought to deprecate allowlists altogether."（The Problem 節）— Docker 公式ブログより

"Pillar’s write-up points back to Elttam’s 2020 research on environment variables, which showed how these settings could be turned into code execution."／"It sat there for six years without troubling anybody very much. Pulling it off meant already being on someone’s machine, setting several things in the right order, running each step yourself, and anyone with that much access had faster ways to cause damage."／"Then coding agents arrived and removed every one of those obstacles at once. They act on instructions found in files they were told to read, they run several steps in a row without stopping to check, and they run as you. A technique that used to need somebody sitting at your keyboard now arrives in a repository you cloned this morning."／"It is the same shape as the s1ngularity attack from Part 4. There, a poisoned package borrowed an agent that was already logged in. Here, poisoned text borrows a command that was already approved. Neither one breaks anything. Both of them use permission that was handed over deliberately, for something nobody intended."／"The full chain in Pillar’s research ends with the victim’s SSH private keys leaving the machine."／"No memory bug. No privilege escalation. Nothing in any log that looks the slightest bit out of place."／"One writes extra lines into ~/.zshrc, so the code runs again every time you open a terminal. You could finish the project, delete the repository, and still be running it next month."（The Scale of the Problem 節／The Impact 節／Technical Breakdown: How the Attack Works の 2. The half you approve 節）— Docker 公式ブログより

"Cursor rated it High and patched it in version 2.3."／"Pillar reported it in August 2025 and the fix shipped that January. Cursor engaged with the report and made a real change, so anything the parser cannot classify now requires approval, which closes the paths that were demonstrated. Five months is a fair measure of how awkward this is to fix at the layer where it was found rather than a complaint about the vendor."／"The wider problem has not gone anywhere, because it was never really about shell built-ins. It is about a check that studies the command while somebody rearranges the furniture around it."（Today’s Horror Story 節／The Impact 節）— Docker 公式ブログより

"Docker Sandboxes run AI coding agents in isolated microVMs, each with its own kernel, filesystem, and deny-by-default network, so a compromised dependency an agent pulls cannot reach the host, its credentials, or other workloads. Inside that box the agent can run anything, including with sudo, which is exactly what Pillar recommends. There is no allowlist to slip past."／"The injection still lands. The environment gets changed, git branch still triggers it, and the payload runs. Nothing about a sandbox stops that. Then the payload goes looking for your SSH key and does not find one. Your home directory sits on the other side of the boundary, so there is no ~/.ssh/id_rsa inside the box to copy."／"The ~/.zshrc trick fails outright, because that file lives on your host and a poisoned copy written inside the box disappears along with the box."／"Getting data out is harder than people expect. HTTP and HTTPS leave only through a proxy on your host that checks every request against your rules, anything else over TCP needs a rule naming the address and port, and UDP and ICMP are blocked outright."（How Docker Sandboxes Contain This at the Execution Layer 節／上表は What This Looks Like in Practice 節の比較表に対応）— Docker 公式ブログより

"It can still use the key. Sandboxes forwards an SSH agent socket into the box so that ordinary work like git push keeps working, which means code inside can ask that agent to authenticate on its behalf. It cannot take the key anywhere, but it can borrow it for as long as the sandbox runs."／"The first is your workspace, which is live on your host by default, so Git hooks and Makefile targets are still within reach and a poisoned hook will not turn up in git diff. Running with --clone hands the agent its own copy."／"Your network policy is what limits that, since SSH needs a rule naming the exact destination address and port before it connects to anything."／"Supported agents mount the same host-side store read-write unless you opt out at creation time, which is what lets an agent refine a skill and keep it. Every sandbox sharing that store sits inside one trust boundary, so a skill modified inside one becomes an input to the next that loads it. The store is sandbox state though, and a modified skill does not by itself execute on your host, so the risk runs sandbox to sandbox rather than sandbox to host."／"Isolation has its own seams. In July, Pillar published a series of sandbox escapes across four coding agents, and the mechanism was never a broken sandbox but a file written inside one that a tool outside later trusted. Both caveats above are that shape."（How Docker Sandboxes Contain This at the Execution Layer 節）— Docker 公式ブログより

"Treat export like any other command. Anything that changes environment settings can change what your next command does, even when that next command is on your allowlist."／"Do not mistake an allowlist for a boundary. It reduces interruptions. The vendor documentation now says outright that it is best-effort and not a security guarantee."／"Isolate before the first command, not after something looks wrong. Untrusted means anything you did not write and have not read, which covers most of a dependency tree."／"Use --clone for code you have not vetted, and opt out of the shared skills store."／"Remember a forwarded SSH agent is a live credential. The key file staying on your machine is not the same as the key being unusable, so restrict egress for untrusted work."／"Read your own policy. Run sbx policy ls. Deny-by-default with a long allow list is closer to allow-by-default than it looks."／"Cursor is built on VS Code and connects the same way, over Remote – SSH, with the editor staying on your machine while files, terminals and extensions run in the sandbox. You will need Docker Sandboxes 0.37.0 or later, SSH access configured, and Cursor’s Remote – SSH support installed."／"A kit is a declarative YAML artifact that extends a sandbox agent with credentials, network policies, environment variables, startup commands and files."（Best Practices 節／What This Looks Like in Practice 節／Codify the Boundary with Kits 節）— Docker 公式ブログより