The expanding threat landscape: Chainguard now scans source code for traditional malware and “greyware”

Chainguard is introducing a new source code scanner, built to block not only malware, but a class of nefarious open source packages that traditional malware scanners miss that we’ve dubbed “greyware.”

Chainguard is scanning 100,000+ packages a day and has already blocked 52,000+ packages detected as malware and greyware. Today, our scanner protects npm packages requested through the upstream fallback available for Chainguard Libraries for JavaScript. Soon, the surface area will expand to other language ecosystems and open source artifacts.

The problem: Coding at machine speed makes per-package security reviews impossible

When was the last time you read an entire README or reviewed the codebase of a new open source project you wanted to use in your application?

Historically, we’ve used signals of package legitimacy (GitHub stars, downloads, total published versions, AI autocomplete suggestions) as proxies for package safety. As AI-assisted supply chain attacks become as common as AI-generated slop appearing on your social feeds, smart automation is required to protect every dependency you’re pulling into your applications.

Malware has become a serious industry problem: 65% of organizations said they experienced a supply chain attack last year, let alone in 2026. However, there hasn’t been much emphasis on packages that do exactly what their README says, pass malware scans, but act in ways no CISO would ever approve. We call those packages greyware.

What is greyware?

includeGreyware packages have functionality that no reasonable developer or enterprise would expect, want, or permit in their applications if it were subject to formal review. These packages look identical to everything else you’re downloading from public registries, yet offer concerning security shortcomings. They honestly declare what they do, and what they do is harmful. The examples we’ve found are some combination of credential theft, command interception, API key harvesting, and persistent remote access.

We’ve seen this story before. Do you remember the Unroll.me app that was popular about a decade ago? Users signed up to unsubscribe from email lists in bulk. However, buried deep in the terms of service was the ability for the tool to read all of your emails and then sell your email data to third parties. Unroll.me technically didn’t do anything wrong. Its terms matched its business practices. The problem was that nobody actually read the terms to understand if they agreed with them.

Here are five examples of greyware we’ve already discovered on npm. You can check other publicly available firewalls, and you will see them unmarked as malicious:

• leobot-cli (versions 1.0.0–1.1.6) — This project advertises itself as a CLI bot for registering Canva and Leonardo accounts. It is an account fraud automation tool. The packages include a command leobot gen -c N, which generates fake accounts (max 20) and injects a Chrome extension for session injection and real-time token monitoring. It’s still available for download on npm and has 2,200+ downloads since its release last month. All versions have passed a typical 7-day cooldown period.

• @robinpath/cloud-cli (versions 0.1.1–0.3.1) — This project advertises itself as a CLI for RobinPath, which is an AI assistant that “reads your code, creates files, executes commands, and builds scripts.” It creates a permanent backdoor from your machine to a third-party server and waits for commands to run. It’s still available for download on npm and has 2,200+ downloads since its release last month. Versions 0.1.3–0.2.2 have passed a typical 7-day cooldown period.

• noesis-miner (versions 0.1.3–0.1.23) — This project advertises itself as an AI-agent-mined token protocol for Solana, and to its credit, says “do not deploy with material value on mainnet until the program and launch process have received independent security review” in its README. The packages spawn worker processes, read Solana keypairs from disk, and run persistent mining loops. All versions are still available for download on npm, and they have 2,200+ downloads since their release last month.

• drogonclaw (versions 0.3.5–1.0.2) — This project advertises itself as an autonomous AI pentest framework. It’s a fully-equipped hacking toolkit with OSINT, network scanning, exploit execution, and remote mobile control. It’s still available for download on npm and has 2,700 downloads since it was first released at the beginning of this month.

• chrome-tool (versions 1.0.3–1.1.2) — This project advertises itself as a CLI and Node.js library for Chrome. It’s a Chrome credential-harvesting extension. The packages openly export modules for extracting passwords, cookies, credit card information, and autofill data by decrypting ChroAES-128-CBC-encrypted SQLite databases via macOS Keychain Access. It’s still available for download on npm and has had 1,400+ downloads since its release last month. Versions 1.0.3–1.0.8 have passed a typical 7-day cooldown period.

How our scanner works

We built our scanner for the reality of the world we currently code in: where threats are sometimes blatant and sometimes disguised. Old, reactive models of defense, such as malware advisories, CVE databases, and vulnerability scanners, are still important but don’t prevent innocent-looking credential harvesters from ending up inside your builds.

Our scanner acts like a developer, thoroughly analyzing a package before allowing you to pull it into your application. It evaluates every package against four pillars before it can be served through Chainguard Repository:

• Maintainer behavior: Flags anomalies in publisher accounts, release history, and package metadata, checking to see if a maintainer account was recently transferred, if a version was quietly yanked and republished, or if a publish timestamp falls outside any normal window. It also monitors for changes in publishing policy, process, or toolchain, as these updates can be an indicator of ownership takeover. 

• Package contents: Downloads and scans the actual package that was published for obfuscated code, embedded C2 domains, modified binaries, and other indicators that something fishy was inserted into the package before it hit the registry. It also triggers on newly added dependencies and significant changes in code or binary size.

• Publishing signals: Compares the published package against its source code, providing additional protection for all packages served via Chainguard’s upstream fallback. It also monitors for items such as a release that is not tagged or is signed with an unknown key. Other publish signals include force-pushing a tag or a commit hash that isn't in the event log.

• Dynamic execution: Runs install scripts in a sandboxed, network-blocked environment to see if there are attempts to call out to an external server, read system files, or execute hidden payloads.

After analyzing a new package against these four pillars, our scanner decides whether the package is malicious, requires a review from a Chainguard security engineer, or is safe to serve to customers.

Not your typical malware scanner

Because our source code scanner is embedded into Chainguard Repository, it acts as another security control on top of building from source and cooldown. Every package is analyzed before it’s added to the Chainguard Libraries catalog, not when a package is requested. This prevents shortcomings that plague other firewalls, such as exposure windows, misconfigured machine installations, or instances where malware is cached in your artifact manager before it’s flagged.

Our scanner detects both malware and greyware, whereas alternatives only detect obvious malware. It also examines a range of questionable maintainer behaviors that traditional malware scanners may overlook.

What’s next

If you’re a Chainguard Libraries customer, there’s nothing for you to do. Our scanner is currently protecting all packages being served through our upstream fallback to npm. Coverage is expanding to all three supported ecosystems in the coming weeks, including packages built from source. Broader artifact support is coming later this year.

We are also building a policy layer so customers can override blocked packages based on their own organizational context, and you’ll be able to see all blocked malware on the Chainguard console for greater visibility.

You can learn more about how Chainguard Libraries protects your supply chain from AI-assisted attacks and get started pulling secure-by-default dependencies on our landing page.