Attacks on AI Infrastructure: 90-Day Honeypot Telemetry

Summary

Wiz's 90-day AI-infrastructure honeypot study documents sustained attacks against services including LiteLLM, Flowise, LangChain, Langflow, ChromaDB, and Ollama. The most concrete vulnerability narrative in the supplied excerpt concerns LiteLLM: attackers exploited an MCP authentication bypass, CVE-2026-59822, and a separate MCP server test-endpoint command injection, CVE-2026-42271. These are observed exploitation findings, not merely hypothetical attack paths.^[1]

The authentication bypass is a fail-open identity check. When bearer-token validation fails, LiteLLM returns an empty UserAPIKeyAuth object without restrictions instead of rejecting the request. Wiz states that even a single-character bearer token grants full MCP access and shows such tokens in requests probing model enumeration. The second vulnerability allows remote code execution through MCP configuration-test endpoints. NHIMG describes the two flaws being chained; the supplied Wiz excerpt independently confirms exploitation of both, but not the complete chain.^[0][1]

NHIMG's secondary account reports post-exploitation activity that included reading the LiteLLM master key from Python process state, harvesting provider API keys, and deploying XMRig miners. The security significance extends beyond the gateway: Wiz directly explains that LiteLLM can concentrate model-provider credentials, cloud IAM access, and connections to internal MCP tools. The separate cloud-metadata pivot described by NHIMG is a research-demonstrated capability, not an established step in the observed honeypot intrusions.^[0][1]

NHIMG identifies versions before 1.84.0 as vulnerable to CVE-2026-59822 and reports its addition to CISA's Known Exploited Vulnerabilities catalogue on 2 September 2026. It recommends upgrading, restricting MCP exposure, replacing default master keys, and rotating credentials held by exposed vulnerable instances. These version, September disclosure, and detailed post-exploitation claims remain secondary-source reporting because the supplied Wiz excerpt ends during its command-injection discussion. No named attacker or victim organization is disclosed.^[0][1]

Attack chain

1. Authentication bypass: Attackers supplied fabricated bearer tokens, including single-character values. Failed LiteLLM token validation yielded an empty, unrestricted authentication object instead of a rejection, allowing MCP access.^[0][1]
2. Model enumeration: Wiz observed single-character bearer tokens in requests probing /v1/models. NHIMG also reports that attackers fingerprinted which models were reachable.^[0][1]
3. Remote code execution: Attackers exploited command injection in LiteLLM's MCP server configuration-test endpoints. NHIMG places this after the authentication bypass in a chained intrusion; the supplied Wiz excerpt reports exploitation of the command injection separately and does not show the full sequence.^[0][1]
4. Credential discovery and collection: According to NHIMG, attackers queried the running Python process for master_key and litellm_master_key_hash rather than relying only on credential files. The account also describes searches for LiteLLM configuration files and harvesting of provider API keys.^[0]
5. Cryptomining and cleanup: NHIMG reports deployment of XMRig miners in locations selected to blend in, followed by deletion of staging directories. The supplied evidence does not provide the actual deployment paths or payload hashes.^[0]

Disclosure timeline

How it works

CVE-2026-59822 affects LiteLLM's MCP authentication handling. In the OAuth2 passthrough setting described by the sources, a bearer token may be intended for an upstream MCP server. When LiteLLM's own validation fails, the vulnerable fallback substitutes an empty UserAPIKeyAuth object. Downstream handling treats that object as unrestricted rather than returning an authentication failure, converting an invalid token into usable MCP access.^[0][1]

The bypass does not require possession of a valid LiteLLM key: Wiz explicitly reports that a single-character bearer token is sufficient. Its honeypot example shows an Authorization bearer value of x in a request to /v1/models. This grounds a concrete observed probing behavior, but does not establish that every request using a short token is malicious.^[1]

CVE-2026-42271 is a separate command-injection flaw in endpoints that test MCP server configurations before they are saved. Wiz reports exploitation enabling remote code execution. Because the supplied original excerpt stops during this discussion, it does not supply the precise vulnerable parameter, command construction, or execution prerequisites.^[1]

The reported credential collection targets live application state. NHIMG says attackers queried master_key and litellm_master_key_hash in the running Python process and harvested provider keys. This explains why examining only credential-file access would not cover the reported collection technique.^[0]

Default master keys create a separate exposure path from the MCP authentication flaw. NHIMG reports that sk-1234 was accepted by 294 scanned gateways and that the master key is both an administrator credential and the HS256 secret for session JWTs. A known master key can therefore support administrator access and forged sessions without requiring the MCP bypass.^[0]

NHIMG also describes a research-demonstrated cloud pivot: an administrator can create pass-through routes to the instance metadata service and forward headers needed to retrieve IAM credentials, including in an IMDSv2 setting. The supplied evidence does not establish that attackers performed this pivot in the observed honeypot activity.^[0]

Affected versions and patch status

Indicators of Compromise

Key takeaways

• The primary evidence establishes active exploitation of two distinct LiteLLM weaknesses: fail-open MCP authentication and command injection in MCP configuration-test endpoints. Remediation tracking should distinguish the two rather than assume one version recommendation resolves both.^[0][1]
• LiteLLM is a credential-concentration point. Provider keys, cloud permissions, and MCP-connected internal services can make a gateway compromise materially broader than unauthorized model use.^[1]
• The reported collection method reaches into live Python state, so patching and credential-file monitoring alone do not address the entire reported incident pattern. Exposure assessment, credential rotation, and process-aware investigation have separate roles.^[0]
• Keep observed activity separate from demonstrated capability: credential collection and cryptomining are reported honeypot outcomes, whereas the cloud-metadata pivot belongs to separate research. The supplied material does not establish a named actor, named production victim, or observed cloud-account compromise.^[0]
• The original Wiz excerpt is incomplete. The affected-version boundary, detailed post-exploitation behavior, default-key census, and September CISA timeline are supported here only by NHIMG's secondary account, not by independently supplied advisory or research bodies.^[0][1]

Defensive actions

• Upgrade LiteLLM instances affected by CVE-2026-59822 to version 1.84.0 or later.: NHIMG identifies this release as fixing the fail-open MCP authentication behavior. This recommendation addresses the authentication bypass; the supplied evidence does not establish a fixed release for CVE-2026-42271.^[0][1]
• If the authentication-bypass upgrade cannot be applied immediately, block /mcp/ routes at the reverse proxy.: NHIMG recommends this containment measure for the exposed MCP surface through which fabricated bearer tokens can obtain access.^[0]
• Audit deployments for the master key sk-1234 and for missing authentication, then configure a strong, unique master key.: NHIMG reports substantial default-key and unauthenticated exposure in the February scan. It also reports that the master key signs session JWTs, so replacing a known default addresses more than ordinary API access.^[0]
• Remove LiteLLM and its MCP routes from unrestricted public access; use private networking or an identity-aware proxy that validates tokens before forwarding them.: The observed exploitation targets exposed AI infrastructure, and NHIMG specifically recommends these controls for LiteLLM gateways and MCP routes.^[0][1]
• For an exposed vulnerable instance or a deployment using the default master key, rotate the master key, provider API keys, and connected MCP-server credentials.: NHIMG reports credential theft from application process state and recommends rotation of the gateway's downstream credentials. Patching the entry point does not revoke secrets that may already have been collected.^[0]
• Restrict the gateway host's IAM permissions and block or tightly control its access to instance metadata.: NHIMG describes a demonstrated administrator-controlled pass-through route to cloud metadata and IAM credentials. This is a potential blast-radius control, not evidence that cloud credentials were stolen in the observed intrusions.^[0]
• Review available request and process telemetry for the reported behaviors: single-character bearer probes to /v1/models, access to master_key or litellm_master_key_hash in Python process state, and XMRig execution.: Wiz supplies the bearer-token probing observation, while NHIMG supplies the process-state collection and mining details. These are investigation leads rather than individually conclusive compromise indicators, and file-access review alone would miss the reported in-memory collection method.^[0][1]
• Replace shared gateway credentials with identifiable clients and short-lived, audience-restricted tokens where supported.: NHIMG recommends per-caller identities so gateway access can be traced and revoked individually rather than relying on a single shared static key.^[0]