A time for cool heads

As of late March 2026 there has seen a noticeable uptick in sophisticated attacks involving exploits of open source software, originating from the maintainers' systems.

We need to adjust our approach to managing dependencies - the way that our projects bring in external libraries.

We have bots available for detecting when a new verious is available, and automating the upgrade process. With some tweaking of the configuration we can keep the automation, and reduce the risk of picking up a compromised dependency.

I was contemplating giving a few examples of how to configure bots and dependency management tools, but there's already a nice fresh post available for that, so head over there instead.

https://nesbitt.io/2026/03/04/package-managers-need-to-cool-down.html

Are you about to find out the weakest link in your software supply chain?

March 2026 exploits from source 

It's April 2026 (in New Zealand at least). In the last week or so there have been multiple security incidents online involving hackers obtaining access to inject malicious code into popular open source software systems.

I'm not deeply involved in security research, but I am aware of exploits of:

• LiteLLM, a Python proxy system for accessing AI services
• axios, a Node.js HTTP client library

These libraries got pushed up to python's PyPI and Node.js's npm registry respectively, using credentials from the maintainers' systems.

What happened?

For LiteLLM it seems likely that the Github build pipeline involved a compromised trivy GitHub action

https://github.com/aquasecurity/trivy/discussions/10425

For axios it is less clear what the vulnerable path was. My theory is that perhaps the developer involved with the compromised security token may have been dabbling with LiteLLM or something with a similar compromise that leaked the credential.

https://github.com/axios/axios/issues/10604

Both of these exploits involved an edge case of executing without even needing the injected code to be a part of the codebase, so scans originating from the project code would not have picked these up.

So What?

In my opinion, this is going to be an ongoing major issue.

We cannot trust that some simple checks that we apply when downloading from an official source will be sufficient to protect development systems and build pipelines from malicious actors.

Shifting left

It is not enough to have checks in place at the end of a build pipeline to detect malicious code and suspicious changes. We need to protect developer systems, where sensitive credentials will inevitably be located.

There may be some exploits that will be avoidable by only interacting with them within a Docker container or similar constrianed environment, but that would most likely not play well with normal developer workflows that rely on IDEs for quickly running tests, debugging etc.

Push pause

Consider yourself lucky if nobody in your organisation has already been impacted by these exploits, but in the spirit of "never let a good crisis go to waste", I would strongly recommend that you set some time aside to address the shifting landscape and be proactive about ensuring that you do not get caught out by the next exploited dependency for your software.

A chain is only as strong as the weakest link.