CVE-2026-26029 is a CVSS 7.5 HIGH remote code execution vulnerability in sf-mcp-server — the official MCP integration for Salesforce CLI operations. This is not some hobbyist side-project someone knocked together on a weekend. Salesforce runs sales, service, and marketing operations for some of the largest organisations on the planet.
When a company at that scale ships a shell injection flaw in its MCP integration, the risk picture changes for every security team. It also raises a harder question: if this happened to Salesforce, what does that mean for every other MCP server your organisation is running?
This case study walks through how CVE-2026-26029 works, what the Salesforce context means for enterprise risk, and what STDIO transport architecture has to do with all of it. We cover the LiteLLM patch for CVE-2026-30623, the responsible disclosure timeline compliance teams need for audit trails, and a triage checklist for teams running LiteLLM, Windsurf, or Cursor.
For the broader picture of how this vulnerability class was found across 7,000+ MCP servers, see our MCP supply chain overview.
What Is CVE-2026-26029 and How Does the Salesforce MCP RCE Work?
CVE-2026-26029 is a CWE-78 OS command injection flaw in akutishevsky/sf-mcp-server, a Node.js package that wraps the Salesforce CLI through an MCP STDIO interface. CVSS base score: 7.5 HIGH, vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H. If an attacker successfully exploits it, they get arbitrary shell command execution with the full privileges of the MCP server process.
The flaw comes down to a single API choice. The package used child_process.exec to run Salesforce CLI commands. exec passes the command string to the OS shell — which means shell metacharacters like ;, &&, and | embedded in the command string are executed as shell operators. Concatenate user-controlled input into that string, and an attacker can break out of the intended command and run whatever they like.
The safe alternative is child_process.execFile. It runs the specified file directly without invoking a shell — metacharacters have no special meaning, only the intended binary runs. Fix commit 99fba0171b8c22b5ee3c0405053ccfd2910a066d replaces exec with execFile. The GitHub Security Advisory is GHSA-h4w9-g9c5-vfwq.
To put the CVSS score in plain language: network-reachable, no account on the target required, the user must run a malicious MCP configuration, and confidentiality, integrity, and availability are all rated HIGH impact. CWE-78 — “Improper Neutralisation of Special Elements Used in an OS Command” — is the assigned weakness type. The code accepts user-controlled input and passes it straight to a shell without stripping the dangerous characters.
One thing compliance teams should note: the NVD record for CVE-2026-26029 is flagged “not prioritised for NVD enrichment due to resource constraints.” If your organisation relies solely on NVD enrichment, you may have underweighted this one. GHSA-h4w9-g9c5-vfwq is the more complete record to work from.
The child_process.exec pattern turned up across dozens of MCP projects in 2026. What made the Salesforce case different was demonstrating that the STDIO architectural flaw OX Security documented across the MCP ecosystem had reached a vendor whose software sits inside Fortune 500 production infrastructure.
Why a Salesforce CVE Changes the Risk Calculus for Enterprise Security Teams
When sf-mcp-server shows up in the CVE database at CVSS 7.5 HIGH, STDIO command injection has reached enterprise production software at scale. Any organisation running MCP-integrated enterprise applications is now in scope for the same class of attack.
OX Security audited 7,000+ publicly accessible MCP servers and confirmed they could execute commands on six live production platforms. Salesforce is the enterprise-grade proof point in that set. The full OX Security audit findings cover the scope: 150M+ downloads, up to 200,000 vulnerable instances, and OX researchers successfully poisoning 9 of 11 MCP registries they tested.
This is not an isolated event. The Authzed “Timeline of MCP Security Breaches” (updated April 2026) documents escalating MCP incidents from April 2025 onward — WhatsApp MCP exfiltration, the Anthropic MCP Inspector RCE (CVE-2025-49596), mcp-remote OS command injection (CVE-2025-6514) — before reaching the enterprise incidents of early 2026. CVE-2026-26029 is a data point in a trend, not an anomaly.
The attack surface exists wherever an MCP server wraps a CLI tool and accepts input from an AI agent’s tool call results. The C:H/I:H/A:H impact rating means all three pillars of the CIA triad are at HIGH — the threshold that triggers mandatory remediation timelines under SOC 2 and ISO 27001, and the number compliance teams take to boards and insurers.
MCP STDIO Transport vs. HTTP/SSE Transport — What the Salesforce Case Reveals
STDIO transport runs an MCP server as a local subprocess. The host application communicates through standard input and output — no network, no authentication boundary, no audit log. Two parameters control that launch: command and args. In Anthropic’s official MCP SDKs, the StdioServerParameters class handles these — without validation.
HTTP/SSE transport is different. It runs the MCP server as a separate process with a network endpoint. The client sends HTTP requests and receives server-sent events. There is an authentication boundary (OAuth 2.1 per the MCP spec), observable HTTP logs, and no subprocess spawned for every tool call. No shell is involved, so there is no metacharacter injection surface.
For CVE-2026-26029, the practical difference is this: an attacker who supplies a crafted string as a command parameter via the STDIO configuration interface gets arbitrary OS command execution. With HTTP/SSE, that pathway simply does not exist.
STDIO is the default in Claude Desktop, Cursor, and Windsurf. So the default is the dangerous option.
When OX Security reported this to Anthropic, Anthropic classified the STDIO subprocess behaviour as “expected” and declined to modify the architecture. Input sanitisation, they said, is the client developer’s responsibility. That means individual vendor patches reduce per-package risk without resolving the systemic exposure. Any new STDIO MCP package can introduce the same class of vulnerability.
The architectural fix for production enterprise deployments is disabling STDIO transport at the configuration layer and migrating to HTTP/SSE. If an STDIO MCP server is accessible from outside a developer’s local machine, or handles credentials, it belongs on the migration list. See our article on the JFrog Universal MCP Registry and enterprise AI governance for tooling that supports this transition.
LiteLLM CVE-2026-30623: Patch Notes, Verification, and What to Do Now
CVE-2026-30623 is an authenticated RCE in LiteLLM — the most widely deployed open-source LLM proxy in the affected ecosystem. Same root cause as CVE-2026-26029: StdioServerParameters accepting unsanitised command input. The key difference: CVE-2026-30623 required valid API credentials. Still serious, but lower priority than an unauthenticated RCE.
The fix landed in commit 7b7f304 (PR #25343), first shipping in v1.83.6-nightly on April 21, 2026, then v1.83.7-stable. A new constant MCP_STDIO_ALLOWED_COMMANDS restricts the command field to known MCP launchers: npx, uvx, python, python3, node, docker, deno. Arbitrary executables are blocked at the API layer before reaching the process level. MCP test endpoints now also require the PROXY_ADMIN role.
To verify patch application: confirm v1.83.7-stable or later is installed with commit 7b7f304 / PR #25343 included. Audit existing STDIO MCP configurations — any server whose command falls outside the allowlist will fail to start after upgrade. Add any needed binaries to LITELLM_MCP_STDIO_EXTRA_COMMANDS. Review who holds PROXY_ADMIN access.
One caveat worth flagging: the allowlist is not a complete fix. OX Security documented that argument flags of allowed commands can be abused — npx -c <malicious-payload> — and bypassed similar allowlist implementations in both Upsonic (CVE-2026-30625) and Flowise using the same technique. Treat v1.83.7-stable as risk reduction, not closure. HTTP/SSE migration remains the architectural fix.
The Responsible Disclosure Timeline: Who Knew What and When
No single public document assembles this sequence. Here it is, in the format compliance and risk teams need for audit trails.
February 11, 2026: CVE-2026-26029 published to NVD. GHSA-h4w9-g9c5-vfwq published on GitHub. NVD record carries the “not prioritised for enrichment” flag.
Before April 15, 2026: OX Security notifies affected vendors privately. Anthropic is notified and declines to modify the STDIO specification. Most vendors patch before the public advisory.
April 15, 2026: OX Security publishes “The Mother of All AI Supply Chains” — covering 7,000+ MCP servers audited, six confirmed-vulnerable production platforms, and 30+ responsible disclosures.
April 20, 2026: The Hacker News amplifies the OX advisory. Organisations that had not yet patched entered an active exposure window.
April 21, 2026: LiteLLM ships v1.83.7-stable, patching CVE-2026-30623. The most operationally relevant post-advisory date for teams running LiteLLM.
The gap between NVD publication (February 11) and the OX advisory (April 15) is 63 days. During that window, organisations running NVD-based scanning had this CVE in scope — but without the OX advisory context, it was hard to prioritise. The “not prioritised for enrichment” flag made it worse. If your organisation was scanning in February 2026, you had a duty to investigate CVE-2026-26029. Whether a remediation action followed is a record-keeping question risk teams may need to answer.
Immediate Triage Checklist for Teams Using MCP Integrations
Complete these actions this week. Specific and sequenced — not generic security hygiene.
1. Check sf-mcp-server. If your environment uses akutishevsky/sf-mcp-server, confirm fix commit 99fba01 is present. Cross-reference with GHSA-h4w9-g9c5-vfwq. If you cannot confirm the fix, treat the installation as unpatched and replace the STDIO integration with an HTTP/SSE-based Salesforce endpoint.
2. Upgrade LiteLLM. Confirm v1.83.7-stable or later is installed with commit 7b7f304 / PR #25343. Audit existing STDIO configurations — anything outside the allowlist fails to start post-upgrade. Review PROXY_ADMIN access. Allowlist bypass via argument flags remains a documented risk.
3. Windsurf — highest urgency. CVE-2026-30615 is zero-click: malicious instructions in attacker-controlled HTML can register a malicious STDIO server and execute arbitrary commands without user interaction. Verify Windsurf is on the latest patched release. Audit all registered MCP servers. Treat any STDIO server you did not explicitly register as suspect.
4. Cursor. CVE-2025-54136 (Critical) requires one user confirmation step — lower urgency than Windsurf but still active. Verify Cursor is on the latest patched release, review active MCP server configurations, and investigate any unexpected STDIO server registrations.
5. Audit all STDIO configurations. List every MCP server registered in your AI coding tools and proxy configs. For each STDIO server: verify it is patched, confirm who added it, and assess whether HTTP/SSE migration is feasible. Local-only deployments are not inherently safe — developer machines hold git tokens, signing keys, and AWS credentials.
6. Plan HTTP/SSE migration. STDIO transport restriction is the architectural fix — it eliminates the subprocess command-execution pathway at the configuration level. Prioritise HTTP/SSE for any STDIO server accessible from outside the developer’s local machine, handling credentials, or part of a production integration.
See our MCP Security Playbook for a prioritised remediation framework covering server inventory, transport restriction, permission scoping, and registry adoption.
Frequently Asked Questions
Is CVE-2026-26029 patched?
Yes. Fix commit 99fba0171b8c22b5ee3c0405053ccfd2910a066d replaces child_process.exec with child_process.execFile, closing the shell injection pathway. GHSA-h4w9-g9c5-vfwq documents the fix. Verify the commit is present in your installed version.
Which version of sf-mcp-server is safe?
Check that fix commit 99fba01 is present via the repository’s commit history on GitHub. Use GHSA-h4w9-g9c5-vfwq as your primary reference. Regardless of patch status, consider HTTP/SSE migration for any production deployment.
Does switching to HTTP/SSE transport fully mitigate the Salesforce RCE?
Yes, for the STDIO command injection vector — HTTP/SSE does not spawn subprocesses, so there is no metacharacter injection pathway. That said, HTTP/SSE introduces its own attack surface that must be properly secured. “No STDIO” is necessary but not sufficient for a complete enterprise MCP security posture.
What is the difference between CVE-2026-26029 and CVE-2026-30623?
Both share the same root cause — StdioServerParameters accepts unsanitised command input. CVE-2026-26029 affects sf-mcp-server with an unauthenticated exploitation path. CVE-2026-30623 affects LiteLLM and requires valid API credentials. Patched via commit 99fba01 and v1.83.7-stable respectively.
Why did Anthropic not patch the MCP protocol after the OX Security disclosure?
Anthropic classified the STDIO subprocess behaviour as “expected” — the spec intentionally allows MCP servers to spawn subprocesses. Individual vendor patches reduce per-package risk but do not resolve the systemic flaw.
Can someone hack my company through an MCP plugin?
Yes, under the right conditions. CVE-2026-26029 and CVE-2026-30623 both demonstrate that attacker-controlled input reaching an STDIO MCP configuration results in arbitrary OS command execution. Windsurf’s CVE-2026-30615 is zero-click — no user interaction required.
What is CWE-78 and why does it apply here?
CWE-78 (Improper Neutralisation of Special Elements Used in an OS Command) means the code accepts user-controlled input and passes it to a shell without removing dangerous characters. It applies because sf-mcp-server passed attacker-controlled values directly to child_process.exec. NVD formally assigned CWE-78 for this CVE.
What does the CVSS 7.5 HIGH score mean for compliance?
Network-reachable, no privileges required, user interaction needed, HIGH impact across confidentiality, integrity, and availability. HIGH severity triggers mandatory remediation timelines under SOC 2 and ISO 27001, and is the threshold insurers and boards take seriously.
Where can I find the LiteLLM v1.83.7-stable release notes for CVE-2026-30623?
PR #25343 and commit 7b7f304 in the LiteLLM GitHub repository. The formal CVE is CVE-2026-30623. v1.83.6-nightly was the first build to include the fix (April 21, 2026), followed by v1.83.7-stable.
What triage steps should I take for Windsurf specifically?
Windsurf is highest urgency because CVE-2026-30615 is zero-click — a malicious STDIO server can be registered without user interaction via prompt injection. Verify Windsurf is on the latest patched release, audit all registered MCP servers, and treat any STDIO server you did not explicitly register as suspect.
Is the LiteLLM command allowlist sufficient, or can it be bypassed?
No, not on its own. OX Security demonstrated that argument flags of allowed commands can be abused — npx -c <malicious-payload>. Treat v1.83.7-stable as risk reduction and pursue HTTP/SSE migration as the architectural fix.
What is the MCP Model Context Protocol and why does its STDIO transport create security risks?
MCP is Anthropic’s specification for letting AI agents invoke external tools at runtime. STDIO transport runs the MCP server as a local subprocess — no authentication boundary, no audit log, and any attacker-controlled value reaching the command parameter executes as an OS command with the process’s privileges. HTTP/SSE transport does not have this subprocess execution pathway.
CVE-2026-26029 is one data point in a broader MCP security landscape that spans 14 CVEs, 7,000+ vulnerable servers, and a structural architectural flaw that patching alone will not resolve. For the complete picture — including the full CVE inventory, governance tooling options, and a prioritised remediation framework — see our broader MCP security landscape.
