When "AI Infrastructure" Means "Remote Shell": Three Logic-Class RCEs, Reproduced

Scope and honesty note. This is a defensive technical analysis of three already-public, already-patched CVEs that we reproduced end-to-end in an isolated lab — to validate our tooling and to characterize a bug class defenders routinely underestimate. These are N-day reproductions, not novel discoveries. Every vendor has shipped a fix; upgrade first, read second. Turnkey weaponization specifics are deliberately withheld: the goal is understanding and defense, not a copy-paste attack guide.

TL;DR

| CVE | Component | Class | Min. role | Primitive | Fixed in | |-----|-----------|-------|-----------|-----------|----------| | CVE-2026-42271 | LiteLLM (AI gateway) 1.74.2–1.83.6 | Command injection via MCP stdio test endpoint | L1 (any valid proxy API key)¹ | Container root RCE | 1.83.7 | | CVE-2026-39987 | marimo (reactive notebook) < 0.23.0 | Pre-auth WebSocket → PTY | L0 (unauthenticated) | Shell in server's user context | 0.23.0 | | CVE-2026-34197 | Apache ActiveMQ Classic < 5.19.4 / 6.0.0–6.2.2 | Jolokia → Spring XML code injection | L1 (web-console creds)² | Broker JVM root RCE | 5.19.4 / 6.2.3 |

¹ The endpoint enforces no role check — any valid proxy API key works, not just the master key. Chained with CVE-2026-48710 (a Starlette Host-header validation bypass) the authentication requirement drops entirely, yielding unauthenticated RCE at CVSS 10.0. CISA added CVE-2026-42271 to its KEV catalog on 2026-06-08 after confirming in-the-wild exploitation. ² Authentication is required in the general case, but on ActiveMQ 6.0.0–6.1.1 an unrelated flaw (CVE-2024-32114) exposes Jolokia without auth, making CVE-2026-34197 effectively unauthenticated there.

The common thread: none of these require a single byte of memory corruption. No ASLR bypass, no info-leak, no ROP chain. They are pure logic / injection flaws — send the request, get the shell. That is why they are dangerous, and why memory-safety-centric defenses miss them.

Two of the three sit inside the AI/ML tooling stack — an LLM gateway and a notebook server. As organizations rush AI infrastructure into production, that software inherits the same web-security fundamentals as everything else, and often skips them.

The part that should worry you: time-to-exploit

These are not theoretical. The window between disclosure and mass exploitation has collapsed to hours:

• marimo was weaponized in under 10 hours from advisory publication — with no public PoC — per the Sysdig Threat Research Team, which logged a full credential-theft operation in under three minutes on a honeypot. Sysdig later reported 662 exploit events across 11–14 April from 11 source IPs in 10 countries, ending in deployment of an NKAbuse blockchain-C2 botnet. CISA KEV: 2026-04-23.
• LiteLLM went into active exploitation fast enough for CISA to add it to KEV on 2026-06-08 with a federal remediation deadline of 22 June.
• ActiveMQ exposes a latent behavior that has been present for roughly 13 years; Horizon3.ai found it (with AI assistance) and public proof-of-concept code now exists.

An attacker in 2026 does not need your PoC. They need the advisory text and a WebSocket client.

Why "logic RCE" deserves more respect than a heap overflow

Security attention gravitates to memory-corruption bugs: hard to find, hard to exploit, impressive when weaponized. But from an operator's risk model, a logic RCE is frequently worse:

• Deterministic. No probabilistic heap grooming; the exploit works 20/20, every time, on every target build.
• Portable. No dependence on libc version, allocator, or mitigations.
• Low skill floor. A well-formed HTTP request or WebSocket frame is the entire "exploit."

In our lab each of the three reproduced at 100% stability across repeated runs. That reliability is the whole point.

1. CVE-2026-42271 — LiteLLM: a test endpoint that spawns processes

Root cause. LiteLLM exposes MCP (Model Context Protocol) "test" endpoints (/mcp-rest/test/connection and /mcp-rest/test/tools/list) that accept a full transport specification. When asked for a stdio transport, the server spawns a child process from an attacker-supplied command/args/env — no sandbox, no allow-list — with the privileges of the proxy process. A feature meant to preview MCP tool wiring is a general-purpose process launcher.

Trigger role. L1 — the caller needs only a valid proxy API key. The endpoint enforces no role check, so even a low-privilege internal-user key works, not just the master key. That bar is lower than it looks: API keys are frequently weak, hard-coded in compose files, shared across environments, or leaked in logs. Once any key is known (or default), the endpoint yields a container-root shell. Chained with CVE-2026-48710 (a Starlette Host-header validation bypass, "BadHost"), the authentication requirement disappears entirely — the pair Horizon3.ai assessed at CVSS 10.0, and the reason it reached CISA KEV.

Why it matters for AI infra. LiteLLM commonly runs as the central egress point for an org's LLM traffic — it holds provider API keys and sits on internal networks. Root inside that container is a launch pad to those secrets and to lateral movement.

Reproduction (details withheld). In an isolated container running the vulnerable version (1.82.6, within the affected range), an authenticated POST to the MCP test endpoint requesting a stdio transport with a shell command executed that command as uid=0(root), confirmed by reading a marker file back out of the container. Full request bodies are withheld.

Defense.

• Upgrade to 1.83.7 or later (and Starlette to 1.0.1+ to close the unauthenticated chain). Move to a current maintained release to clear related 2026 LiteLLM CVEs.
• Treat every proxy API key — master and internal-user alike — as a crown-jewel secret; rotate any that has touched a repo, image, or log.
• Network-isolate the gateway; never expose the admin/test surface to untrusted networks.
• If you must run the vulnerable version, block the /mcp-rest/test/ routes at the reverse proxy.

2. CVE-2026-39987 — marimo: an unauthenticated shell over WebSocket

Root cause (source-level). marimo's terminal WebSocket handler (/terminal/ws) gates access on exactly one condition — that the server is in edit mode. It does not call validate_auth() and carries no @requires("edit") decorator. On connection it forks a real PTY and pipes WebSocket text straight into the shell. Starlette's AuthenticationMiddleware marks failed auth as an unauthenticated user but does not reject the socket, so with no endpoint-level enforcement the connection is accepted even when authentication is enabled. Because marimo edit runs in edit mode by default, any network-reachable instance is a pre-authentication remote shell.

Trigger role. L0 — no credentials at all. This is the most severe of the three by access model: reachability equals compromise.

Why it matters. Notebook servers are spun up casually — on a workstation, a shared box, a cloud VM "just for a demo" — and are often bound to 0.0.0.0 or exposed through a tunnel without a second thought. Unlike a login page, there is no auth wall to misconfigure; the vulnerability is the missing wall. The shell runs with the marimo process's privileges — which in many containerized deployments is root.

Reproduction (details withheld). Connecting to the terminal WebSocket of a vulnerable instance (0.22.5) without any token and sending shell input executed commands in the server's user context, verified via a written proof file, stably across repeated attempts.

Defense.

• Upgrade to 0.23.0 or later (fix in marimo PR #9098).
• Never bind a notebook/edit server to a public interface; keep it on 127.0.0.1 behind an authenticated proxy or SSH tunnel.
• Treat notebook environments as high-risk: avoid storing .env files or production credentials there, and rotate secrets if exposure is suspected.
• Monitor /terminal/ws for unexpected shell spawning and anomalous process trees.

3. CVE-2026-34197 — Apache ActiveMQ: Jolokia as a Spring-bean detonator

Root cause. ActiveMQ Classic's web console ships Jolokia (JMX-over-HTTP) with a default policy permissive enough to invoke management operations on the broker's MBeans — including one that adds a network connector. By pointing a broker configuration at an attacker-hosted Spring XML, the XML is loaded by a ResourceXmlApplicationContext that instantiates all singleton beans before the broker validates the configuration. A bean that runs a process therefore executes during load, before any safety check — classic Spring-XML code injection reached through a management interface. The over-permissive policy traces back to the fix for CVE-2022-41678, which allowed all operations on ActiveMQ's own MBeans so the console kept working.

Trigger role. L1 — valid web-console credentials. The default admin/admin remains widespread, which lowers the bar substantially; and on 6.0.0–6.1.1, CVE-2024-32114 removes the credential requirement entirely. Success yields root on the broker JVM's container in our lab.

Why it matters. Message brokers are trust hubs — they sit between services and carry sensitive traffic. A code-injection path from an exposed console to broker-root is a high-value pivot.

Reproduction (details withheld). Against a default-credential vulnerable broker (6.2.0, within the affected range), a Jolokia management call that caused the broker to load an attacker-hosted (lab-local) Spring XML resulted in uid=0(root) execution, reproduced across independent runs. The reliability-critical management-call and broker-configuration details are withheld; they add offensive utility without aiding defense.

Defense.

• Upgrade to 5.19.4 / 6.2.3 or later (Horizon3 recommends 5.19.6 / 6.2.5 to be conservative).
• Change default console credentials everywhere; treat admin/admin as an open door.
• Restrict or disable Jolokia; tighten its access policy to deny exec on broker MBeans.
• Never expose the web console (port 8161) to untrusted networks.

Detection: what to look for right now

If you cannot patch immediately, these behavioral signatures are your fallback. Code execution often happens before the error appears in the logs — treat these as high-priority, not informational.

| Target | Log / behavioral signal | Notes | |--------|-------------------------|-------| | LiteLLM | Unexpected child processes under the proxy (sh, bash, python, node, curl, wget, nc); requests to /mcp-rest/test/ | Outbound connections from proxy subprocesses to untrusted hosts are a strong indicator | | marimo | Any inbound connection to /terminal/ws; PTY/shell spawned by the notebook process | On a correctly-deployed instance there should be no external /terminal/ws traffic at all | | ActiveMQ | Broker log lines referencing vm:// URIs with brokerConfig=xbean:http; new network connectors you did not create | The advisory's "no BrokerService instance for resource" message can appear after the bean already executed |

Cross-cutting lessons

1. AI infrastructure is web infrastructure. LiteLLM and marimo fail on fundamentals — an unauthenticated socket, a process-spawning test endpoint — not on anything AI-specific. Apply the same review rigor you apply to any internet-facing service.
2. "Internal only" is a control, not a wish. All three are devastating precisely when a service assumed to be private becomes reachable. Enforce network segmentation, then verify it.
3. Defaults are exploits in waiting. A default master key, a default edit mode, admin/admin — each converts a "requires privilege" bug into a practical one.
4. Logic RCE beats memory RCE for reliability. Defenses that focus only on memory safety will not see these. Model your attack surface by reachable behavior, not just by unsafe code.

FAQ

Are these still dangerous if I've patched? No — a patched, current build closes each of these. The risk is entirely in unpatched, network-reachable instances. Confirm your fleet versions against the table above.

Is publishing this responsible? All three are public and patched, and two are already exploited in the wild; defenders need to map the identifiers to their assets. We withhold turnkey payloads and the reliability-critical weaponization details, which add nothing to defense.

Which one should I remediate first? By access model, marimo (L0, unauthenticated) is the sharpest edge if you run it exposed. LiteLLM and marimo are confirmed in active exploitation (both in CISA KEV); ActiveMQ has public PoC code and reported scanning. Prioritize by exposure, not by CVSS alone.

Responsible-use statement

Every issue here is public and patched; we reference the CVE identifiers so defenders can map them to their fleets. We intentionally omit turnkey payloads and the reliability-critical weaponization specifics. Our reproductions ran entirely in an isolated local lab with zero outbound traffic to any third-party system — consistent with our policy of validating exploitability only against infrastructure we own. If you run any of the affected components: patch, rotate credentials, and confirm your network boundaries.

— Innora Security Research