New open-source project Litelm launched on GitHub as a leaner alternative to the LiteLLM multi-provider LLM gateway.
Litelm is a community-published GitHub project positioned as a stripped-down alternative to LiteLLM, a widely used gateway/SDK for routing requests to multiple LLM providers. The post drew modest attention on Hacker News with 45 points and 17 comments. The listing provides no further technical details, benchmarks, or feature specifics.
Wiz found multiple LiteLLM AI gateway flaws, including a CVE-2026-59822 MCP auth bypass added to CISA KEV, enabling root code execution and cloud credential theft.
An internet scan of 3,074 exposed LiteLLM instances found 294 (9.6%) accepting the default sk-1234 master key and 191 (6.2%) requiring no authentication. CVE-2026-59822 lets a single-character Bearer token establish a valid MCP session via an OAuth2 fallback in versions before 1.84.0; the flaw is in CISA's Known Exploited Vulnerabilities catalog. CVE-2026-59821 allows Python code execution as root in the gateway container via unsanitized Custom Code Guardrails registration before 1.82.0-stable, and CVE-2026-35029 permits config changes leading to RCE and admin takeover. Admin access plus pass-through endpoints can reach cloud metadata services to steal IAM credentials.
Wiz found 294 of 3,074 internet-facing LiteLLM gateways accepted the documented default admin key sk-1234, exposing provider API keys and cloud IAM credentials.
Wiz Research's February Shodan scan found 3,074 LiteLLM gateways, 294 of which accepted the setup guide's sk-1234 admin key; 191 had no master key set and would accept any credential. The master key doubles as the authentication switch, and before 1.82.0-stable a gateway started without one granted every request full admin rights, exposing stored provider API keys, prompts, and MCP-connected tools. A documented pass-through endpoint lacks checks against private and cloud metadata addresses, letting an admin-key holder retrieve cloud IAM credentials, though no real-world abuse is reported. Related LiteLLM flaws include CVE-2026-59821 (disputed guardrail code execution), CVE-2026-59822 (CVSS 8.8, added to CISA KEV on September 2 and observed against Wiz honeypots), and CVE-2026-42271, used to install a cryptominer.
Australian Federal Police arrested two alleged TeamPCP members behind supply-chain worm attacks that stole over 500,000 credentials from compromised open-source libraries.
The AFP arrested alleged TeamPCP leader Ruben Thomson, 21, and Louis Gaebler, 23, near Perth; both were charged and remain in custody. The group inserted a self-spreading credential-stealing worm into open-source projects including Trivy, KICS, LiteLLM, and Telnyx, harvesting more than 500,000 credentials used for network access, ransomware, extortion, and sales. About 78,000 tokens and secrets from nearly 2,200 organizations leaked online last month, and the FBI supported the investigation that began in April.
AFP and FBI arrested two alleged TeamPCP hackers behind open-source supply chain attacks that stole 500,000+ credentials from 1,000+ organizations.
Australian Federal Police, working with the FBI and Western Australia Police, arrested a 21-year-old from Cottesloe and a 23-year-old from Mandurah on August 26, 2026, over alleged membership in the TeamPCP cybercrime group. The group allegedly planted malicious code in open-source packages, harvesting credentials, authentication tokens and at least 300 GB of data from over 1,000 organizations, with remediation costs estimated in the hundreds of millions of dollars. TeamPCP has been linked to supply chain attacks on GitHub, Telnyx, LiteLLM, Aqua Trivy, Checkmarx KICS, TanStack, MistralAI and Red Hat using a cloned self-replicating worm dubbed Shai-Hulud. Researchers note TeamPCP cloned the Shai-Hulud worm but was not behind the original 2025 attacks.
Microsoft Threat Intelligence details attacks on exposed AI workloads exploiting LiteLLM gateways for credential harvesting, persistence, and cryptomining.
Microsoft Threat Intelligence examines attacks targeting exposed AI workloads, including exploitation of LiteLLM gateway deployments. Post-exploitation activity includes credential harvesting, establishing persistence, and cryptomining. The post urges defenders to secure AI infrastructure gateways and control points; the available text does not name threat actors, CVEs, or provide IOCs.
TeamPCP planted the SANDCLOCK credential stealer in LiteLLM PyPI releases, exposing credentials across 2,038 repositories at 898 organizations including Microsoft and NVIDIA.
Threat actor TeamPCP compromised LiteLLM maintainer credentials and published malicious versions 1.82.7 and 1.82.8 to PyPI around March 2026, creating an exposure window of several months. The SANDCLOCK credential stealer exposed full credential sets across 898 GitHub owners and 2,038 repositories, including Microsoft, Azure, IBM, NVIDIA, PayPal, Deloitte, Bosch, and S&P Global. Stolen material includes GitHub CI/CD identities, AWS/GCP/Firebase credentials, SSH keys, Kubernetes secrets, and OpenAI and Anthropic API keys; Resecurity acquired a 150GB archive with 2,146 credential records. Technology, banking/finance, and healthcare organizations are the most affected sectors, and victims must rotate all exposed credentials.
153GB archive from the LiteLLM supply chain attack exposes secrets from about 2,500 companies, including AWS, Samsung, Cisco and Salesforce.
Hudson Rock obtained and analyzed a 153GB archive stolen in the LiteLLM supply chain attack, containing 433,909 files with secrets attributed to 2,488 corporate domains, including AWS, Samsung, Cisco, Salesforce, NVIDIA, Microsoft and Siemens. TeamPCP compromised Trivy on March 19, 2026, stole LiteLLM's PyPI publishing tokens through the build pipeline, and published malicious LiteLLM versions 1.82.7 and 1.82.8 on March 24. CloudSEK separately estimated close to 2,500 exposed organizations, and Kevin Beaumont confirmed the data is legitimate. Hudson Rock is running a global ethical disclosure effort and urges organizations to rotate secrets before the trove leaks publicly.
Unauthenticated MCP Endpoint Authentication Bypass in BerriAI LiteLLM
BerriAI LiteLLM, a widely used self-hosted AI gateway and proxy server for calling LLM APIs, fails to properly authenticate requests to its MCP Streamable HTTP endpoint in versions prior to 1.84.0. An unauthenticated attacker can send a fabricated Authorization header that triggers an OAuth2 passthrough fallback, which replaces failed LiteLLM key validation with an empty UserAPIKeyAuth() object and lets the request reach MCP tooling without any valid LiteLLM key. Successful exploitation grants unauthenticated access to the gateway's MCP tooling with high confidentiality impact per the CVSS 4.0 score of 8.8, and public reporting describes attackers chaining LiteLLM weaknesses from authentication bypass to root code execution and cloud credential theft. Any organization running LiteLLM before 1.84.0 is affected, particularly gateways exposed to the internet. The flaw is confirmed exploited in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-02, while EPSS currently estimates a 0.9% probability of exploitation in the next 30 days.
· BerriAI LiteLLM all versions prior to 1.84.0 (fixed in 1.84.0) KEVmoderate
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format.
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.82.0-stable, LiteLLM's Custom Code Guardrails production create and update paths did not apply the same sandboxing and validation used by the test endpoint, allowing a privileged user with access to create or update guardrails to submit custom Python code that executed in the LiteLLM proxy environment and could expose secrets available to the process. This issue is fixed in version 1.82.0-stable.
Command Injection in BerriAI LiteLLM AI Gateway Exploited in the Wild
CVE-2026-42271 is a command injection (CWE-77/CWE-78) in BerriAI LiteLLM's proxy server, a widely used AI gateway for calling LLM APIs. Two MCP preview endpoints (POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list) accept a full stdio server configuration, including command, args, and env fields, and spawn the supplied command as a subprocess on the proxy host; the endpoints are gated only by any valid proxy API key with no role check, so even low-privilege internal-user keys can trigger it. An attacker with any authenticated key gains arbitrary command execution with the privileges of the proxy process, and reporting indicates attackers are chaining the flaw into broader takeover of AI gateway servers, including reverse shells and crypto miners, in some cases via weak or default keys such as the example 'sk-1234' admin key. Any organization running LiteLLM versions 1.74.2 through before 1.83.7, including LiteLLM distributed with Red Hat OpenShift AI, is affected. The flaw was added to CISA's Known Exploited Vulnerabilities catalog on 2026-06-08 and is under active attack, with a very high EPSS of 83.6% for exploitation within 30 days.
· BerriAI LiteLLM (proxy server / AI Gateway) 1.74.2 up to but not including 1.83.7 (fixed in 1.83.7) · Red Hat OpenShift AI KEVmoderate
HTTP Request Smuggling in Kludex Starlette (CVE-2026-48710)
Kludex Starlette prior to version 1.0.1 did not validate the HTTP Host request header before using it to reconstruct request.url, an inconsistency classified as HTTP request/response smuggling (CWE-444). Because routing operates on the raw ASGI scope path while request.url is rebuilt from the unvalidated Host header, an attacker can send a malformed Host header so that request.url.path differs from the path the router actually processed. Any middleware or endpoint that enforces security restrictions based on request.url rather than the raw scope path can then be tricked into approving requests that should have been blocked, bypassing those controls. All Starlette deployments below 1.0.1 are affected, both direct users and downstream products that bundle the library, including Red Hat offerings such as Ansible Automation Platform, OpenShift AI, OpenShift Lightspeed, Satellite, AI Inference Server, Migration Toolkit for Applications, and Enterprise Linux AI. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2026-09-02, confirming active exploitation; related reporting describes attackers deploying reverse shells and crypto miners, and EPSS ranks it in the 98th percentile with a 36.3% probability of exploitation within 30 days.
· Kludex (Encode) Starlette All versions prior to 1.0.1 · Red Hat AI Inference Server KEV PoC ×3mass
Broken Access Control in LiteLLM AI Gateway Enables Authenticated RCE
CVE-2026-35029 is a broken access control flaw (CWE-863, CWE-425) in LiteLLM, an open-source proxy server (AI Gateway) for calling LLM APIs, in which the /config/update endpoint fails to enforce admin-role authorization in versions prior to 1.83.0. Any user who is already authenticated to the proxy can call this network-accessible endpoint without admin rights and modify the proxy configuration and environment variables. Through this, an attacker can achieve remote code execution by registering pass-through endpoint handlers that point to attacker-controlled Python code, read arbitrary server files by setting UI_LOGO_PATH and fetching the file via /get_image, and take over other privileged accounts by overwriting the UI_USERNAME and UI_PASSWORD environment variables; related security coverage also highlights that vulnerable LiteLLM gateways can be turned into root-level code execution and cloud credential theft. Any organization running a LiteLLM proxy older than v1.83.0 is affected, particularly deployments where non-admin users hold authenticated accounts. No public proof-of-concept or confirmed in-the-wild exploitation is known and the flaw is not in CISA KEV, but EPSS assigns a 25.1% probability of exploitation within 30 days (98th percentile), signaling elevated near-term risk.
· LiteLLM proxy server (AI Gateway) all versions prior to 1.83.0; fixed in v1.83.0moderate
Entities are extracted by the model from each article. Watching an entity keeps it in this browser only (no account); the watchlist page and dashboard alerts use it.