Thirty years ago this month, give or take, I was reading a Usenet-style essay at my desk at ICONZ, Technical Services Manager, trying to work out why a chaotic, leaderless process kept producing better software than the disciplined, hierarchical one I had been trained to trust. Eric Raymond's answer, in "The Cathedral and the Bazaar," was that the bazaar worked because enough eyes were looking. But the bazaar never had a certificate authority. Its whole answer to "who can I trust" was a name: look at who wrote it. For most of thirty years, that was enough. Checking a name is cheap, and the people checking were paying attention.
This month, a piece of software moves twenty-three million downloads a week through other people's infrastructure. It found out what happens when nobody checks the name at all.
LiteLLM is a Python proxy library. It lets developers point one piece of code at dozens of different large language model providers without rewriting it for each one. Few people outside engineering teams know LiteLLM. It sits inside their software anyway. On 24 March 2026, two malicious versions of LiteLLM, 1.82.7 and 1.82.8, reached PyPI, the Python Package Index, through a poisoned build-time dependency. A security scanning tool called Trivy had itself been compromised earlier in a separate campaign, and LiteLLM's own build pipeline pulled it in unpinned. The malicious code lived inside a file. Python's own site module runs that file automatically the instant the interpreter starts, whether or not anyone ever imports the package. LiteLLM's own advisory states the packages were live "for about 40 minutes before being quarantined by PyPI." Forty minutes is not nothing, but it is short enough that most of the damage stayed theoretical. Endor Labs, the security firm that first disclosed the poisoned Trivy campaign, later attributed the whole operation to a threat actor it names TeamPCP. The indicators matched a separate campaign the firm Wiz had documented around the same tooling.
Seven months later, on 21 October 2026, the identical mechanical trick worked again on the identical project. This time it stayed open more than twice as long: 103 minutes. It ran from 11:39:51 UTC, when seven malicious wheels for version 1.107.0 hit PyPI, to 13:23 UTC, when the last of them was gone. The payload arrived in three small files. A twelve-byte startup hook did nothing but import a second file. A sixty-one-kilobyte credential harvester, named internally "privcollect", swept up browser passwords, SSH and GPG keys, cloud credentials and AI-tool configuration files. A third file quietly spawned a background process, polling an attacker-controlled repository once an hour for further instructions. That third file's own drop point was empty when the release shipped. It did not need to hold anything yet. It only needed to exist, armed, for whenever the attacker chose to use it. Docker Hub and three separate GitHub Container Registry repositories carried the same poison for even longer, until 14:20 UTC.
The first wave of coverage got close. The malicious release came from a repository called Berri-AI/litellm, one hyphen away from the real organisation, BerriAI. It would be tidy to say a human reviewer glanced at that name, saw something close enough, and let it through. LiteLLM's own account of the attack chain describes something else entirely. The tidy version would let everyone conclude the fix is a more careful human. A configuration file committed to a public repository back in May 2026 had leaked a master key. Nobody revoked it. In October, the attacker used that key. It obtained a GitHub access token belonging to an organisation owner. That token was not scoped down. It was not tied to a service account either. From there, the attacker stole two more maintainers' tokens the same way. Over roughly two hours, ten commits built and refined the payload on the lookalike fork. A change hit the release workflow. It let the build pull from a different source repository. Before any of that build ever ran, the attacker disabled branch protection, the one control that exists specifically to put a human in front of a change before it ships. The same credentials that switched branch protection off are the ones that then built the malicious release. The lookalike name was camouflage for a process that had already removed every reviewer, human or automated, from the room.
Nobody got the chance to catch it. The one checkable fact would have stopped it. The thing positioned to check it had already been turned off, by the same theft that built the thing it should have caught.
None of this is the bazaar's first encounter with a stranger holding the keys. In 2018, a New Zealand developer named Dominic Tarr maintained 422 packages on npm. npm is the equivalent registry for JavaScript. One of them, event-stream, had around 1.5 million weekly downloads. It had not been actively maintained in years. A user calling themselves "right9ctrl" offered to take over its upkeep. As I wrote in Free as in Theft, "He did not know right9ctrl. He did not investigate their identity." He simply handed control of software millions of people depended on to a stranger. Carrying it alone had stopped being sustainable. The mechanism was different: maintainer exhaustion rather than stolen credentials. The artefact being trusted was exactly the same one, a name on a screen, standing in for a person nobody had actually checked.
LiteLLM's download figures tell two different stories. The project as a whole moves roughly 23 million downloads a week. The malicious version itself was pulled around 49,000 times during its 103 minutes. That figure includes CI caches and mirrors. Scale of exposure and actual uptake inside a short window are not the same measurement. Treating them as one makes the incident sound either smaller or larger than it was.
Projects are starting to write new policies. The bazaar never needed them before. The bazaar's whole trust model assumed a name meant a person you could, in principle, go and ask. LiteLLM had an advisory process, a public two-post account of exactly what happened, and a cleanup that moved in under two hours once PyPI acted. All of that held up well. What did not hold up was the one fact an organisation name is supposed to carry, that the thing calling itself BerriAI is actually BerriAI. Nothing was left in the pipeline able to look at it by the time it mattered.
The open-source dimension of this is not abstract either. PyPI carries no certificate authority and never pretended to. A name, a maintainer account and a download count are the trust model, the same one the bazaar has run on for three decades. The Linux Foundation's own survey of open-source maintainers was published the same week as LiteLLM's second compromise, funded in part by Red Hat. It found that thirty-two per cent of projects have no AI-contribution policy and no plans to write one. About a quarter cannot verify whether a contribution was AI-assisted at all. Projects are starting to write policies the bazaar never needed. Every contributor used to be a known name. A policy on paper does nothing when credentials, not judgement, are what gets compromised. LiteLLM just answered that question.
The same question of who is actually running the code sits underneath defence-adjacent Linux deployments too, at a different scale of consequence. US Navy submarines run hardened Linux builds under configuration control that treats build provenance as a precondition rather than an afterthought. Every binary traces to a signed, audited source. Nobody gets a second attempt at discovering mid-patrol that a release did not come from where it claimed to. Branch protection was the control positioned to catch exactly the kind of substitution LiteLLM suffered. It was switched off before the build ever ran. A submarine's build pipeline cannot tolerate a control that the same credentials it is meant to check can simply disable. A name checks nothing by itself. Neither does a control that the same credentials can switch off.
You have spent thirty years in this profession. Its whole promise was that enough eyes on the code make the whole system trustworthy. LiteLLM's second compromise happened because the credentials that built the malicious release had already switched off the one control positioned to look. If the thing you are actually relying on to catch the next one is someone noticing a name, what would have to be true for that to work? Is it true today for the software you run?
This is one of seven weekly series in The Hamberger Report. Subscribe on LinkedIn and the next one arrives in your feed.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
About the Author: Andreas Hamberger is a New Zealand-based enterprise architect and technology strategist. Over 30 years, he has moved from compiling kernels on a 486 to leading cloud, cyber, and AI transformation programmes across government, banking, transport, and aviation. He founded Yoper Linux, served as a technology specialist for Novell during the Linux Wars, and is the author of "Generative AI: Skynet or Heaven" and "Space Mafia." Free as in Theft is the hidden history of open source software. He can be reached at andreas@thehambergerreport.com.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] LiteLLM. "Security Update: Suspected Supply Chain Incident." 24 March 2026. https://docs.litellm.ai/blog/security-update-march-2026
[2] Endor Labs. "TeamPCP Isn't Done: Threat Actor Behind Trivy and KICS Compromises Now Hits LiteLLM's 95 Million Monthly Downloads on PyPI." 2026. https://www.endorlabs.com/learn/teampcp-isnt-done
[3] LiteLLM. "Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised." 21 October 2026. https://docs.litellm.ai/blog/security-incident-oct-21-2026
[4] LiteLLM. "The attack chain behind the v1.107.0 LiteLLM release." 21 October 2026. https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
[5] Datadog Security Labs. "LiteLLM supply chain compromise: What you need to know." 2026. https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/
[6] StepSecurity. "litellm 1.107.0 Compromised on PyPI: Backdoored Wheels Drop a Credential Stealer and an Hourly Remote Code Loader." 2026. https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer
[7] Wiz. "LiteLLM Compromised, Steals Credentials." 2026. https://www.wiz.io/blog/litellm-compromised-steals-credentials
[8] It's FOSS. "Red Hat Funded a Report That Found a Quarter of Incoming Pull Requests May Be AI Slop." 21 October 2026. https://itsfoss.com/news/red-hat-lf-research-ai-slop-report/
[9] Linux Foundation. Press release, "New LF Research Survey Shows Generative AI Cuts Open Source Coding Time in Half, But 25% of Incoming Pull Requests Are Considered 'AI Slop.'" 21 October 2026. https://www.linuxfoundation.org/press/new-lf-research-survey-shows-generative-ai-cuts-open-source-coding-time-in-half-but-25-of-incoming-pull-requests-are-considered-ai-slop