You Approved the Right Command. The Agent Executed Something Else.

Most of what gets called an approval bypass in agent security is a story about a check that did not fire. Somebody found a way to skip the prompt. CVE-2026-22708 is a more unsettling variant, and it is worth returning to now that Docker has written it up carefully, because the check did fire, correctly, on the command that actually mattered. The developer saw it. The developer approved it. It ran exactly as written. And it was still not the action they thought they were authorizing.

What Pillar Security found, precisely

Pillar Security's research team, credited to Dan Lisichkin, reported the underlying issue to Cursor privately in 2025, and it was disclosed publicly on 14 January 2026 in GitHub Security Advisory GHSA-82wg-qcm4-fp2w, assigned CVE-2026-22708. We read the advisory directly. It affects Cursor Agent versions 2.2 and earlier, specifically when a workspace runs in Auto-Run Mode with Allowlist mode enabled, a configuration Cursor itself describes as non default rather than what most installations use out of the box. Cursor rates the advisory High severity. It was fixed in version 2.3, and the advisory's own remediation language is narrow and specific: terminal command parsing around edge cases was improved.

The mechanism is the part worth sitting with. Cursor's allowlist was built to check whether a proposed command matched a program the operator had already trusted, and that check worked by looking for an executable on disk. Shell built-ins, export, typeset and declare among them, are not executables on disk. They are interpreted directly by the shell itself. Because the checker was looking for the wrong kind of object, these built-ins ran without ever being evaluated against the allowlist and without triggering an approval prompt, and the advisory states this held even when a workspace's allowlist was completely empty, the most restrictive setting available. An attacker who could get instructions into content the agent later reads, a README, a dependency, an issue comment, through indirect prompt injection, could use exactly this gap. Not to run their payload directly. To set the table for it.

The command that ran was the command that was approved

Docker's account, published 18 August 2026 as the fifth entry in its coding agent security series, works through a version of the exploit chain built around a command almost nobody would hesitate to click yes on: git branch. We read Docker's article directly. Its shape is this. Something the agent reads first contains an instruction to run export, setting the PAGER environment variable to a command of the attacker's choosing. That step needs no approval and shows the developer nothing, for exactly the reason Pillar's research identifies: export is a built-in, and the allowlist was never watching for built-ins in the first place. Later, the agent proposes git branch, an ordinary, safe looking, entirely accurate description of what it is about to do. The developer approves it, because it is git branch, and git branch is what it says on the label. Git then does what git always does on startup: it checks the PAGER environment variable to decide how to display its output, and PAGER is no longer what the developer's shell configuration set it to. It is whatever the attacker's export statement put there.

Nothing about the command the developer approved was false. Its name was accurate. Its arguments were accurate. If you compared the text the approval prompt showed against the text that reached the shell, they would match exactly, character for character. What did not match was the environment those characters were about to execute inside, and the approval step had no visibility into that environment at all. It could not have, because the environment was not part of what was being approved. It was ambient. It was the water the approved command swam in, silently changed by something upstream that the approval prompt was never designed to notice.

The fuller chain Pillar demonstrated

Docker's PAGER example is a minimal, explanatory illustration, chosen because git and its use of PAGER are familiar to almost any developer. Pillar Security's own research demonstrates a fuller chain, and it is worth holding the two apart, because the fuller chain does not depend on git, or on any command a reader would recognize as display related, at all. Multiple independently phrased searches of secondary reporting on Pillar's research converge on the same sequence, though Pillar's own site was not reachable for a direct read in this session: export sets PYTHONWARNINGS to a value crafted so that the next matching warning causes Python's interpreter to import antigravity, a Python standard library easter egg dating to 2008 whose own code calls webbrowser.open to launch a comic in a browser. The webbrowser module decides what counts as a browser by reading the BROWSER environment variable, so a second export, setting BROWSER to perlthanks, a Perl script that ships alongside a standard Perl installation, hands that call to Perl instead of an actual browser. Perlthanks itself respects PERL5OPT for command line options, and a crafted PERL5OPT using Perl's -M flag loads and executes arbitrary Perl code the attacker supplies. Every step in that chain is itself an export, so none of it ever reaches Cursor's allowlist, for exactly the reason the PAGER example does not: none of it is a program on disk, and reporting on Pillar's research is consistent that this chain also worked against a completely empty allowlist. What makes it the fuller demonstration rather than a second illustration of the same point is what it rides on. The command a developer ultimately approves in this chain is not a display tool like git branch. It is an ordinary python3 script.py, the kind of command a developer approves for reasons that have nothing to do with warnings, browsers or Perl, and Docker's own account credits Elttam's 2020 research on environment variable driven code execution as the technique this chain builds on, repurposed here for Cursor's specific allowlist gap.

Three ways an authorized action can fail, and this is the third one

It is worth being exact about which failure this is, because collapsing it into ordinary allowlist bypass talk loses the part that makes it distinct. Moona Intelligence reads three separate failure modes hiding under the single word approval, and CVE-2026-22708 demonstrates the least discussed of them.

The first is an action executing without the approval it was supposed to require. The export and typeset calls in this vulnerability are exactly that: a control that should have fired and did not, because the checker was built to recognize the wrong category of thing. This failure mode is not new to this piece. A patched AWS vulnerability in Strands Agents Tools showed a related version of it, where a shell tool's human consent gate had a real off switch, and the off switch was a parameter the model itself was allowed to set. Both are cases where the human never got a chance to say no.

The second is an action changing after approval, a bait and switch where what runs is not what was shown. That is not what happened here. Nobody swapped git branch for a different command after the developer clicked approve.

The third is the one this vulnerability actually demonstrates: the visible action stays textually identical to what was approved, and its consequential meaning changes anyway, because something outside the scope of what was approved, in this case a shared, mutable piece of execution state, determines part of what the action actually does. The command was real. The approval was real. The gap sat entirely in what the word command was assumed to include. An approval prompt that shows a command's name and arguments is implicitly claiming that the name and arguments are the whole of what it is authorizing. Nothing about a shell environment is included in that claim, and nothing about a shell environment is stable between the moment a human reads a prompt and the moment the shell actually executes it.

What proves the meaning held

That is the question this vulnerability leaves standing after the patch. Cursor 2.3 closes the specific gap Pillar's research found, by classifying built-ins correctly rather than letting them slip past the allowlist as an unrecognized category. It does not, and could not on its own, answer the more general question a shell environment poses to any approval mechanism: once a human has approved a command's text, what continues to guarantee that the environment resolving that text at execution time is the same environment the human implicitly assumed when they approved it. Cursor's current documentation, corroborated through independent search after direct access to cursor.com remained blocked in this session, describes a layered Auto-review run mode, introduced in a later release than the one that patched this vulnerability, that evaluates a proposed command against the allowlist first, then a sandbox where one is available, then a separate classifier model, and states plainly that the allowlist itself remains best effort, not a security boundary, and that a determined agent or a prompt injection may still get past it. That is a materially different architecture from the single allowlist check CVE-2026-22708 exploited, and it is worth crediting as such. It is still, on the evidence available to this record, a defense in depth design rather than a claim that any one of its three layers, the allowlist included, is itself a hard boundary, and nothing in Cursor's own documentation claims otherwise. Separately, Cursor's current permissions reference documents each allowlist entry as a command or command prefix string matched against a proposed command's text, which corroborates precisely the object this piece has argued approval actually binds to: a command's displayed text, not the environment resolving it.

What containment answers, and what it does not

Docker's own contribution is not a claim to have solved the authorization question. Docker is explicit that its sandboxing does not stop the injected instruction from running, and does not stop the poisoned environment variable from being set. Inside a Docker Sandbox, by Docker's own account, the export statement still executes, and PAGER still gets poisoned. What changes is what that poisoned execution can subsequently reach. Docker describes microVM isolation with a deny by default network posture, so the same PAGER trick that could reach an SSH key or exfiltrate data on an unsandboxed machine finds no SSH key present and no open path out. Docker also documents two of its own caveats worth repeating rather than smoothing over: a workspace directory is live on the host by default, so a poisoned git hook or Makefile target inside that live directory stays reachable unless an operator explicitly isolates it, and Docker's shared skills store is mounted read write across sandboxes by default, so a skill modified inside one poisoned session can reach the next session even though it cannot reach the host directly. Docker separately describes Kits, a declarative network and filesystem policy an organization can review and version like code instead of maintaining as a personal allowlist, and an organization wide governance layer it says can override a local allow rule and generate an audit event, naming the user, the timestamp and the rule that fired, for every policy decision. Those are Docker's own documented claims about its own product, not independently reproduced by Moona against a running deployment, and they are containment claims rather than authorization claims.

The distinction matters more than it looks. Whether an action should be allowed to execute at all is a question authorization answers. Whether the action that actually executed still corresponds to the action a human meant to authorize is a separate question, approval integrity, and it is the one CVE-2026-22708 speaks to. What happens to the consequences once an action executes anyway, despite a broken or absent answer to either of the first two questions, is a third question, containment, and it is the one Docker's sandboxing, network policy and audit logging actually address. An audit event that records a poisoned PAGER variable being set is a real improvement over silence, and Docker is right that it converts an invisible bypass into something an investigator can find. It is a record of the bypass having happened. It is not evidence that the bypass did not happen, and it is not a mechanism that binds a command's meaning to what a human approved. Reducing what a compromised execution can reach is valuable and distinct from guaranteeing that execution matches authorization in the first place. Moona Intelligence's reading is that Docker's own framing supports exactly this separation, and the risk in covering this story is treating the second as proof of the first.

Where this sits against what this desk has already argued

The broader argument that instructions cannot be the boundary, and that authority has to be evaluated at the moment an action executes, is the family this piece belongs to, and CVE-2026-22708 sharpens a part of it that earlier evidence had not isolated. That argument is mostly about whether a system prompt or a written instruction can be trusted to hold a line. This vulnerability is not about an instruction failing to hold a line. It is about an approval succeeding, on exactly the text it was shown, while a separate and unmonitored piece of shared state decided what that text would actually do. Evaluating authority at execution time, the standard the earlier piece argues for, only closes this gap if what gets evaluated at execution time includes the environment the command is about to resolve inside, not only the command's own name and arguments. Most approval architectures, allowlists very much included, evaluate the second and never look at the first.

The Strands Agents Tools pattern, where the field controlling whether a consent gate fired was itself exposed to the model, is the nearest relative rather than the same failure. There, the model could turn its own gate off, inside the same tool call the gate was supposed to be guarding. Here, the gate never had jurisdiction over the mechanism at all. Shell environment variables are not a field in any tool's input schema. They are ambient state that persists across an entire session, readable and writable by any built-in the shell recognizes, and no schema level fix closes a channel that was never inside the schema to begin with. Approval becoming an action an agent can request is a different member of the same family again, about who is authorized to grant approval. CVE-2026-22708 does not touch who grants approval. It touches whether granting it means anything once granted. Claude Code's own move away from a per call prompt, toward a classifier that judges an action before it runs, is worth naming here too, because it is close to what Cursor's current Auto-review run mode now does with its own third layer. Neither is evidence that a classifier closes the specific gap this piece describes. A classifier judging a proposed action is still judging the action as represented to it, and this record has not verified what representation either classifier actually receives.

What this does not show

This is a patched vulnerability, not a current one. Cursor 2.3 and later versions are not affected by the mechanism described here, and nothing in this piece should be read as a claim otherwise. Moona Intelligence found no evidence, in Pillar's research, in Cursor's advisory or in Docker's later analysis, that this vulnerability was exploited against a real deployment before it was fixed. This was responsibly disclosed research, reported privately and patched, and the record of it becoming public runs through a coordinated advisory rather than an incident report. Nor does one environment variable technique, on one editor, in one non default configuration, establish that every approved command can be arbitrarily transformed. What it establishes is narrower and still durable: a command's approved text is not, by itself, evidence of what that command will do, because a command's meaning is resolved against an execution context that an approval prompt showing only a name and its arguments has no way to represent.

The Authority Provenance ledger

Authority grantor. The developer presented with Cursor's approval prompt, the person who reads a proposed command and decides whether to approve it, is the proximate execution grantor for that one call. That is as far as the evidence reaches. Nothing in Pillar's research, Cursor's advisory or Docker's account establishes, or was written to establish, that holding a Cursor session or a development workstation carries any broader organizational authority than the single call being approved, and this record does not infer one from the fact that a person had access to approve it.

Mandate or basis. Undocumented. None of the three primary accounts this record relies on address why the developer approving a command is entitled to authorize every consequential effect reachable through the privileges the Cursor agent process already holds. That is a question about organizational delegation, separate from Cursor's software, and none of the available material was written to answer it.

Delegated scope. This is the center of the vulnerability, and the evidence is precise on it. What a human approves, in Cursor's allowlist and its approval prompt, is a command's displayed text, its name and its arguments, checked as a string or a string prefix against a list of trusted programs. It is not the environment that command will resolve inside at the moment it runs. CVE-2026-22708 exists because those two things were treated as a single act of approval when they are not. Approving a command's text is not the same fact as authorizing every effect the command produces once environment state outside that text has already been changed by something the approval step never saw.

Explicit limits. Recorded here exactly as they operated in the affected versions, up to and including 2.2, rather than generalized to the product today. Auto-Run Mode with Allowlist mode enabled checked a proposed command against a list of trusted programs found on disk. Shell built-ins, export, typeset and declare among them, are not programs on disk, so the check never evaluated them, and this held even when the allowlist itself was empty, the most restrictive configuration available. That is not a limit that occasionally failed under pressure. It is a category of command the check was never built to see at all.

Inherited permissions or assumptions. What executed inherited exactly the privileges already available to the running Cursor agent process, nothing more. Neither Pillar's research, Cursor's advisory nor Docker's account claims privilege escalation beyond that process, and this record does not assert root, administrator or cloud level authority for either demonstrated chain. The PAGER chain and the PYTHONWARNINGS chain each hand execution to a program, a calculator application, a shell, Perl, that the agent process itself was already permitted to run.

Revocation or modification path. What exists is a parser change, not a runtime revocation mechanism. Cursor 2.3 made anything its parser cannot classify require approval going forward. Available material does not describe a way to revoke or invalidate one specific already granted approval, or to detect and roll back an environment variable that was poisoned in the moments before a human approved a command that then read it. What this record can confirm is a version upgrade, applied once, that closes the path for future calls.

Challenge authority. The human confirmation mechanism existed, and that is why this is not a case of approval simply being absent. Cursor showed the developer a command and asked. The failure is narrower and more specific than no challenge occurring at all: what was displayed and challenged did not encode the shell environment the command would actually run inside, so approving the displayed object left a variable outside that object's scope free to determine part of what execution actually did. This record keeps that distinct from a complete absence of human challenge, a different and more familiar failure documented elsewhere in this corpus.

Recovery path. Undocumented beyond the patch itself. Pillar's research, Cursor's advisory and Docker's account each describe how the vulnerability worked and how it was fixed. None describes a rollback, compensation or restoration process for a command that already executed against a poisoned environment while a version before 2.3 was deployed. Patching the parser prevents a future recurrence. It does not reverse an effect a poisoned command already produced.

Provenance evidence quality. Strong and independently corroborated for the technical mechanism: Cursor's own advisory, read directly, and Docker's own account, read directly, agree on what the allowlist checked, what it missed and why. Weaker, and undocumented rather than merely thin, for everything upstream and downstream of that mechanism: no material establishes an organizational mandate for the developer granting approval, a channel through which someone other than that developer could challenge a specific approval already given, or a recovery path for an effect a poisoned command already produced before the patch. The strongest evidence in this record is mechanical, what the parser checked and what it now checks instead. The weakest is exactly what a human's approval was supposed to settle and could not, on its own, guarantee.

The question worth carrying forward

Every approval architecture answers a version of the same question its designer has to be honest about: when a human looks at a proposed action and says yes, what exactly is included in that yes. A name and its arguments are the easiest thing to show a person and the easiest thing to check against a list. They are not the same thing as the full state that determines what running that name with those arguments will actually do. CVE-2026-22708 is one small, patched, well documented case where that gap had a name, PAGER, and a mechanism, export. The gap itself is not specific to Cursor, to shell environments, or to this one CVE. It is specific to any approval step that checks what an action is called without checking what, at the moment it runs, that action has been quietly set up to mean.