What the LiteLLM Attack Means for the MSPs

The recent supply chain attack on litellm highlighted the problem - every software vendor and every customer using any software with third-party libraries is exposed to vulnerabilities in the dependencies of those libraries.

A poisoned version of a popular Python library with over 90 million monthly downloads could harvest SSH keys, cloud credentials, database passwords, and every API key stored on the affected machine. The attack was caught by accident — a bug in the malicious code crashed a developer's machine, triggering an investigation. Without that bug, it could have run undetected for weeks.

For MSPs specifically, the question is not just "how does this work." The question is: what do you do about it for your customers, starting right now?

MSP challenge

Most MSPs have built their managed security offerings around a well-understood perimeter: endpoints, email, network, identity, and patching. These are necessary yet insufficient. The litellm payload arrived through a legitimate package manager, executed during a routine dependency install, and targeted credentials stored on an endpoint. No malware signatures to detect. No phishing email to filter. No unpatched vulnerabilities to close.

Things to do now

If you have customers who develop applications, consider:

1. Treat all endpoints as high-value targets. Most MSPs apply their strongest monitoring and access controls to servers and cloud infrastructure. Workstations often go unprotected. Yet, the litellm attack showed that every endpoint can be an entry-point. A developer's laptop often has long-lived cloud credentials, database connection strings, CI/CD tokens, and SSH keys sitting in plaintext files. One compromised pip install and all of it is gone. Elevate workstations, especially developer workstations, to the same security tier as your customer's production servers. Apply the same monitoring, the same alerting, the same access controls.

2. Push customers to eliminate long-lived credentials on local machines. This is the single highest-impact change. If an attacker exfiltrates an AWS access key that expires in 60 minutes, the damage window is narrow and containable. If they exfiltrate a static access key that has been sitting in a .env file for 18 months, they have persistent access to your customer's entire cloud environment. Work with your customers to move credentials into a secrets manager and enforce short-lived, scoped tokens issued through their identity provider. This does not prevent the attacks from executing. It makes the stolen credentials worthless before the attacker can use them.

3. Monitor outbound traffic from workstations. The litellm payload had to send the harvested credentials somewhere. That means outbound network traffic to an unfamiliar endpoint, likely with an unusual payload size. Most MSPs already have the tooling to detect this — DNS filtering, outbound traffic analysis, anomaly detection. The gap is that these tools are typically pointed at servers and general endpoints, not specifically at developer workstations. Extend coverage. Create alerting rules for unusual outbound connections from machines where development tools are installed. This is a detection layer that you can deploy within your existing stack.

4. Offer dependency auditing as a managed service. Most engineering teams don't pay attention to what their projects install. A single top-level package can pull in 40 or 50 dependencies, each one maintained by a different person or team, each one a potential attack vector. Tools like pip-audit or npm audit provide automated scanning that flags known vulnerabilities and suspicious packages. Package it as a recurring service: weekly or monthly dependency audits with a report that goes to the CTO.

5. Implement a process to manage the dependencies of your and customer applications. Advise your customers to enforce a policy where no new dependency - and no version upgrade of an existing dependency - goes into production-bound code without review and explicit approval. Pin exact versions. Verify checksums. Do not allow automatic upgrades. A developer who pinned litellm==1.82.7 with a hash check would not have pulled the poisoned 1.82.8.

Conversation starter

Most business owners and many CTOs do not understand that their development teams implicitly trust thousands of strangers every time they build software. The concept of a transitive dependency - code you did not choose to install, written by someone you have never heard of, running with full access to your machine - is foreign to anyone who has not worked in software development.

Frame it simply. Every package developers install comes with a tree of other packages, sometimes dozens of layers deep. Any of those packages can be compromised by a single attacker gaining access to a single maintainer's account. When that happens, every machine that installs the update hands over its credentials. No phishing required. No user error. Just a routine installation.

Then tell them about the litellm case. Ninety million downloads per month. The poisoned version lived for less than an hour. Caught only because the attacker's code had a performance bug. Ask them: would your team have noticed?

The opportunity

The type of conversation you can have with your customers about attacks like litellm is a way for you to serve as a trusted advisor and build stronger relationships with your customers. Not to mention, an additional revenue stream from protecting workstations that are usually not protected.