- January 14, 2026 → Pillar Security blog — Pillar Security disclosed CVE-2026-22708 in Cursor
- January 2026 → GitHub advisory GHSA-82wg-qcm4-fp2w — Cursor patched the flaw in version 2.3
- July 2026 → Docker blog — Pillar published a series of sandbox escapes across coding agents
A developer approves git branch. It is one of the most ordinary commands in the toolbox, the kind you stop reading after the first word. On January 14, 2026 Pillar Security blog, Pillar Security showed what that approval can conceal: in Cursor, a poisoned environment could make a harmless command run the attacker’s code.
The flaw, CVE-2026-22708, lived in how Cursor’s agent handled shell built-ins. In Auto-Run Mode with an allowlist enabled, built-ins like export, typeset, and declare slipped through without appearing on the list and without asking for permission GitHub advisory GHSA-82wg-qcm4-fp2w. They are not programs on disk, so the checker never saw them.
The command that wasn’t what it looked like
The attack was quiet. A file the agent was told to read — a README, a dependency, an issue comment — carried an instruction meant for the model, not the human. That instruction set an environment variable nobody notices. Git reads one called PAGER to decide how to show its output; poison it, and the next git branch you approve runs the attacker’s program instead of a branch list Docker blog.
Pillar Security researcher Dan Lisichkin argued the industry should “deprecate allowlists altogether” and move agents into isolated environments Pillar Security blog. Pillar’s researchers noted that “the name of a command does not tell you what that command will do,” and that the trick worked even with a completely empty allowlist.
Cursor rated the issue High and patched it in version 2.3 during January 2026 GitHub advisory GHSA-82wg-qcm4-fp2w.
Why an allowlist was never the right wall
The deeper problem is not shell built-ins. It is a control that studies the command while someone rearranges the furniture around it. Allowlists cut interruptions, but they validate what runs while ignoring the poisoned context it runs in.
Docker Sandboxes run agents in microVMs with their own kernel, filesystem, and deny-by-default network Docker blog, and Docker has extended that model to embedded work by pairing sandboxes with ESP32 firmware builds Docker pairs ESP32 firmware builds with AI agent sandboxes.
The boundary that actually holds
The sandbox does not stop the injection. Inside the box the agent can still run sudo, and the same payload fires. But your home directory sits on the other side of the boundary, so there is no ~/.ssh/id_rsa to copy. Data leaves only through a proxy that checks every request, and UDP and ICMP are blocked.
Isolation has seams. In July 2026 Docker blog, Pillar published sandbox escapes across four coding agents, where the flaw was a file written inside one box that a tool outside later trusted. Docker’s own caveats follow that shape: a poisoned Git hook will not show up in git diff, and a shared skills store can pass a modified skill to the next sandbox.
The trick Cursor patched was specific. The habit of trusting an approved command is not. Until the wall sits between the agent and your SSH keys — not between the agent and its prompt — a harmless git branch will keep meaning whatever the last file it read decided it should.
