TL;DR

  • Attackers compromised popular Python packages LiteLLM and Telnyx after stealing API tokens from a compromised dependency
  • Malicious versions harvested credentials and files from 119,000+ downloads in under 4 hours
  • PyPI quarantined the malware in 2h 32m (LiteLLM) and 3h 42m (Telnyx) — but that was still enough time for massive exposure
  • "Install latest" left 40-50% of users vulnerable — those who didn't pin dependency versions
  • lilMONSTER helps businesses implement software supply chain security without slowing development

On April 2, 2026, the Python Package Index (PyPI) published an incident report revealing that attackers had injected credential-harvesting malware into two widely-used packages: litellm and telnyx [1].​‌‌‌​​​​‍​‌‌‌‌​​‌‍​‌‌‌​​​​‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​​​‍​‌‌‌​​​​‍​‌‌​‌‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​​‌​‌‌​‌‍​​‌‌​​​‌‍​​‌‌​​​‌‍​​‌‌‌​​‌‍​‌‌​‌​‌‌‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​‌‌‌‌‍​‌‌‌​‌‌‌‍​‌‌​‌‌‌​‍​‌‌​‌‌​​‍​‌‌​‌‌‌‌‍​‌‌​​​​‌‍​‌‌​​‌​​‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​‌‌​​‌‌‌‍​‌‌‌​‌​‌‍​‌‌​‌​​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌

This wasn't a typo-squat package or a fake library with a similar name. These were legitimate packa

ges already in widespread use, compromised after attackers exploited a vulnerability in the Trivy dependency to steal API tokens [1].

Using those tokens, attackers published malicious versions that:​‌‌‌​​​​‍​‌‌‌‌​​‌‍​‌‌‌​​​​‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​​​‍​‌‌‌​​​​‍​‌‌​‌‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌​​​‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​​‌​‌‌​‌‍​​‌‌​​​‌‍​​‌‌​​​‌‍​​‌‌‌​​‌‍​‌‌​‌​‌‌‍​​‌​‌‌​‌‍​‌‌​​‌​​‍​‌‌​‌‌‌‌‍​‌‌‌​‌‌‌‍​‌‌​‌‌‌​‍​‌‌​‌‌​​‍​‌‌​‌‌‌‌‍​‌‌​​​​‌‍​‌‌​​‌​​‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​‌‌​‌‍​‌‌​​​‌​‍​​‌​‌‌​‌‍​‌‌​​‌‌‌‍​‌‌‌​‌​‌‍​‌‌​‌​​‌‍​‌‌​​‌​​‍​‌‌​​‌​‌

  • Ran on install
  • Harvested sensitive credentials and files
  • Exfiltrated data to a remote API

The window of exposure was brief but devastating:

  • LiteLLM: 119,000+ downloads in 2h 32m before quarantine [1]
  • Telnyx: quarantined in 3h 42m [1]

What Makes This Attack Different

Most PyPI malware published to date has been new packages designed to trick users — typo-squats or lookalikes that hope you'll install them by mistake [1].

This attack is different. The malware was injected into existing packages that thousands of developers already trusted and used daily [1].

The implications are sobering. If you're using popular open-source packages, you're not just trusting the original maintainers. You're trusting everyone in their dependency chain — every project they depend on, every tool they use to build and release, and every API token they store.

Related: Axios npm Supply Chain Attack: North Korean Sapphire Sleet Targets 70 Million Weekly Downloads

The Vulnerability: Why "Install Latest" Is a Risk

LiteLLM is typically installed ~15-20 million times per week [1]. That averages to roughly 1,700 installs per minute.

Here's the terrifying math: because many systems use pip install package (without pinning a version), they automatically pull the latest release. PyPI's analysis found that 40-50% of all installs of LiteLLM were unpinned [1].

That means when a malicious version was published, nearly half of everyone installing LiteLLM during that 2.5-hour window received malware.

The Dependency Cooldown Strategy

PyPI recommends a simple but powerful defense: dependency cooldowns [1].

Instead of immediately installing the latest version, you configure your package manager to exclude packages published within the last N days (typically 3 days). This creates a time buffer that allows:

  • Security researchers to detect and report malware
  • PyPI admins to quarantine malicious packages
  • Your team to receive security advisories before installing

For uv (the fast Python package installer):

[tool.uv]
exclude-newer = "P3D"  # "3 days" in RFC 3339 format

For pip (v26.0+, available April 2026):

[install]
uploaded-prior-to = P3D

This isn't a silver bullet — you'll need to bypass cooldowns for critical security updates. But as a default policy, it dramatically reduces your exposure window [1].

How Attackers Compromised the Supply Chain

The attack began with a compromised Trivy dependency [1]. Trivy is a popular security scanner that checks container images, file systems, and Git repositories for vulnerabilities.

The irony is painful: a security tool became the initial attack vector.

After exploiting Trivy, attackers stole API tokens for PyPI and GitHub. With those tokens, they could:

  • Publish malicious versions of any package the compromised developer maintained
  • Access and modify source code repositories
  • Compromise additional packages in a cascading supply chain attack [1]

This is the new reality of software supply chain attacks. Your risk isn't just the direct packages you use. It's every dependency in your entire tree — and every dependency those dependencies depend on.

What This Means for Your Business

If You Build Software

If your business develops software (even internal tools or websites), you're in the crosshairs:

  1. Your CI/CD pipelines are targets — Automated deployment systems that publish packages are high-value targets for attackers. If they can compromise your pipeline, they can inject malware into everything you ship.

  2. Your dependencies are attack surfaces — Every third-party package you use is a potential entry point. Transitive dependencies (dependencies of dependencies) multiply your risk.

  3. Your API tokens are crown jewels — Tokens for PyPI, GitHub, npm, cloud services, and CI/CD platforms are what attackers need to move laterally and compromise more systems.

If You Use Software (Every Business)

Even if you don't write code, you're affected:

  1. Your vendors' supply chain is your supply chain — If your accounting software, CRM, or payment processor uses compromised dependencies, you're exposed.

  2. Your development partners are risk multipliers — Agencies, freelancers, and contractors who build custom software for you may inadvertently introduce supply chain vulnerabilities.

  3. Your attack surface is expanding — Modern businesses rely on thousands of software components. Each one is a potential door.

According to the 2025 Verizon Data Breach Investigations Report, supply chain attacks accounted for 6% of all breaches involving web applications [2]. That's up from 3% in 2023 — a doubling in two years.

Related: Why Your Software Supply Chain Needs a Health Check

How lilMONSTER Helps Secure Your Software Supply Chain

Supply Chain Audits

We help you map your entire dependency tree — direct and transitive — and identify:

  • High-risk packages with few maintainers or infrequent updates
  • Dependencies with known vulnerabilities
  • Outdated packages that may have unpatched security issues
  • Unnecessary dependencies that increase attack surface without value

Secure Build and Release Pipelines

We help you implement security best practices for CI/CD:

  • Pin dependencies with checksums (not just version numbers)
  • Use Trusted Publishers instead of long-lived API tokens [1]
  • Require manual approval for production deployments
  • Scan for secrets before committing code (API keys, tokens, passwords)
  • Implement branch protection rules to prevent unauthorized changes

Dependency Governance

We help you establish policies that balance security and agility:

  • Dependency cooldowns (3-day default, bypass for security updates)
  • Regular update cycles (monthly dependency patching, with testing)
  • Vulnerability scanning integrated into your development workflow
  • Allowlists for approved packages and repositories

Incident Response Planning

When (not if) a supply chain vulnerability is disclosed in a package you use:

  • Rapid impact assessment — are you affected? which systems?
  • Isolation and containment — disable affected services, rotate credentials
  • Remediation roadmap — update to safe versions, audit for indicators of compromise
  • Post-incident review — update policies, improve detection

What You Can Do Right Now

Immediate Actions (Today)

  1. Pin all your dependencies — Don't use pip install package without version pinning. Use lock files with checksums: uv lock or pip-compile --generate-hashes [1].

  2. Audit your dependency tree — Run pip list and check every package. Ask: Do we use this? Is it maintained? When was it last updated?

  3. Scan for exposed tokens — Use tools like git-secrets or truffleHog to check your repositories for accidentally committed API keys or tokens.

  4. Enable 2FA everywhere — PyPI has required 2FA for publishers since 2024 [1], but enable it on GitHub, GitLab, npm, and every other service you use.

Short-Term Actions (This Week)

  1. Set up dependency cooldowns — Configure your package manager to exclude packages published in the last 3 days [1].

  2. Automate vulnerability scanning — Integrate tools like Dependabot, Renovate, or Snyk into your repositories to automatically detect and flag vulnerable dependencies.

  3. Document your build process — If you had to rebuild your entire application from scratch today, could you? Document every step, every dependency, every secret.

Long-Term Actions (This Quarter)

  1. Implement Trusted Publishers — Replace long-lived API tokens with short-lived, OIDC-based authentication where supported [1].

  2. Establish an SBOM (Software Bill of Materials) — Track every component in your software so you can rapidly assess your exposure when vulnerabilities are disclosed.

  3. Create an incident response playbook — Document what to do when a supply chain vulnerability is announced. Who does what? What's the communication plan? How do you patch and test?

FAQ

Typo-squat: Attackers create a fake package with a similar name to a popular one (e.g., requests-lib instead of requests). They hope you'll typo the package name and install their malicious version by accident.

Supply chain attack: Attackers compromise the legitimate package itself — either by stealing the maintainer's credentials, exploiting a vulnerability in their build process, or compromising a dependency. Everyone who installs the real package gets malware.

If you have a website, web application, or custom software, there's a good chance you're using Python packages (or packages from another ecosystem like npm, RubyGems, or NuGet). Ask your development team or agency:

  • "What dependencies do we use?"
  • "Do we have a list of all third-party packages?"
  • "What's our process for updating them when vulnerabilities are found?"

Dependency cooldowns should have a bypass mechanism for security updates. Dependabot and Renovate already bypass cooldowns by default for security advisories [1]. The cooldown is a default policy, not a hard rule — you can override it when you need a specific update urgently.

Basic supply chain security is mostly process and discipline, not expensive tools:

  • Lock files and dependency pinning: free (built into package managers)
  • Dependency cooldowns: free (configuration change)
  • Vulnerability scanning: free for basic tiers (Dependabot, Snyk Open Source)
  • 2FA enforcement: free

Where you'll spend money:

  • Paid scanning tools for deeper analysis ($50-200/month for small teams)
  • Implementation help from security professionals to set up processes
  • Incident response when something goes wrong

Compare this to the cost of a breach: $4.88 million on average [3]. Supply chain security is cheap insurance.

Yes, but indirectly. Your SaaS vendors have supply chains too. When a vendor announces a security incident or supply chain vulnerability, you should:

  • Ask for details on what was affected
  • Check if your data was exposed
  • Follow their remediation guidance
  • Rotate credentials if advised

However, you don't have direct control over their dependencies. This is why vendor due diligence matters — ask potential vendors about their security practices, supply chain policies, and incident response track record.

References

[1] Python Software Foundation, "Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance," PyPI Blog, April 2, 2026. [Online]. Available: https://blog.pypi.org/posts/2026-04-02-incident-report-litellm-telnyx-supply-chain-attack/

[2] Verizon, "2025 Data Breach Investigations Report," Verizon, 2025. [Online]. Available: https://www.verizon.com/business/resources/reports/dbir/

[3] IBM Security, "Cost of a Data Breach Report 2025," IBM, 2025. [Online]. Available: https://www.ibm.com/reports/data-breach

[4] CISA, "Securing the Software Supply Chain: Recommended Practices," Cybersecurity and Infrastructure Security Agency, 2024. [Online]. Available: https://www.cisa.gov/resources-tools/resources/securing-software-supply-chain-recommended-practices

[5] NIST, "Supply Chain Risk Management (NIST IR 8276)," National Institute of Standards and Technology, 2024. [Online]. Available: https://www.nist.gov/itl/applied-cybersecurity/supply-chain-risk-management

[6] Open Source Security Foundation (OpenSSF), "Supply Chain Security Best Practices," OpenSSF, 2024. [Online]. Available: https://bestpractices.coreinfrastructure.org/

[7] Aqua Security, "Trivy Supply Chain Attack: What You Need to Know," Aqua Security, March 2026. [Online]. Available: https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

[8] LiteLLM Project, "Security Update March 2026," LiteLLM Blog, March 2026. [Online]. Available: https://docs.litellm.ai/blog/security-update-march-2026

Your software supply chain is only as strong as its weakest link. lilMONSTER helps you identify, assess, and secure the third-party components your business relies on. Book a free consultation to discuss your supply chain security posture.

TL;DR

  • Bad guys found a way to put hidden viruses inside popular software tools that programmers use
  • Over 119,000 computers downloaded the bad version before anyone noticed [1]
  • The scary part: the bad guys didn't make fake tools — they broke into the real ones
  • lilMONSTER helps businesses use software safely, even when bad guys try to break things

What Is PyPI? (Like a Super App Store for Programmers)

Imagine if your phone had an app store where anyone could upload apps for free. Programmers could pick useful tools and add them to their own apps instantly.

That's what PyPI is for Python programmers (Python is a popular computer language). Programmers can:

  • Search for tools (called "packages")
  • Download them instantly
  • Use them in their own software

There are over 500,000 packages on PyPI. Programmers download them billions of times every month. It's like having free LEGO blocks to build whatever you want.

Why Programmers Use These Free Tools

Imagine you want to build a house. You could:

  • Make every brick by hand (takes forever)
  • Buy pre-made bricks (much faster)

Programmers use free packages like pre-made bricks:

  • Need to send emails? Use the "email package"
  • Need to work with dates? Use the "calendar package"
  • Need to process payments? Use the "payment package"

This lets programmers build complex software quickly instead of making everything from scratch.

What Happened: The "Supply Chain" Attack

Here's what happened, step by step [1]:

Step 1: Breaking In Through a Back Door

There's a popular security tool called Trivy that checks code for problems.

Ironically, the bad guys found a hole in Trivy itself. They broke in and stole special digital keys (API tokens) that Trivy used to talk to other services [1].

Step 2: Stealing the Keys to the Castle

With those stolen keys, the bad guys could now:

  • Log into PyPI as if they were the real programmers
  • Upload new versions of popular packages
  • Make changes to code repositories

It's like stealing a hotel master key — once you have it, you can open any door.

Step 3: Poisoning the Well

The bad guys picked two popular packages:

  • LiteLLM — used by programmers building AI apps (~15-20 million downloads per week) [1]
  • Telnyx — used for phone and text messaging

They uploaded new versions of these packages that looked normal but had hidden malware (viruses) inside.

Step 4: The Malware Spreads

Programmers around the world did what they always do:

pip install litellm

This command tells the computer: "Download the latest version of LiteLLM and install it."

Because so many systems were set to "always get the latest," they automatically downloaded the bad version [1].

In just 2 hours and 32 minutes, over 119,000 computers downloaded the malware [1].

Step 5: What the Malware Did

When programmers installed the bad package, here's what happened [1]:

  1. The package installed normally (or so it seemed)
  2. Hidden code ran secretly in the background
  3. It searched the computer for passwords and secret keys
  4. It sent those secrets to the bad guys over the internet
  5. The bad guys could now log into those systems as if they were the real owners

Step 6: The Good Guys Noticed and Stopped It

PyPI (the service that runs the package "store") has security researchers who watch for problems [1].

Other programmers noticed something was wrong and used the "Report malware" button.

Here's the timeline [1]:

  • Bad version uploaded: 0:00
  • First report from user: 1 hour 19 minutes later
  • PyPI quarantined it: 2 hours 32 minutes later

That's incredibly fast! But with 1,700 downloads per minute, that was still enough time for 119,000 computers to get infected [1].

Why This Is Different (And Scarier)

Old Way: Fake Apps

Before, bad guys would make fake apps with similar names to popular ones:

  • Real app: requests
  • Fake app: requestz (notice the typo)

They hoped programmers would typo the name and accidentally install the fake one.

New Way: Breaking Real Apps

This attack is scarier because the bad guys didn't make fake apps. They broke into the real apps that thousands of programmers already trusted and used every day [1].

It's like:

  • Old way: Counterfeiters make fake branded shoes
  • New way: Counterfeiters break into the real factory and replace all the real shoes with fake ones

The "Trust Chain" Problem

Here's what makes supply chain attacks so tricky:

When you install a package, you're trusting:

  1. The package creator (LiteLLM team)
  2. Everyone they trust (their dependencies)
  3. Every tool those dependencies use
  4. On and on, potentially hundreds of links in the chain

In this case, the break-in happened at Trivy — a security tool that the LiteLLM team used [1]. The LiteLLM team did nothing wrong. But because they used a compromised tool, their package was compromised too.

It's like getting sick because your doctor got sick from their doctor, who got sick from their doctor. The chain of trust keeps going.

How This Affects Your Business (Even If You Don't Write Code)

Direct Impact: If You Build Software

If your business has:

  • A website
  • A mobile app
  • Custom software built by an agency or freelancer
  • Internal tools for your team

...then you're probably using open-source packages like these. If your development team installed a compromised package, your software could have malware.

Indirect Impact: If You Use Software

Every business uses software. That software has dependencies. Those dependencies have dependencies.

When major supply chain attacks happen:

  • Your accounting software might be affected
  • Your payment processor might be affected
  • Your CRM or project management tool might be affected
  • Your website hosting provider might be affected

You don't have direct control over these dependencies, but you're still exposed.

The Domino Effect

Here's a scary example:

  1. Bad guys compromise a popular package
  2. A payment processing company uses that package
  3. An accounting software company uses that payment processor's tools
  4. Your business uses that accounting software

Now your business data is at risk — and you had no idea any of this was happening.

How to Protect Your Business

For Software You Build

If you have developers (internal or external), make sure they:

1. Lock Their Dependencies Instead of "always download the latest," they should:

  • Use specific version numbers (like package v1.2.3)
  • Save "lock files" with checksums (like a fingerprint for each file)
  • Test updates before deploying them

2. Wait Before Updating Use a "3-day cooldown" rule:

  • Don't install packages that were released in the last 3 days
  • This gives security teams time to find and remove malware
  • Bypass the rule only for urgent security updates

3. Scan for Problems Use automated tools that:

  • Check every dependency for known vulnerabilities
  • Alert when a dependency has a security issue
  • Suggest safe updates

For Software You Use

1. Update Quickly (But Safely) When vendors announce security updates:

  • Install them promptly (within days, not weeks)
  • But first, check what the update fixes
  • Make a backup before updating

2. Ask Your Vendors Tough Questions When choosing software providers, ask:

  • "How do you handle security updates?"
  • "What's your process when a vulnerability is found?"
  • "How do you test updates before deploying?"
  • "What's your incident response plan?"

3. Have a Backup Plan If a critical vendor has a security incident:

  • Do you have backups of your data?
  • Can you switch to another provider temporarily?
  • Who needs to be notified (customers, regulators, banks)?

How lilMONSTER Helps

We speak both languages:

  • Business: We explain what's happening in plain English
  • Technical: We work with your developers to implement real security

For businesses that build software:

  • Audit your dependencies
  • Set up secure update processes
  • Create an incident response plan

For businesses that use software:

  • Assess your vendor risk
  • Help you ask the right security questions
  • Respond quickly when vendors have incidents

We're about practical security, not fear-mongering. Supply chain attacks are real, but with the right processes, you can dramatically reduce your risk.

FAQ

PyPI gets 700-800 new packages every single day [1]. That's like reviewing 30 new packages every hour, 24/7. Even if they had a team of 100 people checking packages full-time, bad guys would still find ways to hide malware.

Instead, PyPI relies on:

  • Community reporting — users flagging suspicious packages
  • Automated scanning — tools checking for known malware patterns
  • Fast response — quarantining malicious packages quickly (they did it in ~2.5 hours here) [1]

The goal isn't to catch everything before it's published. It's to minimize the damage window and respond fast.

If you have developers or an agency building software for you, ask them:

  1. "Did we use LiteLLM or Telnyx between March 31 and April 2, 2026?"
  2. "What versions do we have installed?"
  3. "Can we check the install logs?"

If you don't have developers, you're probably indirectly affected through your vendors. Check their security advisories and follow their guidance.

Not necessarily. The advantage of open-source is:

  • Many eyes on the code — anyone can review it for problems
  • Fast disclosure — vulnerabilities are usually fixed quickly and publicly
  • No vendor lock-in — you can see exactly what you're getting

Paid, closed-source software has:

  • Hidden code — you can't check for vulnerabilities yourself
  • Slower patches — vendors may delay fixes to save face or money
  • Secret compromises — you might never know if there's a backdoor

Both have risks. The solution is defense in depth: assume any software can be compromised, and build your security accordingly.

No! Free and open-source packages are amazing. They let businesses build software without reinventing the wheel. The key is using them safely:

  • Lock versions (don't auto-update to latest)
  • Scan for vulnerabilities
  • Have a response plan for when things go wrong
  • Keep good backups

Think of it like driving: cars are dangerous, but you don't stop driving. You wear a seatbelt, follow traffic rules, and have insurance.

Because it would take forever and cost a fortune.

Imagine if every time you wanted to bake a cake, you had to:

  • Grow the wheat for flour
  • Raise chickens for eggs
  • Build an oven from scratch
  • Invent your own recipes

That's what programming would be like without open-source packages. Instead of focusing on what makes your business unique, you'd spend months rebuilding basic tools that already exist.

Open-source packages let programmers focus on the 10% of code that's unique to your business, instead of the 90% that's the same for everyone.

References

[1] Python Software Foundation, "Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance," PyPI Blog, April 2, 2026. [Online]. Available: https://blog.pypi.org/posts/2026-04-02-incident-report-litellm-telnyx-supply-chain-attack/

[2] Python Software Foundation, "How to Secure Your PyPI Token," PyPI Documentation, 2025. [Online]. Available: https://docs.pypi.org/trusted-publishers/

[3] Open Source Security Foundation (OpenSSF), "Securing Software Repositories," OpenSSF, 2024. [Online]. Available: https://bestpractices.coreinfrastructure.org/

[4] CISA, "Securing the Software Supply Chain: Recommended Practices," Cybersecurity and Infrastructure Security Agency, 2024. [Online]. Available: https://www.cisa.gov/resources-tools/resources/securing-software-supply-chain-recommended-practices

[5] Google, "Supply Chain Security Best Practices," Google Open Source Insights, 2025. [Online]. Available: https://ossinsight.io/

[6] Linux Foundation, "Software Bill of Materials (SBOM) Explained," Linux Foundation, 2024. [Online]. Available: https://www.linuxfoundation.org/

[7] Aqua Security, "Trivy Supply Chain Attack: What You Need to Know," Aqua Security, March 2026. [Online]. Available: https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/

[8] NIST, "Supply Chain Risk Management for Small Business," National Institute of Standards and Technology, 2024. [Online]. Available: https://www.nist.gov/itl/small-business cybersecurity

Your software supply chain doesn't have to be a weakness. lilMONSTER helps you use open-source packages safely while protecting your business from supply chain attacks. Book a free consultation to learn more.

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation