TL;DR

Open source packages are a fundamental part of modern software development and increasingly underpin AI and agentic applications. Agent frameworks, model SDKs, MCP integrations, AI gateways, orchestration libraries and supporting infrastructure routinely depend on packages sourced from public registries such as npm and PyPI.

Recent incidents demonstrate that attackers are exploiting this trust at multiple points in the software supply chain.

In August, 2026, Unit 42 published its analysis of ChainDrop, a self propagating npm supply chain worm capable of extracting credentials from GitHub Actions runner memory, establishing persistence in developer environments and using Ethereum smart contracts for command-and-control resolution.

Singapore's Cyber Security Agency reported that the campaign had compromised more than 1,300 npm package versions representing a combined 2 billion monthly downloads, including packages associated with keyv, cacheable, flat-cache and file-entry-cache.

The threat also directly affects agentic AI software.

In June, 2026, StepSecurity reported that an attacker compromised the @mastra npm organization and added the malicious easy-day-js dependency across more than 140 packages in the Mastra AI framework ecosystem. The affected packages had a combined weekly download count exceeding 1.1 million. The malicious dependency contained an obfuscated postinstall dropper that retrieved and executed a second-stage payload.

These incidents are part of a broader pattern. Unit 42 has documented successive 2026 compromises involving Axios, TanStack, Mistral AI, Red Hat Cloud Services and AsyncAPI, including attacks that stole npm and GitHub credentials to propagate into additional legitimate packages.

Our own analysis provides another signal.

Our Findings

In our analysis of some of the most downloaded packages across PyPI and npm, we classified close to 2% of open source packages as malicious or suspicious.

This percentage should not be interpreted as the malicious-package rate for PyPI or npm as a whole. It reflects the results of our analyzed dataset and classification methodology.

But combined with the recent supply-chain compromises, it reinforces an important security principle: Open-source software should not inherit trust solely from its package name, popularity, publisher or presence in a legitimate registry. The specific artifact entering the environment must itself be evaluated.

What Happened

Attackers are targeting the trust chain itself

Malicious package risk is not limited to attackers creating obviously fake packages.

Recent incidents demonstrate several distinct paths through which malicious code can enter trusted software ecosystems:

• malicious packages intentionally published by attackers;
• typo-squatted packages;
• compromised maintainer or publisher credentials;
• compromised repositories;
• compromised CI/CD pipelines;
• abuse of legitimate release workflows;
• malicious dependencies introduced into legitimate packages.

The important distinction is that in several recent incidents, the package being installed was itself legitimate and widely used. The attacker compromised the mechanism used to produce or distribute it.

August 2026 - ChainDrop

ChainDrop provides the most recent large scale example.

Unit 42 analyzed the malware and confirmed that it contains functionality specifically targeting GitHub Actions runners. An embedded Python component locates the Runner.Worker process, reads its process memory and searches for OIDC tokens and runner secrets.

The malware also established developer environment persistence.

Unit 42 found that it created a .vscode/tasks.json configuration that automatically executes malicious code when a developer opens the affected project in VS Code. The payload also placed code under .claude, creating persistence that intersects directly with AI assisted developer workflows.

ChainDrop additionally used Ethereum smart contracts to resolve command-and-control infrastructure and retained the ability to execute attacker supplied code.

Singapore's Cyber Security Agency subsequently warned of an ongoing supply chain campaign involving ChainDrop and reported more than 1,300 compromised npm package versions with approximately 2 billion combined monthly downloads.

The important security progression is:

Compromised package → execution in developer/CI environment → credential access → additional compromise and propagation

This turns the package ecosystem itself into a distribution mechanism.

June 2026 - Mastra: Agentic AI Packages Were Directly Compromised

The threat is not merely adjacent to AI.

It has already reached an agentic AI framework.

In June, StepSecurity reported compromise of the @mastra npm organization. More than 140 Mastra packages were republished with easy-day-js added as a production dependency.

Mastra is an open-source TypeScript framework used to build AI agents, workflows and RAG applications and provides integrations involving LLM providers, agent memory, MCP servers and vector databases.

The attack used an interesting staged mechanism.

The attacker first published easy-day-js@1.11.21, which StepSecurity found to be a clean copy designed to resemble the legitimate dayjs package. The Mastra packages referenced it using a compatible semver range.

The attacker then published easy-day-js@1.11.22 containing a postinstall hook:

node setup.cjs --no-warnings

Fresh installations resolving the dependency could therefore retrieve the malicious version.

StepSecurity observed that the malicious version contained an obfuscated dropper that retrieved a second-stage payload from attacker controlled infrastructure and then deleted itself.

This incident provides a direct connection between traditional software supply chain compromise and agentic AI infrastructure.

The model itself did not have to be attacked.

The framework underneath the model was the attack surface.

July 2026 - AsyncAPI: The Release Pipeline Became the Attack Path

In July, attackers compromised release pipelines associated with four core AsyncAPI GitHub repositories and published five trojanized npm package versions.

Unit 42 found that the projects had protections and peer review on primary branches, but certain pre production release branches were not equivalently protected.

Attackers pushed malicious commits directly to those branches, triggering automated GitHub Actions build and release workflows.

This matters because the attacker did not need to replace the registry or impersonate AsyncAPI.

The attacker abused a legitimate route from: repository → CI/CD → build → registry to distribute malicious packages.

Provenance Is Necessary-but Not Sufficient - Red Hat Cloud Services

The 2026 Red Hat Cloud Services compromise provides another important lesson.

Unit 42 documented at least 32 compromised packages under the @redhat-cloud-services npm namespace. A compromised employee GitHub account was used to push malicious commits that triggered GitHub Actions publishing workflows.

The resulting malicious packages carried valid SLSA provenance.

The provenance was not false.

The packages really had been produced by the declared build pipeline.

The problem was that the build pipeline had processed attacker controlled code.

ChainDrop subsequently demonstrated the same underlying limitation. Unit 42 notes that valid npm provenance establishes that an artifact came through the workflow identified by the certificate; it does not establish that the code processed by that workflow was benign.

Therefore, provenance establishes lineage. It does not independently establish trustworthiness. Provenance should be one trust signal, not the entire trust decision.

May 2026 - The Blast Radius Reached Mistral AI

Unit 42 documented another major campaign on May 11.

The initial attack targeted the TanStack GitHub Actions CI pipeline. Within six minutes, Unit 42 observed 84 malicious package artifacts across 42 @tanstack/* packages.

By the end of the day, Unit 42 had documented:

373 malicious versions across 169 npm packages, in addition to compromised PyPI packages.

Among the affected packages were:

@mistralai/mistralai

and related Azure/GCP variants-the official Mistral AI TypeScript client packages.

Other affected ecosystems included OpenSearch and UiPath. Again, AI software was not isolated from the traditional software supply chain. It was part of it.

March 2026 - LiteLLM

LiteLLM provides an earlier AI specific example. The LiteLLM project confirmed that PyPI versions: 1.82.7 and 1.82.8 were compromised on March 24, 2026.

The project reported that initial evidence indicated that malicious packages were uploaded directly to PyPI rather than through its official release workflow.

The malicious versions included credential stealing functionality designed to search for:

• environment variables
• SSH keys
• AWS, GCP and Azure credentials
• Kubernetes tokens
• database passwords

The stolen information was encrypted and exfiltrated to infrastructure not operated by LiteLLM. LiteLLM reported that its GitHub source repository itself was not compromised. This illustrates another critical distinction: Trusted source and trusted package are not necessarily the same thing.

The artifact distributed through a registry must itself be verified.

The Core Attack Pattern

Across these incidents, several recurring behaviors can be established from observed evidence.

1. Compromise a point in the software trust chain

Observed targets have included:

• Maintainer identity
• Source repository
• CI/CD workflow
• Publishing mechanism
• Registry

The attacker does not necessarily need to compromise every component. Compromising one sufficiently trusted point can be enough to introduce malicious software downstream.

2. Insert or introduce malicious code

Attackers have used multiple mechanisms.

• Mastra packages were modified to introduce a malicious dependency.
• AsyncAPI release branches were modified with malicious commits that triggered legitimate publishing workflows.
• LiteLLM's compromised PyPI artifacts contained malicious code that was absent from the project's legitimate source repository.

There is therefore no single artifact-poisoning technique. The common objective is to cause trusted dependency resolution to deliver attacker controlled code.

3. Execute inside trusted environments

Execution can occur as part of:

• package installation
• dependency resolution
• application startup
• package import
• build or CI/CD execution
• developer workflow execution

4. Harvest credentials and secrets

Credential harvesting is a recurring capability. Unit 42 documented 2026 campaigns targeting:

• GitHub tokens
• npm tokens
• SSH keys
• AWS credentials
• GCP credentials
• Azure credentials
• Kubernetes tokens
• HashiCorp Vault secrets
• CI/CD credentials

ChainDrop went further by reading GitHub Actions runner process memory to recover transient OIDC tokens and runner secrets.

5. Use stolen trust to expand the compromise

Unit 42 describes wormable propagation as a defining characteristic of recent npm attacks: malware prioritizes theft of npm tokens and GitHub Personal Access Tokens that can then be used to infect and republish legitimate packages.

This creates a dangerous feedback loop:

Compromise package → Steal credentials → Gain access to another trusted project → Publish another compromised package → Reach another population of developers

The software ecosystem provides the distribution infrastructure.

Why Agentic AI Changes the Impact

These attacks are fundamentally software supply chain attacks. They do not become AI attacks merely because an affected developer uses an LLM. But modern agentic applications increasingly depend on the same software ecosystems being targeted.

Mastra demonstrates this directly: an agentic AI framework's npm organization was compromised and more than 140 packages were modified.

Mistral's official TypeScript client was among packages affected during the May campaign documented by Unit 42.

LiteLLM demonstrates the same issue within AI gateway infrastructure.

ChainDrop even established persistence involving .claude and VS Code project configuration, directly intersecting AI-assisted developer environments.

The key security observation is therefore: An attacker does not need to compromise the LLM if they can compromise the software that surrounds it.

No prompt injection is necessary. No jailbreak is necessary. No reasoning hijack is necessary. The malicious package already has code execution.

The Attack Progression Across the AI Kill Chain

The Tactic and Technique names below are our AI Kill Chain classification of the observed attacker behavior. They are not terminology assigned by the cited researchers.

Not every supply chain attack traverses every AI Kill Chain stage. Where the observed behavior does not require an AI specific stage, the mapping is explicitly marked N/A.

1. Reconnaissance — Active. Adversaries identify packages, repositories, publishing paths, maintainers, or CI/CD workflows whose compromise can provide access to downstream consumers — the targeted-ecosystem selection seen across ChainDrop, Mastra, AsyncAPI, and Red Hat.
2. Trust Manipulation — Active. Existing trust in legitimate package names, publishers, repositories, or build infrastructure causes a malicious artifact to retain the appearance of trusted software, as with easy-day-js masquerading as a dayjslike utility inside the Mastra ecosystem.
3. Input & Instruction Weaponization — Active. Malicious code or malicious dependencies are introduced into packages or release artifacts that will subsequently be consumed by downstream applications — the staged easy-day-js versions, the AsyncAPI trojanized releases, and the LiteLLM PyPI-only compromise are all instances of this.
4. Reasoning-Time Execution — Bypassed entirely. Package execution does not require manipulation of model reasoning. The AI system can reason exactly as intended while the software infrastructure underneath it is already compromised — no prompt injection, jailbreak, or reasoning hijack is necessary.
5. Tool Invocation — Active. Executing package code accesses host capabilities such as processes, filesystems, environment variables, network access, and other functionality available to the compromised process — for example, ChainDrop's embedded component reading GitHub Actions runner process memory.
6. Privilege Escalation — Active. Malicious code accesses credentials and identities available within developer or CI/CD environments that exceed the legitimate functional requirement of the package, as seen in the credential-harvesting functionality documented across ChainDrop, LiteLLM, and the TanStack-linked campaign.
7. Lateral Movement — Active. Stolen GitHub, npm, CI/CD, or related credentials are used to compromise additional trusted repositories or packages and distribute malicious versions downstream — the wormable propagation pattern Unit 42 describes as defining recent npm attacks.
8. Persistence — Active. Malicious state is introduced into developer workflows to regain execution. ChainDrop created VS Code task configuration and .claude content that could execute when affected projects were opened.
9. AI-Native C2 — Bypassed entirely. AI-native C2 is not required for these compromises. ChainDrop used Ethereum smart contracts for C2 resolution, which is a conventional malware C2 mechanism rather than an AI-native control channel.
10. Action on Objectives — Active. Malicious code collects credentials and other sensitive information and exfiltrates it, or uses the recovered identities to expand the supply chain compromise.

One of the most important observations from this mapping is that Stage 4 — Reasoning-Time Execution — can be bypassed entirely. The AI system can reason exactly as intended while the software infrastructure underneath it is already compromised.

The Difference With Traditional Systems

The underlying problem is not unique to AI. The difference is where the compromised package may execute and what identities may be available to it.

Traditional software-composition analysis has heavily emphasized: Dependency → vulnerability → CVE → remediation. This remains essential. But a malicious package presents a different problem: Dependency → intentionally malicious behavior → execution

There may be no vulnerability to exploit. The malicious functionality is itself the implementation.

A CVE-oriented vulnerability scanner primarily answers whether a this component contains a known security weakness. Malware and supply chain analysis must additionally answer if the artifact itself is trustworthy.

What Our Analysis Adds

Recent incidents establish that open source packages are actively being used as attack vehicles.

Our package analysis asks a different question: What happens when we proactively evaluate popular open-source software before trusting it?

Across approximately 60,000 of the most downloaded packages from PyPI and npm, our analysis classified 794 as malicious and 232 as suspicious. That is 1,026 packages requiring security attention within the analyzed population. The finding should not be extrapolated into a prevalence rate for the entire npm or PyPI ecosystems without additional statistical analysis.

What it does demonstrate is that even within a population selected around package adoption, security analysis still surfaced a meaningful number of artifacts that should not automatically be trusted.

Recent compromises show why this is necessary.

Popularity is not integrity.

ChainDrop affected heavily consumed packages.

Legitimate ownership is not integrity.

Mastra's legitimate npm organization was compromised.

Legitimate source does not necessarily establish registry integrity.

LiteLLM confirmed that its GitHub source was not compromised while malicious versions were distributed through PyPI.

Legitimate CI/CD does not guarantee a benign artifact.

AsyncAPI's legitimate GitHub Actions workflows were triggered by attacker controlled commits.

Valid provenance does not establish benign behavior.

The Red Hat Cloud Services compromise produced malicious packages with valid SLSA provenance because the legitimate build workflow processed attacker-controlled code.

The conclusion is not that these trust signals are useless but the fact that no single one is sufficient.

How to Prevent This Class of Attack

The appropriate security model is continuous, multi-signal verification before trust is granted.

Verify identity

Establish that the package is:

• the expected package
• from the expected namespace
• published by the expected identity
• associated with the expected project

This helps address impersonation and typo-squatting.

Establish provenance

Determine the source that this artifact come from. Validate its relationship to:

• source repository
• build system
• release workflow
• publisher
• registry artifact

But provenance should remain one input into the decision rather than the final decision.

Verify artifact to source integrity

Where practical, determine whether the published package corresponds to expected source. Unexpected divergence between source and distributed artifact should be treated as a significant security signal.

LiteLLM demonstrates why: malicious PyPI versions existed while the project's source repository remained unaffected.

Analyze malicious behavior

Security analysis should examine behaviors such as:

• credential discovery
• environment-variable enumeration
• filesystem scanning
• secret access
• subprocess creation
• shell execution
• install hooks
• import time execution
• obfuscated payloads
• dynamic code loading
• remote payload retrieval
• unexpected network communication
• persistence

This complements vulnerability analysis rather than replacing it.

Evaluate publisher and project reputation

Relevant signals can include:

• publisher history
• ownership changes
• account age
• unexpected maintainers
• anomalous release cadence
• sudden repository changes
• unexpected package dependencies
• package maturity

These signals establish context. They should not independently grant trust.

Control package introduction

Public registries should be treated as distribution mechanisms, not internal trust stores.

A stronger model is: Public Registry → Package Discovery → Provenance + Integrity + Malware + Reputation Analysis → Policy Decision → Approved Internal Repository → Build → Deployment

This turns package trust into an explicit security decision before software enters production or AI development environments.

Restrict execution privileges

Preventative controls will eventually fail. When they do, blast radius matters. Developer, CI/CD and AI workloads should receive only the credentials and network access necessary for their function. Recent attacks repeatedly targeted credentials precisely because software build environments commonly contain powerful identities.

Lineaje UnifAI

Open Source Software Attestation: Lineaje checks for the integrity of every component in the software supply chain of your application. This includes direct and transitive dependencies. The integrity in represented in LCAL (Lineaje Component Attestation Level) in a scale of 0-4.

Gold Open Source

Open Source Software Classification: Lineaje’s classifiers thoroughly inspect open source packages, including Agentic AI skills, for malicious and suspicious behavior. UnifAI policies ensure that such malicious or suspicious components are flagged and/or blocked.

Rethinking Trust in Open Source

Open source packages remain indispensable. The security assumption surrounding them must change. Recent 2026 incidents demonstrate that attackers can compromise: packages, publisher identities, repositories, dependencies, CI/CD pipelines and release processes.

The package arriving from a legitimate registry may therefore have a legitimate name, a legitimate publisher, a legitimate repository, and in some circumstances even valid provenance, while still containing attacker controlled code.

For agentic AI, the lesson is particularly important. Mastra, Mistral AI and LiteLLM provide concrete 2026 examples showing that AI-specific frameworks, SDKs and infrastructure are already part of this attack surface.

Our internal analysis of the most downloaded npm and PyPI packages provides additional evidence for why open source packages should be evaluated before they are allowed to execute in trusted environments.

The security question can therefore no longer stop at if the package contains known vulnerabilities. Organizations also need to ask if they can establish sufficient evidence that the exact package version and artifact is trustworthy. For AI applications, answering that question before the package enters the environment should become a foundational shift- eft security control.