DEV Community: Armor1

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