Computer-Use Agent TOCTOU: Screen Swaps Cause Unintended Clicks

Johann Rehberger published a working TOCTOU exploit against Claude Computer-Use in June 2026, and it lands cleanly. The attack exploits one structural property of how all computer-use agents work: they look at the world, think about what to do, and then act — and the world can change between the looking and the acting. The research was publicly disclosed June 25, with a video demo presented at Stanford’s Real-world AI Security Conference. The finding applies to Claude Computer-Use as the primary target but a related vulnerability in ChatGPT Operator (GHSA-mp56-7vrw-qxvf, documented by Jun Kokatsu) confirms the problem is architectural, not model-specific.

How the timing window opens

Computer-use agents operate in a capture-reason-act loop. The agent takes a screenshot, sends it to the LLM for visual reasoning and action planning, receives a response specifying what to click or type, and then executes that action. The LLM inference step is the bottleneck. A capable model analysing a complex screen can take two to five seconds to return its action plan. That interval is the attack surface.

During those seconds, whatever is displayed on screen can change. The agent’s action plan was generated against a screenshot that no longer reflects reality. When the action executes, it operates on the current state of the screen, not the state the agent reasoned about. Classic time-of-check to time-of-use, applied to GUI agents.

The TOCTOU concept is decades old in systems security — file permission races, signal handler races, kernel scheduling races. What makes the AI agent variant novel is the mechanism that creates the delay. It’s not a scheduler preemption or a kernel context switch. It’s the inherent inference latency of a large language model.

The Outlook demo

Rehberger’s proof-of-concept is precise. The attack setup:

1. A malicious page serves a “Continue” button, positioned to pixel-exact coordinates corresponding to where Outlook’s “Send” button renders.
2. The page contains a prompt injection instructing Claude to execute a bash calculation — specifically 1+1 — before proceeding.
3. Claude reads the instruction, decides to run the calculation first, and takes a screenshot showing the “Continue” button.
4. While Claude is computing the bash result and reasoning about next steps, the page transitions. Outlook has now loaded behind the malicious overlay, with a pre-drafted email addressed to an attacker-controlled recipient already composed.
5. Claude’s reasoning resolves. It decides to click “Continue” based on the screenshot it analysed.
6. The click executes. But “Continue” is gone. What’s at those screen coordinates now is Outlook’s “Send” button. The email sends.

The bash calculation is the timing mechanism. It doesn’t have to be 1+1 specifically — any injected instruction that consumes agent reasoning time creates the window. The key insight is that the attacker controls the timing source: the injected prompt determines how long the agent spends in the reasoning phase before acting.

The agent receives no error. Nothing in its context indicates that what it clicked differed from what it saw. From the agent’s perspective, it clicked “Continue” and the task proceeded.

What the agent doesn’t know

The structural problem is that agents don’t maintain a continuous, verified model of the screen state between their reasoning step and their action step. They see a screenshot. They decide what to do. They do it. If the screen changed, that’s not in scope for the agent’s awareness unless the agent framework explicitly checks for it.

This is not a failure of the underlying model’s visual reasoning. Claude correctly identifies the “Continue” button in the screenshot it was given. The button was there when the screenshot was taken. The model is doing its job. The race condition is in the harness, not the model.

That distinction matters for defenders. Patching the LLM or upgrading to a more capable model doesn’t address the vulnerability. The fix has to be in the agent loop itself.

ChatGPT Operator

Rehberger’s research notes a parallel finding by Jun Kokatsu in ChatGPT Operator, tracked as GHSA-mp56-7vrw-qxvf. The specific exploitation path differs across the two systems, but the same architectural gap applies: any computer-use agent that separates the screen-capture step from the action-execution step has a TOCTOU window. The width of that window scales with inference latency. Slower reasoning, larger attack surface.

As more AI labs ship computer-use products — OpenAI’s Operator, Anthropic’s Claude Computer-Use, Google’s Project Jarvis-derived tooling — and as the inference latency for frontier models remains in the second range, the vulnerability class will recur across implementations.

Anthropic’s mitigation

Anthropic’s response was pixel-change verification: before executing any action, the agent framework checks whether the pixels at the target coordinates have changed since the screenshot was taken. If they have, the action is aborted.

This is the correct direction. Pixel-change verification closes the visible UI swap attack — if the attacker’s transition is visually detectable, the agent won’t proceed. Rehberger notes the mitigation directly: “We also ensure that pixels haven’t changed before action.”

The harder cases involve changes that aren’t detectable at the pixel level. DOM manipulation that repositions click targets without visible rendering changes. Iframe overlays that are transparent but intercept clicks. Accessibility tree mutations that change what a click means without changing what the user sees. Pixel verification catches obvious swaps. It doesn’t address the full attack surface.

What teams building on computer-use should do

For teams deploying computer-use agents in production, the immediate controls are:

Sandboxed browser environments: Run computer-use agents in isolated browser profiles with no access to authenticated services unless those services are the explicit task target. An agent that can’t access Outlook in the background can’t be tricked into sending an email via Outlook.

Constraint injection to task targets: Limit agent authority to the specific service the user authorised for the task. An agent helping with a form submission shouldn’t have access to email, calendar, or anything else. Permission scoping by task type reduces the blast radius of a successful TOCTOU exploit.

UI stability verification in the action loop: Don’t rely solely on pixel-change checking at the coordinate level. Verify that the element the agent intends to click — by accessibility ID, element type, or stable DOM identifier — still matches the intended action target at execution time. This is harder to implement than pixel comparison but more robust against partial-page manipulation.

Audit logging of agent actions with screenshots: Log what the agent saw when it made its decision alongside what action it took. Post-incident analysis of TOCTOU exploits is difficult without evidence of the screen state at decision time versus execution time.

Computer-use agents are compelling because they can operate general-purpose software interfaces without custom integrations. That generality is also the attack surface. An agent with access to a browser is an agent with potential access to everything in that browser session, and the TOCTOU window is a mechanism to redirect that access without the agent’s or user’s knowledge.

References

• Embrace The Red — Computer-Use and TOCTOU: What You Click Is Not What You Get!
• GitHub Security Advisory GHSA-mp56-7vrw-qxvf — ChatGPT Operator TOCTOU