, an extremely popular HTTP client for JavaScript, suffered a malicious payload injection attack. While the malicious code was removed within a matter of hours, the package’s popularity means that millions of build systems may have been infected.

This attack is the latest in a growing list of software supply chain attacks, this time linked to 

, where the actors took advantage of the popularity of open source packages to serve malicious payloads to millions of victims. npm credentials have repeatedly emerged as a weak point that malicious actors attack.

The attack vector appears to have been a compromise of the

npm account of one of axios’s maintainers, giving a malicious actor the ability to publish new versions of axios to the 

 registry and add malicious dependencies to the payload.

The malicious payload was added to two branches of axios between 00:20 and 01:00 UTC on 31 March. The malicious version remained live on npm for around 2 hours, in part because the maintainer’s

npm account was the only admin account, preventing other collaborators from shutting down the attack until the case was picked up by npm’s administrators.

The attack appears designed to facilitate crypto-related fraud. The attacker modified 

, which is a new malicious software package that did not exist before yesterday.

 was published 18 hours before the axios updates. The compromised payload, in a new version of 

, deploys a remote access trojan that’s tailored for the host’s operating system. This is a textbook supply chain malware injection incident. Systems that configure their build managers to install the latest version by default are subject to compromise in this style of attack. That’s probably a huge number of systems, given that 

 is a popular project, with over 100 million weekly downloads on 

How to secure your supply chain against future attacks

The axios breach comes less than a week after another popular package, 

, the canonical Python public registry. Very popular open source packages are an attractive attack vector for malicious actors. Once a malicious payload like this enters your software supply chain, it can do irreversible damage almost immediately. Cleanup is often a slow and frustrating process, and regulations such as the EU's Digital Operational Resilience Act (DORA) and the Cyber Resilience Act (CRA) require companies to report these incidents within 24 hours, or face substantial fines.

Here’s how to protect your software supply chain:

Route all package requests through a private registry proxy, like Cloudsmith.

 Sitting between your developers and public registries, Cloudsmith creates a checkpoint, applying security policies before packages reach build environments or developers’ local machines.

This proxy buffer is a key component of Cloudsmith. With Cloudsmith as your control plane, every public package, and base Docker container image, is subject to scanning and security policies before anything reaches your build systems.

 was created less than a day before the attack. It was published specifically as part of a malicious payload before the compromised axios versions were published. Blocking package versions less than 7 days old (the specific age is configurable) is one of the most effective ways to stop this class of attack, giving security researchers time to identify the vulnerability.

In 2025, 99% of malicious npm packages were identified and officially verified within 72 hours – implementing a simple cooldown policy significantly reduces the attack vector.

Cloudsmith users with a cooldown policy in place would block 

 even before malicious behaviour was reported, protecting their software supply chain from this attack.

You can configure cooldown policies in many package managers, but Cloudsmith allows you to set the policy at an organisational level, so it’s enforced across formats, teams, and build systems consistently.

Subscribe to real-time threat intelligence feeds.

 Cloudsmith subscribes to databases like OSV.dev and the OpenSSF Malicious Packages project, which update in near real-time.

. Using a system like Cloudsmith to integrate these feeds into your package policies means you get automatic protection as new threats are identified.

 can act on these intelligence feeds, so anti-malware policies trigger even after the cooldown period ends. We’ve written before about how 

Cloudsmith’s policy manager protects your software supply chain

Creating a Malicious Package policy in Cloudsmith

. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

 for this policy, such as to quarantine, tag, or block package promotion.


If you are interested in evaluating proactive security policies for poisoned/malicious software packages, 

 about protecting your software supply chain from attacks like the one on axios.

Axios 1.4.1 and 0.30.4 NPM packages compromised

 Dependabot is great at keeping dependencies current, but update automation and ingestion control solve different problems. Cloudsmith acts as an upstream gatekeeper; ensuring packages are verified before they ever enter your environment. Together, they cover more of the supply chain than either does alone.

Let’s frame a scenario: a new dependency version is released. Within hours, Dependabot opens a pull request to upgrade your application.

The change looks routine. The PR is merged.

But this version wasn’t just an update - it was part of a coordinated malware campaign.

Before long, the compromised package has made its way into your build environment, cache layers, and developer workstations. Your security team is pulled into incident response, and a difficult question follows:

How did this get through so quickly, and how do we prevent it next time?

How dependency updates become a supply chain risk

To understand how this scenario unfolds, it’s worth breaking down what actually occurs between a dependency being published and a pull request being merged. When a new version of a package is released by a maintainer (or malicious actor in this case), it becomes immediately available in upstream registries such as npmjs, pypi, Maven Central, or DockerHub.

Tools like Dependabot continuously scan your repository’s dependency files for updates. As soon as a new version is detected, Dependabot compares it against what your application is currently using. If a valid upgrade path exists, it automatically opens a pull request with the updated version. From a developer’s perspective, everything looks normal:

The dependency comes from a trusted source

The version increment appears routine (ie. “It’s probably a patch or security fix”)

The pull request follows a familiar, repeatable workflow

Nothing appears out of the ordinary - which is exactly how these attacks are designed.

At no point in this process is there a built-in mechanism to evaluate whether a newly released version is too new, potentially unverified, or part of a broader security incident without additional manual investigation. To make matters worse, it often takes time for security researchers to identify and report malicious packages, leaving a window where compromised versions can spread undetected.

That's not a criticism of the tool, it's a reminder that no single layer of automation was built to catch everything.

The problem isn’t automation; it’s the absence of an upstream control layer that determines when a dependency can be trusted and safely consumed

Dependabot cooldowns: Helpful, but not a complete safeguard

To address the risk of organizations rapidly adopting new dependencies, Dependabot offers a cooldown feature that allows platform teams to introduce a delay before opening pull requests for newly released dependency versions.

In practice, this means that even if a new version becomes available in the registry, Dependabot will intentionally wait for a defined period of time before suggesting the update through the pull request.

This provides an additional layer of protection:

It gives the ecosystem the time to detect and flag malicious packages

It reduces the likelihood of of immediately adopting unverified releases

It helps avoid 0-Day exposure to newly published vulnerabilities

For many teams, this delay can significantly reduce risk. However, it’s important to recognize what this control does and does not protect against. Dependabot’s cooldown feature operates at the pull request level, meaning that it controls when an update is suggested, but it does not control what is ultimately available to your build systems or developers once a version is accessible in a registry.

Once a dependency version is published and reachable, it can still be:

Downloaded outside of Dependabot entirely

In other words, Dependabot’s cooldown feature only influences one path to consumption, but not all paths. This naturally creates a gap: even with cooldown in place, a malicious package can still be consumed before it is ever flagged or blocked. While Dependabot’s cooldown can help reduce noise and delay exposure, they do not enforce a boundary around what dependencies your organization is allowed to consume.

If Dependabot’s cooldown helps reduce the speed of adoption, the next question becomes:

What controls when a dependency is allowed to exist in your environment at all?

Dependabot's cooldown helps slow the rate of adoption, but it doesn't control what dependencies are reachable in the first place. To close that gap, organizations need a control layer that sits upstream of their build systems entirely - one that determines whether a dependency is even available before any tool can request it.

Introducing an upstream gatekeeper for dependency security

 comes in as your upstream gatekeeper. Instead of allowing direct, unrestricted access to upstream packages, Cloudsmith acts as a controlled gateway. With Cloudsmith Advanced Security, organizations can also introduce cooldown periods as policies to introduce time-based buffers to quarantine newly published dependency versions across a variety of different package formats.

For example, I currently work with a customer who has implemented a 5-day cooldown period for all npm packages with an updated version within that 5 day window. During this time, the customer can:

Check security advisories for any potential malware

Validate the upstream maintainer and perform additional reconnaissance

Only after the 5 day cooldown period is the package unquarantined and made available for download. When combined with Dependabot’s cooldown feature, organizations can layer the Dependabot cooldown with Cloudsmith’s to maximize security. Here’s an example workflow:

On Day 0, a new dependency version is released.

 The version exists upstream, but Cloudsmith intentionally keeps it out of reach in quarantine state. It cannot be pulled by developers or CI/CD pipelines.

 The version becomes available through Cloudsmith after the cooldown period has passed.

 Dependabot is pointed to Cloudsmith, and now detects the newly available version and opens a pull request.

Cloudsmith controls when the version becomes consumable, while Dependabot controls when the version is proposed. Together, they ensure that updates are both safe and timely, without exposing the organization to newly released, potentially risky artifacts.

Modern software delivery depends on automation, and tools like Dependabot have made keeping applications current easier than ever. But automation can only work safely within the boundaries set for it. Without an upstream control layer, every newly published dependency version is immediately exposed to your systems, trusted by default, not by design.

By pairing Dependabot with Cloudsmith's upstream cooldown policies, you create a model where trust is earned over time rather than assumed at the moment of release. Small in implementation, significant in impact: that shift is what allows teams to move fast without leaving the door open.

This layered approach is essential for organizations looking to strengthen their 

 without slowing down development velocity.

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

 that most developers in the AI space saw within hours: a simple 

 exfiltrated SSH keys, cloud credentials, Kubernetes secrets, API keys, crypto wallets, and more from any machine that ran it. He called it “software horror.” Given the scale, LiteLLM has 

The good news: this attack is exactly the kind of thing a well-configured artifact management setup is built to stop.

LiteLLM is an open-source Python library that acts as a universal API gateway for large language models. Instead of writing separate integration code for OpenAI, Anthropic, Google, and dozens of other providers, developers use LiteLLM to call all of them through a single standardized interface. It's a natural fit for any team building AI-powered applications, which is why it's become something close to infrastructure, with close to 100 million downloads per month.

That position in the AI stack, sitting between applications and every LLM provider, is also what made it an attractive target. A package with that kind of access to API keys and environment variables is worth compromising.

The threat group behind this, known as TeamPCP, didn't find a bug in LiteLLM's code. They worked their way up the supply chain: first compromising Trivy, a widely used open-source security scanner (

), then using that foothold to steal LiteLLM's PyPI publishing credentials. With those credentials, they uploaded two backdoored versions of LiteLLM directly to PyPI. This required no pull request, no code review, and nothing to inspect.

Standard integrity checks passed. The packages were published using legitimate credentials, so there was no hash mismatch, no suspicious metadata, no misspelled package name. The malicious versions were live for roughly three hours before PyPI quarantined them.

Three hours is a narrow window, but it's wide enough. And as Karpathy noted, the attack was only discovered because a bug in the malware crashed a researcher's machine.

The more unsettling detail is how far the blast radius extends. The contagion spreads to any project that depends on LiteLLM. This includes teams using it directly and anyone running 

 or any other package with LiteLLM in its dependency tree. Most developers have no visibility into what their dependencies depend on, let alone controls over it.

Three moments where this attack could have been stopped

The LiteLLM attack didn't require beating sophisticated defenses. It required developers pulling packages directly from a public registry with no organizational governance layer in between.

That's the gap Cloudsmith closes. It makes sure that your team doesn’t pull directly from PyPi without a policy check first.

Here's how that works in practice, mapped to the specific failure modes in this attack.

Cloudsmith acts as a proxy between your developers and upstream registries like PyPI. Packages don't arrive on developer machines directly from PyPI, they pass through Cloudsmith first, where your organization's policies apply. This one change puts every subsequent control within reach.

Apply a quarantine window to new package versions.

Cloudsmith lets you configure a cooldown policy that holds newly released versions in quarantine before they enter your environment and get served to your team. This gives the security community time to identify problems before your developers install anything. The policy applies organization-wide; it doesn't depend on individual developers remembering to check a release date or configuring pip correctly. The three-hour window that defined the LiteLLM attack becomes irrelevant if new versions don't reach your developers for 7 to 14 days.

Even on disciplined teams, a developer working quickly on their laptop might pull directly from PyPI. That's why your CI/CD pipelines should point to Cloudsmith independently of workstation configuration. Code that pulls a bad version locally doesn't survive the build pipeline because it gets caught before it reaches staging, production, or any shared infrastructure.

The LiteLLM attack is a useful reminder that AI tooling is software, and software has a supply chain. As AI agents take on more autonomous roles in development – installing dependencies, running builds, pulling packages – the same governance principles apply whether the consumer is a human or an agent. Controlling what packages enter your environment is part of running AI infrastructure responsibly.

If you'd like to understand your current exposure, 

 with Cloudsmith for a custom assessment of your software supply chain.

How Cloudsmith can protect against the LiteLLM attack

Software supply chains are complex and increasingly fragile. For enterprise teams, managing an ecosystem of open-source packages, container images, and AI/ML models is no longer just a storage problem, it is a delivery and governance challenge.

Cloudsmith processes petabytes of artifact data every month for global enterprises. To meet these demands, we didn't just move our platform to the cloud. We built a genuinely cloud-native platform from day zero, using AWS to ensure that every artifact is fast, available, and trustworthy.

The architecture of trust: Why cloud-native matters

Many legacy artifact management tools were designed for a different era. Cloud-hosted is different from cloud-native. Cloud-hosted solutions typically begin as on-premise software that vendors retrofit to run on cloud servers. This architecture doesn’t eliminate operational maintenance; it shifts it from managing physical hardware to managing patching, upgrading, and complex high-availability configurations.

Cloudsmith is different. By building natively on AWS, we provide a platform that abstracts away infrastructure headaches.

: We handle all updates, patches, and scaling. Teams can stop firefighting infrastructure incidents and focus on shipping value.

: Our system uses multi-region redundancy by default. There is no single point of failure, ensuring that builds don't stall even if a specific region or load balancer goes down.

: AWS allows us to scale horizontally and vertically. Whether you are running ten builds or ten thousand, the platform maintains consistent performance without manual tuning.

That elasticity matters beyond traditional binary packages, too. As AI/ML models become standard supply chain assets, the architecture has to handle their size (often measured in gigabytes) without a separate delivery strategy.

Performance at the edge: Global delivery without the latency

With AWS, Cloudsmith takes advantage of what the cloud makes possible: elastic compute, global reach, and the ability to serve large enterprise customers without the operational overhead of managing infrastructure.

The edge is where that global reach becomes tangible for our customers. These are the AWS services we use to deliver global performance and reliability.

 is the backbone of how we distribute artifacts. With over 600 points of presence worldwide, CloudFront allows us to serve packages from as close to the requester as possible. Whether a developer pulls a dependency from their local machine or an automated build system fetches a container image at 2am, an edge location near them serves the request. That proximity is what makes the performance difference our customers depend on.

 extend that further. Authentication and intelligent routing are not afterthoughts in Cloudsmith; they're core to how the platform works. Cloudsmith needs to authenticate and correctly route every incoming request before serving the artifact. CloudFront edge functions enable that logic to run at the edge itself, not at a central registry on the other side of the world. The processing happens where the request is. The result is that every millisecond we would otherwise spend routing back to origin is recovered at the edge, and across the volume of requests we handle – tens of millions per day – those milliseconds add up to faster and more reliable builds for customers.

protects the perimeter of the Cloudsmith platform. While the software supply chain is a high-value target for malicious actors, WAF allows us to block common web exploits and automated bots before they ever reach our API. By leveraging AWS Managed Rules, we ensure our defenses are updated in real-time against emerging threats. This allows us to maintain a high-availability environment where the platform remains performant and accessible only to legitimate users, ensuring the infrastructure behind your artifacts is as secure as the artifacts themselves.

Together, these three AWS services give Cloudsmith the global reach, edge processing capability, and security posture to serve enterprise customers at scale – reliably, and with the performance they need.

AWS EDGE Innovation Spotlight: Cloudsmith | Amazon Web Services

Catch the full conversation: VP of Engineering Ronan O'Dulaing sat down with AWS to discuss how Cloudsmith uses AWS to power its cloud-native artifact management platform. 

A specialized control plane vs. basic registries

Cloud providers offer their own basic artifact registries, but they focus on identity and access management rather than comprehensive supply chain governance.

Cloudsmith provides a unified control plane that goes beyond simple storage. Unlike basic registries or package managers embedded in developer platforms, Cloudsmith delivers:

: We support 30+ package formats, including AI/ML models, in a single repository.

: Using our policy management capabilities (built on OPA), organizations define precise compliance rules. You decide what artifacts are untrusted or non-compliant and block them before they ever enter your environment.

: We don't just scan your artifacts. We continuously enrich packages with new vulnerability and malware intelligence data, ensuring your software supply chain remains protected as new threats emerge.

AI has changed the requirements for artifact management. ML models are significantly larger than traditional software packages, often reaching multi-gigabyte sizes.

Our AWS-backed architecture allows us to adapt. We parallelize metadata fetching and artifact pulls to ensure reliable delivery of massive models. Because we leverage AWS's global reach, these large files still benefit from the same low-latency edge delivery as a standard Python package.

Delivering revenue-critical software with confidence

Reliability and performance are the baseline expectations for modern software delivery. By building a genuinely cloud-native platform on AWS, Cloudsmith ensures that your delivery pipelines are predictable, resilient, and secure.

You don't have to manage clusters, configure regions, or worry about manual replication. You simply get a fast, governed, and reliable software supply chain–globally, and at scale.

See how Cloudsmith handles your specific tech stack. 

How Cloudsmith builds on AWS to deliver enterprise-level speed and uptime

Yes. DORA became fully applicable on January 17, 2025. By 2026, the grace period for initial Register of Information (RoI) submissions has passed.

Is DORA already in effect?

Threat-Led Penetration Testing (TLPT) is a high-intensity "red team" exercise using the TIBER-EU framework. It is mandatory every three years for systemically important financial institutions.

What is TLPT under DORA?

NCAs can impose periodic penalty payments of up to 1% of the average daily worldwide turnover for the preceding business year.

What are the penalties for non-compliance?

While "SBOM" isn't explicitly named, the requirements in Articles 8 and 30 for asset inventory and supply chain visibility make a software bill of materials the most practical way to achieve compliance.

Does DORA require an SBOM?

Common DORA compliance questions (FAQs)

Digital Operational Resilience Act (DORA) compliance is mandatory as of January 17, 2025. For 2026, the focus shifts from initial implementation to 

. Financial entities must maintain a risk management framework, report major incidents within 24 hours, conduct annual resilience testing, and manage third-party risk via a formal Register of Information (RoI).

, commonly known as DORA, is a landmark EU regulation designed to strengthen the IT security of financial entities. Unlike previous guidelines, which were fragmented across sectors and countries, DORA provides a single, harmonized rulebook for digital resilience.

Its primary goal is to ensure that the European financial sector remains resilient in the face of severe operational disruptions, such as cyberattacks, system failures, or third-party outages.

DORA applies to over 22,000 entities across the EU and their global ICT providers, including the following:

 Banks, credit institutions, and payment providers.

 Investment firms, insurance undertakings, and intermediaries.

 Crypto-asset service providers and crowdfunding platforms.

 Critical ICT third-party providers (including cloud service providers and software vendors) who serve the financial sector.

Why DORA compliance is the 2026 "North Star" for financial risk

DORA is no longer a "future project". We are now over a year into the enforcement era. EU competent authorities (NCAs) are actively auditing implementations, specifically looking for evidence of 

DORA establishes uniform, enforceable resilience standards across 22,000+ entities, including banks, insurers, crypto-asset providers, and their critical ICT third-party providers. If you operate or serve clients in the EU, DORA is your primary regulatory hurdle.

The DORA compliance checklist: The five pillars of resilience

DORA organizes its requirements into five distinct pillars. Use the checklists below to audit your current posture against the specific Articles and Regulatory Technical Standards (RTS).

Pillar 1: How to build a DORA-compliant ICT risk framework (Articles 5-16)

Board-level accountability is the cornerstone of Pillar 1. Article 5 dictates that the management body, not just the CISO, owns the risk.

 Management has approved and actively oversees the ICT risk framework.

 A continuously updated register of all hardware, software, and services, classified by criticality.

 Network segmentation, identity management, and rapid patch cycles are documented and enforced.

 An ICT disaster recovery plan exists with defined RTOs/RPOs, tested and updated within the last 12 months.

 Backup procedures are isolated from primary production environments to prevent ransomware lateral movement.

Pillar 2: Managing ICT incident reporting timelines (Articles 17–23)

In 2026, "major" incidents require a strict three-stage reporting cadence to your National Competent Authority (NCA):

 Within 4 hours of classification (max 24 hours from detection).

 Incident management tools are configured with DORA RTS criteria (client impact, data loss, geographic spread).

 Workflows trigger immediate alerts to the legal and compliance teams when "Major" thresholds are hit.

 All incidents (even minor ones) are logged in an auditable record for year-end trend analysis.

Pillar 3: Executing digital operational resilience testing (Articles 24–27)

Standard pentesting is no longer sufficient for systemically important institutions (G-SIIs, O-SIIs, etc.).

 All critical ICT systems undergo vulnerability assessments at least once a year.

 certified test is scheduled every 3 years.

 Open-source packages and container images are scanned for CVEs before they reach production.

Pillar 4: Mitigating ICT third-party risk (Articles 28–44)

This is the most common area for audit findings in 2026. Article 28 requires a 

 of all third-party ICT arrangements in a specific EBA-compliant format.

 A full register of ICT vendors exists and has been submitted to the NCA via the 2026 reporting portals.

 All vendor contracts include mandatory provisions on data locations, audit rights, and exit strategies.

 Compliance extends to "material subcontractors" (the fourth party) providing critical functions.

Software Bill of Materials implementation:

 A SBOM (SPDX or CycloneDX) is generated for all proprietary and third-party software.

Pillar 5: Voluntary information and intelligence sharing (Articles 45–49)

While Article 45 is voluntary, regulators view active participation in 

 (ISACs) as a sign of high operational maturity.

 The organization participates in a sector-specific threat-sharing community.

 Threat indicators received from external partners are automatically ingested into SOC workflows.

The "Invisible" gap: Software supply chain provenance

 Every open-source package or container image pulled from a public registry is a "third-party ICT dependency." Under Articles 8 and 30, you must know what is in your software and prove its integrity. This is where 

, knowing exactly where code came from and who touched it, becomes a regulatory requirement.

Cloudsmith provides a specialized, cloud-native 

 that serves as the foundation for software supply chain security and DORA alignment. By acting as a centralized "source of truth", Cloudsmith enables financial institutions to move away from fragmented, manual processes toward a unified DevSecOps environment where compliance is baked into the development lifecycle.

The platform ensures continuous identification, tracking, and management of every software component, whether proprietary code or a third-party open-source dependency. Through automated, configurable policy gates, Cloudsmith enables organizations to define strict quarantine rules that align with DORA’s risk-reduction intent, effectively blocking vulnerable or malicious packages before they ever enter the build environment. This proactive stance on 

Cloudsmith Blog

We built Cloudsmith for this moment

The AI speed trap: Securing the future of software supply chains

The 2026 guide to software supply chain security: From static SBOMs to agentic governance

Cloudsmith Broadcasts: Distribute software on your own terms

Stardrop: New cross-industry npm campaign

Cloudsmith in your IDE: Package intelligence, security remediation, and Infrastructure as Code inside your editor

Performance matters: How infrastructure impacts CI/CD

Closing the enforcement gap: Why visibility isn’t enough for supply chain security

The AI speed trap: Securing the future of software supply chains

Axios 1.4.1 and 0.30.4 NPM packages compromised

Layered defense for dependencies: Why dependabot needs an upstream gatekeeper

How Cloudsmith can protect against the LiteLLM attack

How Cloudsmith builds on AWS to deliver enterprise-level speed and uptime

How to achieve DORA compliance: The complete checklist for financial institutions

Cloudsmith’s take on Chainguard Repository