Within ten days in October, two of the tools developers trust most were turned against them, and neither attack looked like an attack.
On October 21, a poisoned release of LiteLLM, published to PyPI with matching Docker images using stolen maintainer tokens, started collecting credentials from every machine that installed it. On October 29, a tampered Claude Code extension was live on Cursor’s marketplace for about 11 hours, affecting up to 5,000 users. Both arrived through the normal update route, under a name people already trusted.
That’s what makes these incidents worth a closer look. Nobody clicked a suspicious link or ignored a warning. They did what developers do every day, which is install the latest version of a tool that helps them work faster.
AI tools make this riskier than it used to be, because they sit close to API keys, cloud credentials and source code. A bad update doesn’t just break a build. It can quietly reach everything the machine can reach.
In this post we’ll explain what happened in both incidents and why AI tooling raises the stakes. Then we’ll set out a practical dependency hygiene plan, a response routine for a bad install, a checklist and answers to common questions.
What Happened in the Cursor Marketplace
A tampered copy of the Claude Code extension was available in Cursor’s marketplace for about 11 hours on October 29, and Cursor says at most 5,000 users received it.
Cursor said a malicious actor used access to its marketplace to publish a tampered copy of the extension, which neither Cursor nor Anthropic built or published. The versions on Anthropic’s own channels weren’t affected, so the problem was limited to Cursor users.
The payload was more than a nuisance. It added an attacker’s SSH key to the user’s authorised keys file and installed persistence that survives uninstalling the extension. Other reporting says it also tried to harvest details such as hostname, username and public IP address.
Cursor pulled the malicious version, shut down its marketplace as a precaution, audited access and found no other tampered extensions. Anthropic then issued a clean version, 2.1.314.
The detail that matters most is where the change happened. The attacker got into Cursor’s publishing path, so the file was altered before it reached users. A careful developer checking the name and publisher wouldn’t have spotted anything wrong.
What Happened with LiteLLM
On October 21, a malicious LiteLLM 1.107.0 reached PyPI and the project’s Docker images carrying a credential stealer, and it was live on PyPI for about 1 hour 40 minutes.
LiteLLM is a widely used gateway that sits between applications and AI providers, so it handles a lot of keys. The malicious release carried a credential stealer and a remote code loader inside all seven of its wheels, and the Docker images carried the same payload. The stealer collected system information, SSH files, Git credentials, environment variables and tokens for package registries such as npm and PyPI.
Reading the code wouldn’t have helped, because the source on GitHub didn’t contain the malicious files. The danger was in the built packages.
LiteLLM said attackers used GitHub CLI tokens belonging to three of its engineers. A later investigation traced the chain back further. A platform master key accidentally published to a public GitHub repository in late May was never revoked, and it ultimately let the attacker push the malicious version. Two-factor authentication didn’t stop it either, because GitHub CLI tokens are issued after two-factor sign-in, so GitHub’s extra re-authentication step for sensitive actions did not apply.
Details are still emerging, so treat the cause as the current best account rather than the final word.
Why AI Tools Raise the Stakes
The two incidents worked differently, but they share three features that make AI tooling especially exposed.
The tools sit next to secrets. AI coding tools and gateways live where provider keys, GitHub tokens, cloud credentials and SSH keys are. A stealer that lands on a developer’s machine or a gateway host gets all of them at once.
Updates are fast and automatic. Editors and package managers are built to deliver new versions quickly. That’s a feature until the new version is hostile.
Trust is borrowed. Teams trust a name, a logo or a publisher. In the Cursor case the name and publisher were genuine and the file had still been changed on the way.
Our post on protecting your AI keys covered what a leaked key can cost. This post covers the other half, which is stopping a hostile update from reaching those keys in the first place.
The Two Incidents at a Glance
- Late May 2026: a LiteLLM platform master key is accidentally published to a public repository and never revoked.
- October 10, 2026: the attacker uses that key to reach a GitHub organisation owner’s token.
- October 21, 2026: the malicious LiteLLM 1.107.0 is published to PyPI and the Docker images, then pulled the same day.
- October 29, 2026: the tampered Claude Code extension is available in Cursor’s marketplace for about 11 hours.
A Practical Plan
Know what you’ve installed. You can’t protect what you haven’t listed. Make an inventory of editor extensions on every developer machine, packages in each project, globally installed tools, container images and any AI agents or plugins that run with access to credentials. Most teams find extensions nobody remembers approving.
Wait before you update. Both malicious releases were found and pulled within hours. A delay of a day or two for non-urgent updates would have avoided them at almost no cost. Make the wait a written default, with an exception route for genuine security fixes, and check the vendor’s own notice before acting on an update prompt.
Pin versions and digests. Ask for an exact version rather than “the latest”, and commit your lock files. Reference container images by digest, not a moving tag. In the LiteLLM case, the poisoned release was also published under the latest and main-stable Docker tags, so anyone pulling a moving tag was exposed. LiteLLM’s own advice afterwards was to pin to a release published before October 21, which only helps if you were pinning already. Install into freshly built environments, not long-lived ones.
Keep an approved list for extensions and plugins. Treat editor extensions like any other software supply chain. Keep a short approved list, review additions and switch off automatic updates on managed machines so changes roll out on purpose. A list can’t stop a marketplace compromise on its own, but it shrinks your exposure and tells you in minutes who has a given extension installed.
Shrink what a bad install can steal. Assume that one day something hostile gets in, and make sure there’s little worth taking. Keep long-lived keys out of developer environment variables where you can, use short-lived and separate credentials as we described in our AI keys post, and run unfamiliar tools in containers rather than on the machine holding your SSH and cloud credentials.
Protect your own release pipeline. If you publish software, you’re someone else’s dependency. Use the smallest permissions that work, keep temporary increases short, require a second person to approve releases and make sure branch protections can’t be quietly switched off. Revoke any token that has ever appeared in a repository or a log, because a leaked secret you forgot to cancel is still a working secret. Our post on risk-tiered code review covers how to decide which changes need extra scrutiny.
Don’t forget websites and stores. Online stores sit on long dependency chains of themes, plugins, build tools, payment integrations and third-party scripts, and a build server holding payment or hosting credentials is as attractive as an AI gateway. Pin your build dependencies, keep an approved plugin list and keep production credentials off developer laptops. Our web and e-commerce team can review how a site is built and deployed, and put these controls into the pipeline.
Put someone in charge. Every rule above depends on a named person. Who keeps the inventory, who approves a new extension, who reads the vendor notices? Without answers, the policy exists on paper only. If your team is stretched or the knowledge sits with one person, Kilowott Workforce can help you bring in people and working practices that make this routine.
Be ready to respond. Subscribe to security notices for the tools you rely on, keep your inventory current so you can answer “are we affected?” in minutes and write a short response plan, as below.
If You Installed Something Bad
Move quickly and in order. Always follow the vendor’s current notice, as details can change.
- Don’t stop at uninstalling. In the Cursor case, researchers warned that uninstalling the extension wouldn’t remove the backdoor.
- Check for unfamiliar access. Look at your SSH authorised keys file for entries you didn’t add, and remove them.
- Check versions. For LiteLLM, look for version 1.107.0 in your environments and images, and rebuild from a clean, pinned version.
- Rotate every secret reachable from that machine. That means environment variables, cloud keys, SSH keys, GitHub and registry tokens and AI provider keys.
- Review activity. Look at your provider, cloud and repository logs for use you don’t recognise.
- Consider rebuilding the machine if you can’t be sure what ran on it.
- Record what happened and update your practices. If personal data may have been affected, involve your legal advisers. This isn’t legal advice.
A Dependency Hygiene Checklist
- Listed every editor extension, package, container image and AI plugin in use
- Set a default delay before installing brand-new versions, with a route for urgent security fixes
- Locked and pinned package versions, and referenced container images by digest
- Created an approved list of extensions and switched off auto-updates on managed machines
- Removed long-lived keys from developer environments where possible
- Given each tool its own short-lived or scoped credentials
- Reviewed token permissions and branch protections on your own repositories
- Revoked any key or token that has ever been exposed
- Subscribed to security notices for your key tools
- Written a short response plan and named an owner
Trust the Tool, Verify the Update
It’s tempting to treat these incidents as bad luck for two popular projects. But the pattern is more useful than the headlines. A trusted name was used to deliver something hostile, the window was short and the damage depended on what the victim’s machine could reach.
You can’t stop every tampered update. You can make sure your team is rarely the first to install one, that a bad install finds little to steal and that you know within minutes who’s affected. Those are habits, not purchases, and they’re worth setting up before the next notice.
If you’d like help putting this in place, our web and e-commerce team can review how your sites and build pipelines are put together, and Kilowott Workforce can help you build the team and processes that keep it running. You can see how we approach this kind of work across other brands in our case studies.
