CVE-2026-73217 isn't a sandbox escape—it's a trust-reversal inside the sandbox that exposes a fundamental architectural flaw in how Cursor (and likely every AI-assisted IDE) separates agent privileges from toolchain privileges.
The attack works like this: Auto-Run Sandbox correctly contains the agent's direct file operations. But the agent has filesystem write access to project directories—write access the agent needs to create virtual environments, modify configs, and be genuinely useful. The Microsoft Python extension, running outside the sandbox, implicitly trusts the venv directory as a safe execution context. When the agent writes a malicious wrapper to the venv's Python binary and the extension subsequently invokes it, the wrapper executes with the extension's host privileges. The sandbox never saw this as an attack surface because the agent wasn't escaping—it was doing something boring (writing a file) that the sandbox permits.
This is the confused deputy problem wearing new clothes. The vulnerability class has decades of precedent in build systems, container runtimes, and package managers—all the same genetic sequence where an entity with write access to a directory that another entity trusts for execution creates a privilege escalation path. Cursor didn't introduce this flaw; they inherited it. The Microsoft Python extension's implicit trust of venv directories predates AI agents by roughly a decade, built for a world where the entity writing to venv and the entity executing from venv were the same human developer.
The 3.1.2 patch presumably closes the specific venv path—likely through access restrictions or binary integrity checks. But examine the fix carefully. If Cursor restricted venv write permissions, they patched the symptom. If they added integrity verification or sandboxed the extension itself, they acknowledged the deeper problem. The attack class—modify anything an external process will subsequently trust—remains architecturally endemic to multi-process IDE ecosystems.
For your environment: audit every directory your IDE extensions treat as trusted execution contexts (venv, node_modules, tool caches, shell configs). Ask whether your agent has write access to any of them. Assume that within eighteen months, a different trusted execution context will emerge that the agent can influence—this is a class vulnerability, not a one-off bug. The fix that works today is a band-aid on systemic architectural debt that the entire AI tooling ecosystem is accumulating.