Code trust crisis: Is it safe to update your system during an active supply chain attack?

Running a routine Python pip update command on March 24 could’ve pulled malware that stole passwords and crypto savings. Running npm update a week later could've dropped a trojan. Critical LiteLLM and axios attacks expose just how vulnerable dependency trees are. But can you get infected just by running OS update commands like “apt update,” “dnf upgrade,” or “brew upgrade?”

Short answer is yes, but it is a lot less likely, and here’s why.

Due to recent open-source supply chain attacks, the notion that you should always keep your software updated to the latest version is no longer as clear-cut.

Open source has one maintainer problem. Attackers can compromise a developer maintaining a small utility and silently push a malicious update. It gets pulled in by dozens of other packages, which are pulled in by hundreds more. Millions of users would update commands on their systems and get infected.

Open source supply chain attacks are raging

Last week, the LiteLLM hack was a critical Python supply chain compromise that likely infected thousands of developers and many more users who simply installed or updated the packages. This week, thousands of developers likely got hacked due to the NPM supply chain compromise – axios, a hugely popular JavaScript library with 100 million weekly downloads, was infected with malware.

The recent supply chain attacks continue to run and feed threat actors with access to even more packages that might be boring, invisible, or highly dependent on a single, tired developer, but used by millions.

“A routine pip install upgrade during the March 24th window could have installed a fully signed, hash-verified backdoor with no indication anything was wrong, since all integrity checks would still pass. LiteLLM is a transitive dependency across many AI agent frameworks, so developers may have been exposed without ever installing it directly,” said Rock Lambros, Director of AI Security and Governance at Zenity.

Update mechanisms are highly trusted, but security researchers are now warning that they shouldn’t all be treated the same way.

“The risk is in what you are updating. System updates (apt, dnf, brew) are often much lower risk than updated-to language registry packages (PyPi, npm, crates.io) as the OS packages are curated and signed repositories which include vetting and verification,” said Zbyněk Sopuch, CTO of Safetica.

OS updates are a lot safer

Most OS distributions won’t bring the latest code – they bring stable updates that go through a long chain of verification. That also means that the packages are often delivered weeks or months old, and this is by design.

For example, Fedora uses the Bodhi system to test software packages before release – the packages sit for seven days or until enough karma is received from authenticated users. The Debian package sits in “unstable” for at least 10 days, later moves to testing, and can’t get to stable release unless manually reviewed.

If a maintainer of a key dependency gets compromised, there’s no way for the malicious package to immediately reach users.

Amit Chita, Field CTO at Mend.io, considers OS updates like “sudo apt update” to be safe.

“LiteLLM is natively packaged in some OS ecosystems like NixOS and Arch Linux, the malicious PyPI versions (1.82.7 and 1.82.8) were only live for a few hours. The natural delay of OS package maintainers testing and building updates acted as a firewall, keeping the infected builds out of OS repositories entirely,” Chita explains.

Nix package manager still ships LiteLLM version 1.8, which was released in November last year.

“It is crucial to understand that running ‘sudo apt update && sudo apt upgrade’ on a standard system with only official repositories is not meaningfully riskier today because of the LiteLLM incident,” assures Mykhailo Pazyniuk, Senior Malware Research Engineer at Moonlock by MacPaw, a software company behind CleanMyMac and other apps.

That said, even OS updates aren’t completely bulletproof – they all can contain security issues, but the risk of each cautionary scenario is significantly lower.

For example, the xz-utils backdoor was one of the closest near-miss global catastrophes averted due to some luck.

Running “brew upgrade” on macOS also deserves more caution, because Homebrew’s trust model structurally resembles the ecosystem where LiteLLM happened, and attacks on it have already been observed, according to Pazyniuk.

“For routine system-wide updates, the risk of running commands is generally low, as most supply chain attacks tend to target application-level dependencies rather than core operating system packages,” said Michael Clark, Senior Director of Threat Research at Sysdig.

“However, the risk is not zero. If a system package or its distribution channel were compromised, running these commands could potentially install a malicious update.”

Many more repositories are vulnerable to attacks

The supply chain attacks are still actively running. After attackers that hit Trivy, pivoted to Checkmarx's KICS GitHub Action, and infected LiteLLM, later compromised the Telnyx package, and are unlikely to stop.

Cincinnati-based cybersecurity firm Vigilant Defense scanned 50,012 of the most widely used repositories on GitHub and found that 40.6% contain vulnerabilities in their automated build systems – the exact weakness exploited in recent attacks involving the Trivy security scanner and the spread of the CanisterWorm malware.

Vigilant Defense warned that LiteLLM is present in 36% of all cloud environments.

“These weren’t isolated incidents,” said Chris Nyhuis, CEO and co-founder of Vigilant Defense.

“They exposed a systemic issue in how modern software is built and trusted. What we’re seeing is a massive, largely invisible attack surface that most organizations representing global industries don’t realize they’re dependent on.”

The firm identified 192,776 individual security vulnerabilities. The vulnerable code circulates in over 590 million downstream copies. The most popular repositories with 50,000–100,000 stars show a 68.1% vulnerability rate.

Major technology organizations, open-source projects, and cloud platforms are not exempt from flaws.

“GitHub itself hosts at least 25 vulnerable repositories, including starter templates used by developers to build new applications,” Vigilant Defense said.

The company released a free, open-source scanner for GitHub Actions, called Runner Guard, that enables organizations to assess their own vulnerability exposure in CI/CD pipelines.

What can you do to protect yourself?

All experts agree that running OS updates is a safer alternative than leaving the system vulnerable to known, unpatched bugs.

“The broader lesson isn’t ‘stop running updates’ – that would be far more dangerous,” Pazyniuk agrees.

“It's more about constantly auditing your sources and adopting a package update cooldown window.”

Pazyniuk recommends checking which third-party repositories you use and delaying adoption of new dependency versions for 24-48 hours, up to 7 days, especially if they use a single-maintainer publish model, like PyPI’s.

Riccardo Spagni, creator of nsh and uhoh and former lead maintainer of Monero, suggests treating pip, npm, and cargo (Rust) packages “with extreme paranoia.”

“Compromising apt main requires subverting a massive review process. Compromising PyPI just requires stealing one developer's credentials. My advice? Run your system updates,” Spagni concluded.

Safetica’s CTO Sopuch advises developers to schedule production updates for audited maintenance windows and focus on patches for known vulnerabilities.

“Production should not be blindly applying full upgrades in the middle of active supply-chain uncertainty,” Sopuch said.

Developer laptops are at the highest risk of supply chain attacks from language registries (PyPi, npm, crates.io).

Tyler Reguly, Associate Director of Security R&D at Fortra, warns that developers who choose not to pin packages to a specific version expose their users to supply chain threats.

“Whether you use languages like Node or Python, you can define library requirement lists via things like package.json (Node) or requirements.txt (Python),” Reguly said.

Unlock more exclusive Cybernews content on YouTube.