Threats Tagged 'litellm'

In this article AI workloads are becoming high-value control points Case study 1: LiteLLM gateway compromise Case study 2: RAGFlow compromise Case study 3: Kestra compromise Mitigation and protection guidance MITRE ATT&CK techniques observed References Learn more AI is creating a new layer of enterprise infrastructure. Gateways, retrieval platforms, orchestration services, and containerized runtimes now sit between users, applications, data, and models. These systems concentrate credentials, data access, model connectivity, and execution privileges, making them some of the most powerful components in the AI stack. That concentration of trust is also creating new opportunities for attackers. In recent investigations, Microsoft observed activity targeting three distinct AI workloads: a LiteLLM gateway, a RAGFlow deployment, and a Kestra workflow environment. The intrusion paths varied, but the objectives were strikingly similar. Attackers sought to steal credentials, establish persistence, and monetize compromised compute resources. The individual techniques matter, but the broader pattern matters more. Across these cases, attackers treated AI infrastructure as a control plane where credential theft, host compromise, and downstream data access can converge. As organizations continue to deploy AI systems, these platforms are becoming high value targets that deserve the same security scrutiny as other critical enterprise infrastructure. AI workloads are becoming high-value control points The campaign-level signal extends beyond one product. The targeted workloads served different functions, but each exposed assets that could support follow-on abuse, including model-provider keys, proxy-issued virtual keys, database connection strings, tenant configuration, workflow execution, or host compute. Post-compromise behavior varied by workload role. Defenders should inventory exposed AI management surfaces, restrict administrative access, and monitor for gateway-originated execution and secret access. Three observed compromises across AI workloads AI workload Observed activity Attacker objective LiteLLM Observed attacker activity : Python droppers, runtime secret harvesting, PostgreSQL collection, miner deployment, and persistence activity from the LiteLLM gateway context. Microsoft assessment: Initial access likely occurred through exploitation of the exposed LiteLLM gateway surface, consistent with the vulnerability chain involving CVE-2026-42271 and CVE-2026-48710. Credential theft, backend database access, durable host access, and compute monetization. RAGFlow Observed attacker activity : Possible SSRF-style reconnaissance followed several days later by code execution, application-path modification, and placement of a Python hook in the TenantLLM credential-configuration flow. Public research: Describes multiple RAGFlow execution paths; Microsoft does not attribute this intrusion to a specific vulnerability. Intercept newly configured LLM provider credentials and model metadata. Kestra Observed attacker activity : Workflow-origin shell execution, Docker and container-environment discovery, XMRig deployment, and follow-on data collection. Microsoft assessment: Initial access likely involved exploitation of the exposed Kestra orchestration surface, with CVE-2026-49869 providing relevant public vulnerability context. Secret discovery, container-level access, data collection, and rapid compute monetization. Case study 1: LiteLLM gateway compromise Framework role and affected runtime context LiteLLM is commonly deployed as a proxy or gateway between applications and model providers. In that position, the service may hold or retrieve model-provider keys, LiteLLM master keys, virtual-key records, database connection strings, routing configuration, and tenant policy data. Command execution in the gateway runtime therefore exposed a process context close to AI routing and credential material. Figure 1. LiteLLM gateway compromise – attack chain…

A supply chain poisoning attack on LiteLLM, a popular AI model gateway, was detected by NSFOCUS Technology CERT. The TeamPCP group compromised the Trivy security scanning tool used in LiteLLM's release process, allowing them to publish malicious versions 1.82.7 and 1.82.8 on PyPI. These versions contained credential-stealing programs that collected sensitive data and, if a Kubernetes cluster was detected, deployed privileged Pods and implanted persistent backdoors. The attack impacted numerous dependent packages and potentially affected millions of users. The incident highlights the growing risks in AI infrastructure and the need for robust supply chain security measures.

MediumCampaignUnited StatesChinaIndia+7#software security#supply chain attack#open source

TeamPCP has launched a supply chain attack targeting LiteLLM, an open-source Python library used in 36% of cloud environments. Malicious versions 1.82.7 and 1.82.8 were published on PyPI, employing sophisticated techniques for payload delivery and persistence. The compromised packages exploit Python's .pth mechanism for stealthy execution across any Python process. The malware collects sensitive data including API keys, cloud credentials, and CI/CD secrets, encrypting and exfiltrating them to attacker-controlled domains. This attack follows TeamPCP's previous compromises of Aqua Security's Trivy and Checkmarx tools, highlighting an ongoing campaign against the open-source ecosystem. The incident underscores the potential for widespread impact and the need for vigilance in software supply chain security.

MediumCampaignUnited StatesGermanyUnited Kingdom+7#cloud security#supply chain attack#pypi

A malicious supply chain attack has been discovered in the Python Package Index package litellm version 1.82.8. The compromised package contains a malicious .pth file that executes automatically when the Python interpreter starts, without requiring explicit import. This file, located in site-packages/, exfiltrates sensitive information including environment variables, SSH keys, and cloud credentials to an attacker-controlled server. The payload is double base64-encoded to evade basic static analysis. PyPI administrators have quarantined the project to limit its spread. Users are advised to check for the malicious file, rotate all potentially exposed credentials, and audit their PyPI publishing process. The attack is attributed to TeamPCP and is actively exploited in the wild.

MediumCampaignUnited StatesGermanyUnited Kingdom+7#litellm#cloud credentials#pypi