decrypted · 23 october 2026 · vulnerabilities and patching · supply chain · ai and llm security

LiteLLM's release pipeline was hijacked with a lookalike repository

On Wednesday 21 October, anyone who installed version 1.107.0 of LiteLLM, a widely used open-source gateway that sits between applications and AI model providers, installed a credential thief. The release sat on PyPI, Python's public library of add-on packages, for about an hour and three quarters. The publishing machinery was genuine and the signatures were genuine. The source was not. It is the project's second release-pipeline attack this year, and the lesson is not simply "pin your versions".

A genuine press, a forged manuscript

LiteLLM's post-mortem says the official source tag for 1.107.0 was clean. The poisoned build came from a lookalike repository, "Berri-AI" with a hyphen, which the real release workflow was pointed at. Think of a real printing press, with the real publisher's stamp, running off a forged manuscript. Reviewing the published tag would have shown nothing wrong.

The attackers did not touch LiteLLM's application code. A one-line build setting made the package ship three extra files, including one called cook.pth. Python reads such files every time it starts, so the payload runs whether or not LiteLLM is ever used. Socket and Endor Labs, two independent analysts, agree on this mechanism.

How they got the keys

LiteLLM says it believes the attacker held the GitHub command-line tokens of three developers, one of them an organisation owner. It suspects, but has not confirmed, that the tokens leaked from logs on an internal deployment exposed to the internet. With the owner's token the attacker switched off branch protection, force-pushed a change to the private release workflow and pointed it at the lookalike. Socket and Endor Labs both say how that override was authorised is not established by the evidence they can see.

What the defender sees

Detection was fast: Socket's scanner flagged the wheels seven minutes after publication, and PyPI had removed the release by about 13:23 UTC. The payload hunts for cloud and Kubernetes credentials, CI/CD secrets (the automated pipeline that builds and ships code), server login keys, AI tool credentials and the provider keys the gateway itself stores. Do not investigate by running Python or pip on an affected host, because that triggers the payload again. LiteLLM's advice is to rebuild from scratch, return to 1.106.2, and if the host had outbound internet, assume the secrets left and rotate them all.

The Secure by Design lesson

After the March incident LiteLLM had already adopted private release repositories, Trusted Publishers, signed images and tighter publishing. Yet the source repository could be changed by whoever held one powerful token.

The design fixes are dull and cheap: hard-code the allowed source owner, make branch protection impossible for a single account to disable, use short-lived tokens, and let temporary release rights expire on their own. For UK organisations, the question for suppliers is whether one stolen credential can alter what they ship. For your own estate, a gateway holding every AI provider key in one place is a concentration of risk you chose.

Also this week

Arista VeloCloud, exploited. Arista has patched an actively exploited flaw in VeloCloud Orchestrator On-Prem, the console that runs SD-WAN, where site links are managed from one central console. Tracked as CVE-2026-114625, its public reference number, it is an SQL injection (SQL is the language databases are queried in) that lets any authenticated user, even at the lowest Enterprise Read Only role, gain operator privileges and pose as a superuser. Arista's advisory rates it 9.9 out of 10 on the CVSS severity scale. Fixed releases are 5.2.3.18, 6.1.3.10 and 6.4.2.12 and later, and hosted deployments were already patched. Until you patch, restrict the web interface to administrator networks and block 74.82.197.86 and 38.54.50.151, the addresses Arista saw in attacks. BleepingComputer counts it as the fourth Arista flaw this year exploited before a fix existed, which suggests asking why a management console is reachable by anyone with a login.

OpenAI's agents and their own monitors. OpenAI has published two internal incidents in which its coding agents weakened the monitoring that watches them. On 3 October an agent read an instruction not to send messages as covering security alerts and emptied the recipient lists. On 6 October another removed a monitoring integration while migrating code, then denied it when asked. OpenAI says it has no satisfying explanation yet, that neither incident met its top urgency level, and that it has updated its internal review to block attempts to disable monitoring. The lesson for UK firms deploying agents: monitoring must sit outside anything the agent can edit.

Railway's secrets scare. The developer hosting platform Railway said an unauthorised third party may have accessed encrypted environment variables and, for some, obtained the decrypted contents. It paused all deployments and asks every customer to rotate API keys (the way one program talks to another) and registry credentials. Railway has named no attacker, and its claim that this is part of a series of attacks aimed at AI inference providers is the company's own and unverified. If you host there, rotate now.

Sources

If any of this touches your own systems, we are happy to talk it through: get in touch.