NVD published CVE-2026-30623 on 15 July 2026. It describes remote code execution in LiteLLM's MCP server creation feature: a user supplies a JSON config with a command and args, and LiteLLM runs them on the host without validation. The flaw was first reported by OX Security on 15 April as part of its research on command injection in the stdio transport of Anthropic's MCP SDK, and LiteLLM published its response on 21 April.
Two accounts differ on one point that matters for triage. The NVD record scores it 9.8 and describes it as exploitable remotely without privileges. LiteLLM says the affected endpoints sit behind authentication, so an attacker needed a valid API key.
What's affected
LiteLLM proxy deployments that expose MCP server management. NVD names version 1.18.10. The vendor's fix history is on the 1.83.x line: the fix landed in v1.83.6-nightly and is in v1.83.7-stable and every later release.
The vulnerable surfaces, per LiteLLM:
- MCP server creation and update requests
- The preview endpoints
/mcp-rest/test/connectionand/mcp-rest/test/tools/list - Servers reloaded from config files or the database at runtime
With transport: stdio, the command value went straight into the SDK's stdio parameters and ran as a subprocess of the proxy. An authenticated user who could create MCP servers could therefore run OS commands as the LiteLLM process.
How to check if you're exposed
pip show litellm | grep -i '^version'
docker image ls | grep -i litellm
Look for stdio MCP entries in your config and database:
grep -rn -B2 -A4 "stdio" config.yaml
Any entry whose command is not a launcher you recognize deserves attention. Check your key inventory too: list which API keys can reach the MCP management routes, since older versions did not require the admin role there.
What to do now
- Upgrade to
v1.83.7-stableor later. Nightly users needv1.83.6-nightlyor later. - After upgrading, review existing stdio MCP servers. The fix adds a command allowlist (
npx,uvx,python,python3,node,docker,deno), and entries using other commands will fail to start. - If you need another binary, add it with the
LITELLM_MCP_STDIO_EXTRA_COMMANDSenvironment variable, comma separated. Add only what you must. - Review who holds
PROXY_ADMIN. After the patch, creating MCP servers and using the preview endpoints require that role, and non-admins now get HTTP 403. - If any key you do not fully trust could reach these routes before the upgrade, rotate it and the provider credentials the proxy holds.
How this could have been avoided
- Validate the command, not just the shape. The config was accepted as long as it was valid JSON. An allowlist of launchers, which the fix introduced, would have been the first line.
- Re-check at spawn time. The fix revalidates at
_create_mcp_client, so entries saved earlier cannot slip through from the database or config. - Reserve server creation for admins. Registering an MCP server is closer to installing software than to calling an API. Tying it to an admin role keeps ordinary keys away.
- Keep the proxy's own credentials narrow. A subprocess inherits the proxy's environment, including provider keys, so scoping and rotating those keys reduces what a command can take.
Why it matters
Adding an MCP server over stdio means executing a program. Any product that accepts a command line from a user interface has to treat that field as code. OX Security framed its advisory around the stdio transport in Anthropic's MCP SDK, so the same question applies to any product built on it.
The authentication disagreement is also a lesson. Databases that copy NVD show "no privileges required", the vendor says a key was needed, and both can be partly right for different deployments. When your gateway sits on a shared network with many keys, "authenticated" is a weak guarantee.
Try it yourself
Run grep against your own gateway config for stdio. For each server, write down the exact binary it launches and who approved it. Then compare with the demo below, which walks through setting up an MCP server with controls around it.
Click through it at your own pace, or open it full screen.
Quick check
Which LiteLLM stable release first contains the fix?
v1.83.7-stable. The first nightly with the fix is v1.83.6-nightly.
Which environment variable extends the stdio command allowlist?
LITELLM_MCP_STDIO_EXTRA_COMMANDS, a comma separated list of extra binaries.
