DEV Community: Armor1

How to Audit Your AI Agent Skills for Credential Exposure and Malicious Instructions

Armor1 — Fri, 15 May 2026 00:40:52 +0000

Two independent security research groups published this week with findings that land on the same problem from different angles: AI agent skill files are a serious and underaudited supply chain surface, and the attack techniques targeting them are already in active use.

The Scale Finding

Capsule Security's analysis covered more than 200,000 agent skill files and 160,000 code files. The result that stands out: 2,909 of 19,618 distinct skill files carry hardcoded credentials alongside direct database write access. Roughly 15% of distinct skill files in active use. No additional exploit is required. Install the skill, the agent reads the skill configuration, the credentials are there.

The same analysis found that AI workloads present a supply chain attack surface six times larger than traditional software. It also observed that malicious skills continue to persist and propagate after the campaigns that distributed them are officially terminated.

The Active Campaign

A separate disclosure published the same week documents a March 2026 campaign targeting a popular AI coding agent framework. Attackers published deceptive community skills that appeared legitimate at a glance. The payload delivery mechanism was not a traditional malware dropper. It was the installation instruction inside the skill file itself.

The skill's installation instructions directed the agent to perform operations that installed Remcos RAT and GhostLoader. The agent followed those instructions because that is exactly what installation instructions are for. No user interaction beyond installing the skill was required.

This is a distinct campaign from the January 2026 supply chain attack covered in prior security reporting. Different delivery mechanism. Different payloads. The point of connection: both used the skill ecosystem as the distribution channel.

What the Attack Surface Looks Like

An AI agent skill typically consists of a few components:

A metadata file (often named SKILL.md or similar) containing the skill's name, description, and installation instructions
Configuration specifying what tools, permissions, and external resources the skill uses
Optionally, code files the skill executes

The attack surface is broader than the code. The metadata file, particularly the installation instructions, is executed by the agent as part of skill setup. An agent that reads and follows installation instructions is following arbitrary instructions from whoever wrote that file. If the file was tampered with or written by a threat actor, those instructions are arbitrary commands.

The credential exposure problem is a separate issue: skill files that embed API keys, database connection strings, or other credentials expose those values to every developer who installs the skill, to the agent that reads the configuration, and to anything else in the agent's context window.

How to Audit Your Skills

Step 1: Inventory what you have. List every skill file currently active in your agent environment. For community-sourced skills, note the source and whether the version has changed since you installed it.

Step 2: Check skill metadata for credentials. Search skill configuration files for patterns that suggest embedded credentials: connection strings, API key patterns, private key markers. A regex scan for common credential patterns across skill metadata is a reasonable first pass.

Step 3: Review installation instructions for anomalies. Read the installation instruction sections of skill files, particularly community-sourced ones. Installation instructions that invoke shell commands, download additional packages from unverified sources, or reference external URLs outside the skill's stated purpose are worth investigating.

Step 4: Check skill versions and provenance. Skills that have changed since their last verified install are a flag. Skills from sources without a clear maintainer are a flag. If a skill you installed months ago now behaves differently, that is worth examining.

Step 5: Treat skill installs as supply chain events. The same controls that apply to adding a dependency to package.json should apply to adding a skill to an agent environment. Review what it does, check the source, pin to a specific version.

How Armor1 Approaches This

Armor1's skill security scanner evaluates every skill file before execution. The scanner checks for hardcoded credentials and credential misuse patterns, malicious installation instructions, data exfiltration patterns embedded in skill configuration, and supply chain risks such as references to unverified external packages or remote code in skill definitions. The scanner runs two passes: an initial analysis and a verification pass to reduce false positives.

The credential exposure Capsule Security found at scale and the installation instruction attack vector documented in the March 2026 campaign both fall inside the categories the scanner evaluates.

Check the risk of any MCP server in your environment with Armor1's free public catalog.

To cover every agentic app, MCP, tool, skill, and plugin across your stack, sign up free Here.

What "Code That Runs Before You Click Trust" Means for AI Coding Tools (Claude Code Case Study)

Armor1 — Tue, 12 May 2026 23:54:17 +0000

The trust dialog in an AI coding tool is supposed to be the security boundary that gates everything the agent does inside a workspace. External security researchers recently published a technical write-up of arbitrary code execution paths in Anthropic's Claude Code CLI that fired before that dialog appeared. Anthropic patched the disclosed paths quietly in December 2025; the public write-up landed on April 30, 2026.

This article is not just about Claude Code. It is about the broader category these findings name: any operation an AI coding tool performs during workspace bootstrap, before the user confirms trust, is a candidate for the same class of bug.

How Pre-Trust Execution Happens

When you open a new project in an AI coding tool, the tool typically does several things before showing the trust prompt:

Reads project configuration files (.editorconfig, .tool-config, .vscode/settings.json-style files) to set up the editor view.
Parses plugin or extension manifests to determine which extensions to activate.
Runs project-local hooks or initialization scripts as part of the bootstrap.
Resolves package manifests to set up the language server.
Invokes Git to determine repository state, branch, recent commits.

Each of these steps is "safe-by-convention" when initiated by a human user, on the assumption that the human applied implicit context (do I trust this workspace) before opening the project. None of them are safe when an automated bootstrap performs them on a workspace the user has not yet ratified.

The Claude Code findings sit in this category. Workspace-scoped configuration files were parsed eagerly; the parsing dereferenced references that triggered execution; the execution happened before the trust dialog had a chance to appear.

The General Pattern

Pre-trust execution requires three ingredients:

A bootstrap operation that touches workspace-controlled state. Reading a config file, resolving a manifest, executing a hook, evaluating a script.
A reference inside that state that triggers code execution. A path, a module reference, a hook script, a serialized object that gets deserialized into running code.
No gating between (1) and (2) on user-confirmed trust.

Closing the bug means breaking the chain at (3). Either the bootstrap does not touch workspace-controlled state at all until trust is confirmed, or the parsing of that state is performed in a sandboxed environment that cannot trigger code execution until trust is confirmed.

How to Audit an AI Coding Tool for This Class of Bug

If you operate or build an AI coding tool, the questions to ask:

What files does the tool read from the workspace before showing the trust prompt? List them all. For each, ask: can the contents trigger execution, directly or through dereferencing?
What plugins or extensions activate before the trust prompt? If any extension manifest is parsed, the parsing logic itself is in scope.
What Git operations does the tool perform before the trust prompt? Each Git op is a potential trigger for any .git/hooks/ script the workspace ships.
What language-server initialization happens before the trust prompt? Language servers often resolve and load workspace-specific config that can include arbitrary paths.
Does the tool's own update process touch workspace-scoped state during bootstrap? Some self-update mechanisms read workspace config to determine update behavior.

What Users Can Do

For Claude Code specifically: ensure your CLI is on a release dated after December 2025. Auto-update is on by default; most users are patched.

For AI coding tools more broadly: pin to recent versions, audit each tool in your fleet for what it does on workspace open, and treat opening an unfamiliar repo as a high-risk action regardless of the trust prompt's presence.

How Armor1 Detects This

Armor1's Client Catalog evaluates AI coding clients across 16 risk categories. Two are directly relevant to pre-trust execution paths:

Execution Approval Controls: measures whether sensitive operations require user-visible approval before execution. A client whose bootstrap executes workspace-scoped configuration before a user-visible approval step surfaces in the catalog as a high-risk posture, independent of any specific CVE.
Script Hooks: measures whether the client runs hook scripts from workspace-controlled locations without independent user confirmation. The same structural feature that the recent Claude Code research targeted, evaluated as a category not as a bug-by-bug list.

For developer fleets running multiple AI coding tools, Armor1 inventories every client in scope and tracks the version-to-risk mapping across the fleet. Versions before the December 2025 Claude Code patches surface differently from versions after.

Check the risk of any MCP server in your environment with Armor1's free public catalog

To cover every agentic app, MCP, tool, skill, and plugin across your stack, sign up free Here

How to Check if You're Affected by CVE-2026-26268 in Cursor (and What to Do)

Armor1 — Sun, 10 May 2026 07:34:06 +0000

CVE-2026-26268 is a CVSS 8.1 high-severity vulnerability in the Cursor AI IDE that lets a malicious repository execute arbitrary code on a developer's machine the moment Cursor's agent performs a Git operation against it. There is no prompt injection, no user click, and no warning dialog. The agent's normal bootstrap flow is sufficient to trigger execution.

The bug is patched in Cursor 2.5. Every version prior to 2.5 is affected.

How the Mechanism Works

Cursor's agent operates with significant autonomy inside a workspace. When you open a new project, the agent indexes the codebase, summarizes structure, offers to set up the dev environment, and performs Git operations as part of that bootstrap.

The vulnerability allows a repository to ship a .git/hooks/ configuration containing arbitrary shell commands. Git hooks are scripts that Git executes at specific points in the workflow (pre-commit, post-checkout, post-merge, etc.). When Cursor's agent triggers any Git operation that fires one of these hooks, the hook script runs with the developer's process privileges.

Critically:

No human typed git commit. The agent did.
No trust dialog appeared. The hook ran during a normal agent operation.
No prompt injection was needed. The agent was not subverted; it was performing its standard workflow.

How to Check if You Are Affected

1. Check your Cursor version

from inside Cursor: Help -> About

Or from terminal:

cursor --version

2. If output is < 2.5, you are running a vulnerable version.

If you have ever opened an unfamiliar repository in Cursor on a pre-2.5 version, treat the developer environment as potentially compromised. Specifically:

Audit Git hooks in any recently-opened workspace

cd /path/to/workspace
ls -la .git/hooks/

Anything not ending in .sample (the default Git template files) is custom.

Inspect the contents of every non-.sample file.

cat .git/hooks/post-checkout 2>/dev/null
cat .git/hooks/pre-commit 2>/dev/null
cat .git/hooks/post-merge 2>/dev/null

How to Fix

Update Cursor to 2.5 or later. From inside Cursor, choose Help -> Check for Updates. The fix landed in version 2.5; every version before that is vulnerable.
Audit any unfamiliar repos you opened on a pre-2.5 version. If you opened a repo from an unknown source while running 2.4 or earlier, inspect its .git/hooks/ directory for custom scripts before reopening it.
Rotate credentials reachable from the developer environment if you have reason to believe a malicious workspace was opened. Session tokens, API keys, and any credentials cached in environment variables or local config files are in scope.
For team installations, push Cursor 2.5 fleet-wide and confirm uptake through your MDM or distribution channel.

How Armor1 Detects This

Armor1's Client Catalog evaluates AI coding clients across 16 risk categories. Two of those categories are directly relevant to CVE-2026-26268:

Script Hooks: measures whether the client runs hook scripts from workspace-controlled locations without independent user confirmation. Cursor versions before 2.5 surface as a high-risk posture in this category. The catalog reflects the structural feature, not just the disclosed CVE, which means similar vulnerabilities in the same class would surface even before they receive a CVE assignment.
Execution Approval Controls: measures whether sensitive operations require user-visible approval before execution. An agent that performs Git operations on a fresh workspace without an approval gate is, by definition, exposed to this attack pattern.

For developer fleets running multiple AI IDEs, the catalog inventories every AI coding client in scope and tracks the version-to-risk mapping across the fleet.

Armor1's free public catalog covers the per-server MCP risk picture. The full agentic stack scan covers every app, MCP, tool, skill, and plugin across your environment.

Check the risk of any MCP server in your environment with Armor1's free public catalog

To cover every agentic app, MCP, tool, skill, and plugin across your stack, sign up free Here

How to Check If Your Claude Code Installation Is Affected by CVE-2026-39861 (CVSS 7.7)

Armor1 — Fri, 08 May 2026 02:32:14 +0000

CVE-2026-39861 is a sandbox escape in Claude Code, patched in version 2.1.64. The vulnerability allows file writes to land outside the workspace directory by exploiting symbolic link following across two Claude Code processes. Reported by security researcher philts via HackerOne, tracked as GHSA-vp62-r36r-9xqp. If you use Claude Code below 2.1.64, update immediately.

The Mechanism

Claude Code sandboxes write operations to the current workspace directory. CVE-2026-39861 bypasses this using two processes:

A sandboxed process creates a symbolic link inside the workspace. The symlink points outside the workspace boundary. Creating a symlink inside the workspace is permitted, so the sandbox allows it.
A separate, unsandboxed process writes through that symlink. It does not re-validate the resolved path. It sees a path inside the workspace and writes to it. The write lands at the symlink's target, outside the sandbox.

The root cause: the sandbox checks the declared path at creation time but not at resolution time. TOCTOU-adjacent pattern. The filesystem state changes between validation and use.

Who Is Affected

Anyone running Claude Code below 2.1.64. Auto-update (the default) delivers the patch automatically. Enterprise environments that pin versions need to apply the update explicitly.

How to Check Your Installation

Step 1: Run claude --version. Below 2.1.64 = affected.

Step 2: Confirm auto-update is enabled. If your org disables it for controlled rollouts, confirm the update has been applied.

Step 3: If you suspect exploitation, check for unexpected symlinks pointing outside the workspace:

find /path/to/your/workspace -type l -exec ls -la {} \;

Look for symlinks targeting system directories, home directory config files, or anything outside the project tree.

Step 4: If your environment captures Claude Code sandbox logs, review for path resolution events where declared path and resolved path differ. A write where the resolved path falls outside the workspace boundary is the signature.

The Broader Pattern

This is the sixth Claude Code advisory in the current review period. The previous five: argument injection, domain verification bypass, credential theft via prompt injection, command injection through the prompt editor, hook injection via CBSE. Six advisories, six distinct attack classes, multiple independent researchers.

The pattern reflects a structural property of agentic execution models: tools that combine user-level filesystem access with agent-driven autonomous execution present a recurring attack surface. Staying current on versions is baseline hygiene.

How Armor1 Tracks This

Armor1's Client Catalog scores Claude Code across 16 risk categories. Two map directly to this CVE:

Sandbox Isolation measures whether write operations stay confined to the declared workspace. The symlink-following escape is the class of violation this category covers.

Supply Chain and Update Posture distinguishes installations below 2.1.64 from patched ones. Teams can identify unpatched Claude Code instances across their developer fleet without manual version audits.

Two things you can do right now, both free:

See the risk of any MCP server in your environment in Armor1's public catalog

Cover your entire agentic stack (every app, MCP, tool, skill, and plugin) by signing up free Here

How to Check Your MCP Server for CVE-2026-5603's Vulnerability Pattern (And Why shellQuote Isn't Enough)

Armor1 — Wed, 22 Apr 2026 00:08:34 +0000

CVE-2026-5603 is a Critical command injection in @elgentos/magento2-dev-mcp, but the vulnerability pattern it represents shows up in community MCP servers regularly. This post explains what the vulnerability is, why the sanitizer fails on Windows, how to check your own MCP server code for the same issue, and what the correct fix looks like.

What Is CVE-2026-5603?

@elgentos/magento2-dev-mcp is an NPM package that exposes Magento 2 development operations as MCP tools: database queries, cache management, module operations, configuration commands. AI coding assistants can call these tools on behalf of developers.

The vulnerability: 16 of these tools pass user-supplied parameters into shell commands. A single-quote sanitizer is applied before insertion, but it fails to protect Windows deployments. The result: an attacker who can manipulate an AI agent into calling one of these tools with crafted parameters can execute arbitrary commands on the machine running the server.

Affected versions: 1.0.2 and earlier. Patched in PR #5.

Why shellQuote Fails on Windows

shellQuote uses single-quote escaping designed for Bourne-compatible shells. In bash and sh, everything between single quotes is treated as a literal string. Special characters have no effect.

cmd.exe does not use single quotes as quoting characters. They pass through the command line unchanged. Metacharacters like &, |, >, and < retain their command-separator semantics regardless of surrounding single quotes.

The server documentation confirms Windows as a supported deployment environment. Magento 2 developers running Docker-based local environments (Warden, DDEV) on Windows are the target population.

How to Audit Your Own MCP Server

If you maintain or use a community MCP server that wraps shell operations, check for this pattern:

Identify any shell execution calls in the server code. For each one, trace where the values fed into the command come from. If any value originates from MCP tool parameters (what the AI agent sends), check whether any sanitization is applied and whether that sanitizer covers all deployment platforms, including Windows.

String-escaping libraries designed for Unix shells typically do not protect against Windows cmd.exe. If a user on Windows deploys your server, escaping that worked in your Linux test environment may be silently ineffective on theirs.

The fix pattern

The correct approach uses execFile (Node.js) or equivalent:

import { execFile } from 'child_process';
import { promisify } from 'util';

const execFileAsync = promisify(execFile);

// args is an array, not a concatenated string
const { stdout } = await
execFileAsync('magerun2', [userQuery], options);

This works safely on both Linux and Windows. No sanitizer needed because no shell interprets the arguments.

How Armor1 Detects This

Armor1's MCP server source code scanning performs taint flow analysis: it traces user input from MCP tool parameters through the call graph to execution sinks, and checks whether any sanitizers along the path adequately handle the target environment.

When run against magento2-dev-mcp, the scan identified both vulnerable code paths and flagged the sanitizer as inadequate for Windows cmd.exe. The findings were classified as high-severity code execution risks. The scan doesn't depend on CVE databases: it reads the code and evaluates what the code does.

This is the difference between reactive and proactive scanning. CVE-based dependency scanning tells you a vulnerability exists after a researcher files an advisory and the databases index it (typically 24-72 hours after disclosure). Source code analysis tells you the pattern exists from the moment it appears in the codebase.

Two things you can do right now, both free:

1. See the risk of any MCP server in your environment in Armor1's public catalog

2. Cover your entire agentic stack (every app, MCP, tool, skill, and plugin) by signing up free at app.armor1.ai

Remediation Summary

Package Affected
@elgentos/magento2-dev-mcp

Versions
<= 1.0.2

Status
Patched (PR #5)

Action
npm update @elgentos/magento2-dev-mcp

Verify your version: npm list @elgentos/magento2-dev-mcp

For your own MCP servers: replace string-based shell command construction with execFile(command, [userInput]).

CVE-2026-35030 (CVSS 9.4): How LiteLLM's JWT Cache Fails and How to Rotate Credentials After the Supply Chain Attack

Armor1 — Thu, 16 Apr 2026 01:04:19 +0000

Introduction

Two critical CVEs in LiteLLM landed this week. CVE-2026-35030 is CVSS 9.4. CVE-2026-35029, CVSS 8.7, chains into remote code execution on the proxy. Both are patched in 1.83.0. Running alongside them: the LiteLLM supply chain attack that has been active since mid-March claimed its first named victim, Mercor, with 4 TB of data exfiltrated and 33,185 unique secrets compromised.

This covers the mechanics of both CVEs, how to verify your exposure, and a credential rotation checklist if you installed the compromised versions.

CVE-2026-35030: The JWT Cache Problem

LiteLLM caches OIDC userinfo to avoid querying the identity provider on every request. The cache key is the first 20 characters of the JWT token.

JWT tokens from the same OIDC provider share algorithm metadata in the header, which means their base64 representations often start with the same characters. Two tokens from the same provider frequently share the same first 20 characters and therefore the same cache key. An authenticated low-privilege user can obtain a token from the same identity provider and have their requests served as a cached high-privilege user. No credential theft needed.

Conditions: Requires enable_jwt_auth:true. Not enabled by default. The fix in 1.83.0 uses a full token hash as the cache key.

CVE-2026-35029: The Config Endpoint

The /config/update endpoint manages proxy settings, environment variable overrides, and pass-through handler registration. Handlers are Python callables the proxy executes during request processing.

The endpoint was documented as admin-only. Authorization was not enforced. Any authenticated user could call it.

The full attack chain combining both CVEs:

Use CVE-2026-35030 to impersonate an admin via cache collision
Call /config/update as that admin to register a malicious handler
The handler executes arbitrary Python on the LiteLLM proxy
Read credentials, move laterally

Both CVEs are fixed in 1.83.0.

Check and Patch

pip show litellm

If below 1.83.0:

pip install --upgrade litellm

If you cannot upgrade immediately: disable enable_jwt_auth and restrict /config/update to trusted network segments only.

The Supply Chain Attack: 1.82.7 and 1.82.8

Separate from the CVEs, but overlapping the same window. TeamPCP published trojanized versions 1.82.7 and 1.82.8 to PyPI in mid-March. The infostealer targeted credential storage specific to AI dev environments: .env files, ~/.aws/credentials, shell profiles, terminal history, IDE settings, and agent memory files.

Scope as of April 6: 6,943 compromised developer machines, 33,185 unique secrets extracted, 3,760 still valid. 59% CI/CD runners. Mercor confirmed as the first named victim: 4 TB including source code, databases, cloud storage, and verification workflows.

LiteLLM is a dependency for 1,705 PyPI packages including dspy (5M monthly downloads), opik (3M), and crawl4ai (1.4M). A developer who installed any of these in a fresh environment during March may have pulled the trojanized code indirectly.

pip show litellm | grep Version

If you see 1.82.7 or 1.82.8, proceed to credential rotation.

Credential Rotation Checklist

Cloud credentials:

AWS: create a new access key, delete the old one, review CloudTrail for unusual API calls
GCP: rotate service account keys, check audit logs
Azure: rotate Key Vault secrets, check activity logs

API keys and shell history:

Check every .env file in repositories the machine accessed. Rotate anything there.
cat ~/.bash_history and cat ~/.zsh_history. Any key in either file should be considered compromised.

SSH keys:

ssh-keygen -t ed25519 -C "new-key", remove the old public key from ~/.ssh/authorized_keys on all servers, update in GitHub/GitLab.

CI/CD:

Rotate all secrets in your CI/CD system.
Audit pipeline execution history for March. Look for unusual outbound network calls.

How Armor1 Catches This

This is the kind of vulnerability Armor1's dependency scanner catches automatically. For MCP servers listing LiteLLM as a dependency, the dependency risk scan flags CVE-2026-35030 (CVSS 9.4) and CVE-2026-35029 (CVSS 8.7) for any server running litellm < 1.83.0.

Run a scan on your MCP servers: https://dub.sh/ltQxgD8, free, no credit card.

NomShub: How to Check If Your Mac Was Affected by the Cursor Sandbox Escape

Armor1 — Fri, 10 Apr 2026 22:09:51 +0000

Introduction

In January 2026, Straiker AI disclosed a three-stage attack chain against Cursor, the AI coding editor, on macOS. They named it NomShub. Cursor patched it in version 3.0 on April 2, 2026.

If you use Cursor on macOS and worked with any external or untrusted repositories before that date, there are specific things on your machine to check. This article walks through the attack mechanism, how to look for indicators of compromise, what to do if you find them, and what the fix in Cursor 3.0 actually changed.

How the Attack Works

NomShub chains three distinct stages. Each stage depends on the previous one.

Stage 1: Indirect Prompt Injection

Cursor reads repository content as AI context. README files, configuration files, code comments, documentation. This is by design: the AI needs to understand the project to help with it.

An attacker embeds natural language instructions in any of these files. Not as executable code. As text, the same way a developer would write a comment. When you open the repository and ask the AI anything, the agent processes those instructions as part of its context and follows them.

This is indirect prompt injection. The payload is in content the agent reads as part of its job, not in anything the user typed.

Stage 2: Sandbox Escape via Shell Builtins
Cursor implements a filter called shouldBlockShellCommand to prevent the AI agent from running dangerous commands outside the intended workspace. The filter blocks patterns it recognizes as dangerous.

It does not block shell builtins: export, cd, source, eval. These are built into the shell interpreter itself, not commands the filter tracks.

The NomShub attack chains builtins to achieve what the filter is designed to prevent:

export CWD=~ && echo $CWD && cd $CWD && echo '/tmp/run.sh' > .zshenv

Each component of this passes the filter individually. Together, they navigate from the project directory to the home directory and write a line into ~/.zshenv. That file is a shell startup script: every terminal session that opens afterward executes /tmp/run.sh.

Stage 3: Persistent C2 via cursor-tunnel

Cursor ships with cursor-tunnel, a binary used for remote development via Microsoft Dev Tunnels. It is Apple-signed and notarized. macOS trusts it. Endpoint security tools trust it. Its traffic goes to Microsoft's Azure infrastructure over HTTPS on port 443.

The injected instructions tell Cursor to:

Kill any existing tunnel sessions
Clear cached GitHub credentials
Start a new tunnel session
Print the GitHub device authorization code to the terminal

Cursor does all of this. The authorization code appears in terminal output. The attacker's payload reads it from the output and sends it to attacker-controlled infrastructure. The attacker enters the code into GitHub's OAuth device flow, registers the tunnel under their account, and gains authenticated shell access to your machine via the spawn RPC method.

The .zshenv entry reruns this sequence automatically if the connection drops. The access survives reboots. To anything monitoring your network traffic, it looks like normal Cursor remote development.

Who Is Affected

Cursor users on macOS, running versions prior to 3.0, who opened a repository containing the NomShub payload.

This is macOS-specific. The attack uses cursor-tunnel and shell startup behavior that does not apply in the same way on Windows.

Repositories that could contain the payload include: public GitHub repositories crafted by an attacker, pull requests from external contributors, and dependency repositories that an AI agent reads as context while working on a project.

How to Check Your Machine

Run these checks now if you were on a Cursor version earlier than 3.0 on macOS.

Check 1: ~/.zshenv
cat ~/.zshenv

If you see any entries that reference /tmp/ paths, shell scripts you don't recognize, or lines you didn't write, treat that as a potential indicator of compromise. Document what you find before removing anything.

Check 2: GitHub Device Authorizations

Go to github.com/settings/connections. Look for any Dev Tunnel entries you didn't set up yourself. If you see an unrecognized tunnel registration, revoke it immediately.

Check 3: Running Processes

ps aux | grep cursor-tunnel

If cursor-tunnel is running and you haven't intentionally started a remote development session, investigate.

Check 4: Shell History

cat ~/.zsh_history | grep .zshenv

Look for any commands that wrote to .zshenv during your Cursor sessions.

What to Do If You Find Something

If any of the above checks returns unexpected results, treat the machine as potentially compromised.

Remove the suspicious .zshenv entries. Open the file in a text editor and delete the lines you don't recognize.
Revoke all GitHub device authorizations under Settings > Connections.
Rotate credentials stored in locations the Cursor process could access: environment variables, any .env files in projects you worked on during the affected period, SSH keys, and cloud credentials if Cursor had access to terminal sessions where those were active.
Check for processes running from /tmp/ paths and terminate them.

If you cannot account for the source of a .zshenventry, rotate the credentials accessible from that machine before relying on it for sensitive work.

What Cursor 3.0 Changed

The patch in Cursor 3.0 strengthens shouldBlockShellCommand to address the builtin chaining gap. The specific export + cd + source + eval combination that NomShub uses no longer passes the filter.

Cursor has not published a detailed changelog for the security fix as of this writing. The Straiker AI disclosure was coordinated, and the patch was in the April 2 release.

Why This Problem Is Bigger Than the Patch

The NomShub fix closes a specific sandbox gap in Cursor 3.0. The structural problem it documents is not closed anywhere.

AI coding tools read repository content as instructions. They run commands autonomously. They ship with legitimate remote access binaries used for real product features. Every repository that an AI agent reads as context is a potential attack surface.

Palo Alto's Unit 42 documented Chinese APT Stately Taurus using VS Code's remote tunnel feature for persistent access against Southeast Asian government targets in September 2024. NomShub demonstrates that the technique does not require the attacker to compromise the machine first. It can be delivered through natural language in a file the agent reads as part of doing its job.

The broader practice this points to: treat repository content as potentially untrusted input, the same way you treat user input in applications you build.

How Armor1 Prevents This

Armor1 enforces local runtime policies via hooks inside Cursor, positioned directly in the execution path. This is where NomShub's kill chain is stopped.

Shell execution hooks evaluate command chains before they run. The export+cd+eval sequence NomShub uses to escape the workspace and write to ~/.zshenv is blocked at the hook layer before the shell interpreter sees it. File access policies prevent writes to sensitive system paths, so even if a command chain reaches that stage, the ~/.zshenv modification is denied.

These hooks enforce independently of Cursor's native shouldBlockShellCommand filter, which is what NomShub bypassed. The hook layer sits inside the execution path and applies regardless of whether execution is inside or outside the sandbox boundary.

Armor1's AI coding client catalog covers 30+ tools across 16 security categories including Sandbox Isolation, Filesystem Isolation, Script Hooks, and Network Egress, giving teams a governance baseline alongside the runtime enforcement layer.
For teams managing AI coding client security: https://tinyurl.com/Armor1AIMCP3