AI Agent Security: Vulnerabilities and Attack Kill Chains

Summary

Cymulate's November 3, 2026 article presents two researcher-built attack demonstrations showing how weaknesses across AI coding agents can be chained from untrusted content to privileged cloud identities. The scenarios assume shared Windows hosts, multiple users, and agents connected to corporate services. They are research demonstrations rather than evidence of an observed malicious campaign; the supplied article identifies no real-world victim or named threat actor. All substantive findings in this dossier come from that single article.^[0]

The first demonstration moves from a prompt-injected web page through AWS Kiro code execution, cross-user Codex CLI takeover, and OpenAI token theft into a shared Codex cloud environment. A malicious setup script then captures QA secrets, including an Azure application client ID and secret associated with broad tenant permissions. The second demonstration moves from a poisoned README through Cursor execution and cross-user hooks, then propagates through a shared repository to Gemini CLI, exposing Google OAuth credentials usable with the victim's GCP permissions.^[0]

The common failure is misplaced trust across agent inputs, executable lookup paths, machine-wide configuration, local IPC, sandbox configuration, and cloud sessions. Reported remediation is uneven: AWS and Anthropic fixed their identified CVEs, OpenAI fixed the named-pipe issue but did not accept all reported execution findings, and Cursor's issues remained unresolved at publication. Defenders should therefore combine available fixes with independent execution isolation, owner-restricted configuration and secrets, constrained cloud privileges, and monitoring that connects agent inputs to endpoint actions and identity use.^[0]

Attack chain

1. Azure demonstration — 1. Web content to Kiro execution: A user asks Kiro to work with an attacker-controlled web page. Hidden instructions cause the file-write tool to create a VS Code task definition that Kiro inherits and executes on a subsequent relevant event without an approval prompt. This yields execution as the first Windows user through the configuration-poisoning issue identified as CVE-2026-10591.^[0]
2. Azure demonstration — 2. Cross-user Codex takeover and token theft: From that foothold, the attacker targets another user's Codex CLI session. A named pipe granting Everyone full control allows sandbox impersonation and fabricated command output. Combined with Codex configuration weaknesses described by the researchers, this manipulation exposes the second user's OpenAI authentication token from their Codex configuration directory.^[0]
3. Azure demonstration — 3. Shared cloud-environment backdoor: Using the stolen token as the victim's OpenAI identity, the attacker modifies the organization's shared Codex cloud environment. Persistent instructions direct generated code to import an attacker-controlled library, while the environment setup script is sourced from an attacker-controlled repository.^[0]
4. Azure demonstration — 4. Execution through downstream cloud tasks: Subsequent application-generation requests incorporate the attacker's script. Code-review and other tasks in the GitHub-connected environment run the malicious setup script before their normal work because automatic setup is enabled. The shared environment becomes a propagation point for later consumers.^[0]
5. Azure demonstration — 5. QA secret exposure and Azure access: When QA automation runs, the setup script executes as root inside the cloud container and sends process identity and environment variables to the attacker. These include an Azure app registration's client ID and secret. Because that application has broad tenant permissions in the constructed scenario, its credentials provide high-privilege Azure access.^[0]
6. GCP demonstration — 1. README injection and Cursor binary hijacking: A user directs Cursor CLI to a repository containing a poisoned README. The agent writes an executable named npx.exe into the project directory. On the next prompt, Cursor resolves the helper by name with the project directory searched first, executing the planted binary with the user's privileges without further approval.^[0]
7. GCP demonstration — 2. Cross-user execution through ProgramData: The first user creates C:\ProgramData\Cursor, which the article says is absent by default and can be created by a standard user. An attacker-controlled hooks configuration executes a command when another user submits a Cursor prompt. This provides execution in the second user's session and access to their GitHub credentials.^[0]
8. GCP demonstration — 3. Repository propagation: Using the second user's GitHub access, the attacker commits an AGENTS.md instruction file and helper-named executables, including git.exe and docker.exe, to a team repository. Users who pull the repository receive the planted files.^[0]
9. GCP demonstration — 4. Gemini sandbox-startup hijacking: A third user pulls the repository and starts Gemini CLI with sandboxing enabled. On Windows, sandbox startup resolves an external container runtime by name and includes the project directory in its search. The planted docker.exe therefore executes on the host before isolation starts.^[0]
10. GCP demonstration — 5. OAuth credential theft and GCP access: Gemini's sandbox mounts the user's ~/.gemini directory with write access, exposing stored OAuth credentials to the compromised session. The attacker reads access and refresh tokens. The demonstrated access token has cloud-platform scope and is used with the Cloud Resource Manager API to list the victim's GCP projects, exercising the permissions of the compromised identity.^[0]

Disclosure timeline

How it works

Execution-flow hijacking bridges prompt injection and operating-system execution. In the Kiro example, untrusted content induces a write to execution-sensitive task configuration. In the Cursor example, an unrestricted file-write tool creates an encoded executable in the workspace, and a later helper launch resolves that local binary before a trusted system copy. The initial user request is still required; the demonstrated issue is execution without a subsequent approval step.^[0]

The sandbox failures occur at different boundaries. Writable host configuration can influence behavior outside the sandbox, while credential directories mounted into a sandbox expose secrets to compromised work inside it. Separately, Gemini's Windows sandbox startup resolves a container runtime from a search path containing the workspace, permitting host execution before the containment boundary exists.^[0]

World-writable trust enables cross-user execution without requiring the first user to administer the machine. An application trusts a machine-wide configuration location even when a standard user can create or populate it. In the Cursor demonstration, prompt-triggered hooks under C:\ProgramData\Cursor execute in another user's agent session. The article also identifies machine-wide dependency paths such as C:\node_modules as part of this vulnerability family.^[0]

Codex's cross-user IPC weakness is a command-result integrity failure. A named pipe with an Everyone full-control security descriptor allows another local user to impersonate the sandbox and return fabricated results. The model treats those results as output from its own commands; in the demonstration, this is combined with configuration weaknesses to obtain the victim's OpenAI token rather than treated as a standalone token-read primitive.^[0]

UNC credential coercion is separate from the two main code-execution chains. When an agent file tool reads or lists an attacker-supplied UNC path, Windows connects to the remote share and automatically authenticates as the current user. The resulting exposure is NTLM authentication material, not necessarily a plaintext password, and the article states that no victim-side code execution is needed. The behavior was reported in GitHub Copilot, Codex CLI, and Google Antigravity.^[0]

Cloud compromise depends on the authority of stolen identities and secrets, not just local execution. The OpenAI token permits modification of shared Codex environment instructions and setup behavior; the malicious QA setup then captures Azure credentials from environment variables. In the Gemini scenario, exposed OAuth tokens carry cloud-platform scope and permit use of the victim's existing Google Cloud permissions. The demonstrated Azure and GCP outcomes therefore depend on the broad privileges assigned in those scenarios.^[0]

Affected versions and patch status

Key takeaways

• These are demonstrated exploit chains under stated enterprise assumptions, not evidence of an active campaign. No independent corroborating source, named attacker, or operational attacker infrastructure is supplied.^[0]
• Assess combinations of agent weaknesses rather than individual findings alone: workspace execution, cross-user configuration or IPC trust, and exposed cloud credentials produced substantially greater impact when chained.^[0]
• A vendor sandbox is not sufficient protection when startup resolves workspace binaries or the sandbox exposes host configuration and credentials. Test the isolation boundary and its startup behavior, not merely whether sandboxing is enabled.^[0]
• The relevant security boundary extends into shared cloud environments. Modified instructions and setup scripts can affect later tasks and users, while the permissions of inherited identities determine the final blast radius.^[0]
• The article's remediation summary is not a version-level patch inventory. It names several fixed findings but leaves build ranges and some per-finding outcomes unspecified, so its broad vendor-response labels should not be treated as proof that every described weakness is resolved.^[0]

Defensive actions

• Deploy the reported Kiro, Claude Code, and Codex named-pipe fixes, and restrict agents with unresolved findings on shared hosts.: These fixes remove specific demonstrated primitives, while the article reports unresolved Cursor issues and incomplete remediation elsewhere. Its lifecycle guidance recommends inventorying agents, keeping them current, and blocking unapproved or outdated clients.^[0]
• Limit agent-readable sources and approved integrations; inspect ingested content for prompt injection and investigate suspicious agent-session behavior.: Both demonstrations begin with attacker-authored information: a web page or README. The article recommends allowlisting domains, repositories, and registries, restricting tools and plugins, scanning untrusted inputs, and using session refusals or repeated interruptions as investigative context.^[0]
• Run agent workloads behind an independent isolation boundary that does not expose host credentials.: The demonstrated vendor sandboxes do not reliably prevent access to host configuration or credential stores, and Gemini's runtime lookup executes before isolation. The article recommends real virtualization, cloud development environments, or dedicated container hosts rather than relying solely on the agent's own sandbox.^[0]
• Pre-create machine-wide vendor configuration directories with administrator-only write access, restrict agent configuration and token stores, and enforce owner-restricted IPC access.: Cursor's attacker-created ProgramData folder enables cross-user hooks, Codex's permissive named pipe enables sandbox impersonation, and writable or exposed configuration directories weaken credential boundaries. The article specifically recommends securing these paths and restricting pipes and token stores to their owner.^[0]
• Correlate agent inputs with child-process execution, file changes, network activity, and cross-user pipe connections.: The article cautions that agent process trees are often legitimately complex. Higher-value combinations include a new workspace executable followed by agent-launched execution and outbound traffic, non-administrative creation of ProgramData vendor folders, permissive pipes, and external SMB or NTLM authentication.^[0]
• Constrain agent-held cloud and source-control credentials to task needs, favor short-lived credentials, and require approval for high-impact actions.: The demonstrated Azure outcome depends on broadly privileged QA application credentials, while the GCP chain uses the victim's Google permissions and stolen GitHub access. The article recommends QA-only Azure access, narrower GitHub tokens, limited Google access, and task-bound rather than standing credentials.^[0]
• Audit and alert on changes to shared cloud-agent instructions and setup scripts, and monitor agent credentials used from unexpected locations.: The Azure demonstration establishes persistence by changing the Codex cloud environment rather than the endpoint. Subsequent tasks run the modified setup and expose environment secrets, making cloud configuration and identity telemetry necessary alongside endpoint monitoring.^[0]
• Require review of repository changes that add executables or agent instruction files.: The GCP demonstration propagates through a team repository containing AGENTS.md and helper-named executables. The article identifies review gates for such commits as a point where this chain could be broken.^[0]