The infrastructure that connects AI models to enterprise tools and cloud accounts has become a serious new attack surface, according to a sustained honeypot study covering roughly 90 days of live intrusion attempts. Researchers found attackers systematically fingerprinting and exploiting exposed AI gateways, model proxies, and agent frameworks — and in several cases, chaining vulnerabilities into full remote code execution.

A New Kind of Cloud Entry Point

Security researchers deployed honeypots that mimicked a range of widely used AI services, including LiteLLM, Model Context Protocol (MCP) servers, LangChain, Flowise, Langflow, OpenWebUI, and Node-RED. Over the observation period, they logged tailored intrusion techniques for each platform, suggesting attackers already understand the specific quirks of these tools rather than treating them as generic web applications.

The concern goes well beyond a single compromised app. AI proxies frequently centralize API keys for multiple model providers alongside broad cloud permissions, meaning a weak deployment can become a bridge into far more valuable data, paid model usage that gets billed to the victim, and deeper internal systems.

Chaining Flaws in LiteLLM and MCP

One campaign focused on internet-facing MCP services, which let AI agents call into databases, code repositories, messaging platforms, and internal APIs on an organization’s behalf — a design that multiplies the damage from any single takeover.

Attackers were observed exploiting two LiteLLM vulnerabilities in tandem:

• An MCP Gateway authentication bypass that, remarkably, could be defeated with a one-character bearer token.
• A command-injection flaw in a test endpoint, exploited by submitting a fabricated MCP server configuration whose “command” field launched a Python-based downloader and cryptomining payload while still returning a convincing handshake to avoid suspicion.

That second flaw can reportedly also be chained with a separate host-header bypass affecting the Starlette framework, yielding unauthenticated remote code execution outright. External researchers have linked this particular exploitation chain to the Qilin ransomware group, underscoring that AI infrastructure is now squarely on the radar of financially motivated ransomware operators, not just opportunistic script kiddies.

Prompt Injection as a Delivery Mechanism

A separate set of attacks skipped traditional exploitation entirely and instead relied on blind prompt injection against agent frameworks. In these cases, intruders inserted hidden instructions designed to make an agent with shell access execute a command on their behalf. Attackers reportedly used DNS lookups to quietly confirm code execution without generating any visible output that might trigger alerts, and retrieved follow-on payloads from Pastebin using Base64 encoding to slip past basic log filters and content inspection.

These techniques led to successful deployment of the XMRig cryptominer on compromised Node-RED systems. In one particularly deceptive case involving Langflow, the malicious miner binary was staged inside a hidden .claude directory and renamed to blend in with legitimate development tooling — a tactic clearly designed to survive a cursory glance from an administrator.

API Keys as the Real Prize

On compromised LiteLLM deployments, attackers went further than opportunistic mining. They queried the running Python process directly to recover the proxy’s master key from memory — a location where it may never be written to disk or appear in a configuration file, making it invisible to standard secret-scanning tools. From there, they enumerated backend models and configuration paths to select the most valuable targets for key theft or capacity abuse, effectively turning the AI gateway into a credential store that could be milked long after the initial compromise.

Indicators and Recommendations

Investigators tied the campaigns to a set of infrastructure, including malware download and cryptominer command-and-control servers, Monero mining pools and proxies shared across multiple campaigns, and staging directories such as /tmp/.dbus-cache/. Organizations running any of the affected platforms should treat this as an active, evolving threat rather than a theoretical one.

Recommended steps include:

• Inventory every AI service in use — proxies, MCP servers, agent frameworks — and assign clear ownership.
• Require authentication before any of these services are exposed externally, and patch known CVEs immediately.
• Treat MCP services as a distinct exposure zone with its own permission review, separate from the underlying application.
• Limit outbound network access and the permissions granted to agents and proxies, rather than trusting the model or interface alone.
• Deploy runtime monitoring for AI servers that spawn shells, download archives, or launch unexpected child processes.
• Rotate any credentials that may have been exposed and treat shell access granted to an agent as a high-risk design decision requiring extra scrutiny.

As organizations rush to deploy agentic AI tooling, this research is a reminder that the security fundamentals haven’t changed — exposed services, weak authentication, and excessive trust in unvalidated input remain the primary way in. What has changed is the blast radius: a misconfigured AI gateway can now hand attackers the keys to cloud accounts, paid model subscriptions, and every system that gateway touches.