Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free TrialThe volume of malware on public repositories hasn’t decreased. ReversingLabs (RL) has never seen more malicious packages published on public repositories, and the overall count of malicious software is steadily rising. Looking at the metrics, npm saw around 5308 unique malicious packages published in 2024 (excluding spam). By August of this year, the number of malicious npm packages reached 5723, exceeding the total for all of 2024 in just eight months. And the number of malicious packages continues to grow.
Figure 1: The RL malware count by year and January-August 2026.
Compromises of trusted, popular packages are also on the rise. Since the appearance of Shai-Hulud in September, 2025, multiple variants have appeared. More broadly, legitimate, high-profile packages seem to be compromised almost every month, while a series of supply chain compromises have been driven by social engineering attacks, open source maintainer account takeovers, and various other threats. Malware ranging from infostealers and RATs to self-propagating worms have infected widely used open source packages.
In an effort to curb the spread of registry malware and protect trusted packages, npm announced plans to implement pre-publish scanning, a security screening of packages prior to becoming publicly installable. That includes looking for evidence of suspicious or malicious behavior such as the unauthorized use of preinstall, install, or postinstall scripts that execute code; unexplained modifications in package tarballs; evidence of credential harvesting and more.
That’s an important new check on supply chain attacks. But, despite npm’s efforts to reign in malicious packages, they have continued to surface — including a campaign that delivered the same payload as the most recent wave of Shai-Hulud infections in May 2026.
The steady stream of npm threats also includes an interesting package ReversingLabs discovered in August that poses as an authorized security research tool for developers working with Twilio, a widely used platform for powering communications for Internet-based applications, while attempting to exfiltrate sensitive data. The package has since been removed from npm. Here's what we found and how developers can protect themselves.
Founded in 2008, Twilio provides programmable communication tools for making and receiving phone calls, text messages, and other communications via web service APIs. Twilio’s widely-used APIs allow software developers to embed features to enable phone calls, text messages, emails, and multi-factor authentication directly into their applications. Some of its core capabilities include sending automated text messages for two-factor authentication (2FA) codes, routing phone calls and powering identity verification services like SMS-based one-time passwords (OTPs).
Developers implementing Twilio in their own applications use ACCOUNT_SID and AUTH_TOKEN to contact Twilio’s API - allowing them to authorize billing and trigger communication. In official documentation, Twilio warns developers to keep these credentials secret, since anyone who has them can make an API request for their account.
A compromise of those credentials could allow attackers to send spam, steal OTPs or gain unauthorized access to APIs and run up massive API usage bills. Twilio has internal systems designed to proactively and automatically detect fraudulent uses of our communications platform. It also offers a complete anti-fraud guide to help developers avoid unwanted scenarios.
The malicious package we detected, tw-pkgprobe-7731, was not affiliated with Twilio in any way. It was published in the middle of August, with 11 different versions of a single package published back to back on August 14. Typically with open source software, newer versions of a package build upon a foundation set by earlier versions. But the tw-pkgprobe-7731 packages were a bit different — the first of many “red flags” we detected.
Specifically, the first version of tw-pkgprobe-7731 posed as an authorized security research probe.
Comments inside the package describe it as an “Authorized bug-bounty research probe (Twilio HackerOne program)” that “runs only inside Twilio’s serverless packager sandbox” and “”collects local process/host context and writes it next to itself; no destructive action.”
Once deployed, however, the package attempts to identify if the current environment is a Twilio developer environment, exiting immediately if it isn’t. Otherwise, it extracts environment variables along with system details like mounts, temporary folders and various configurations. These environment variables along with the current working directory and hostname, are then sent out via webhook.
Figure 2: The first version of the package.
The next few packages that were published, versions 1.0.1, 1.0.2 and 1.0.3, shifted focus. Moving away from general data extraction seen in the 1.0.0 version, they began mimicking a security probe targeted at developers using Twilio APIs. Starting with version 1.0.1, code inside deamon.js searched for specific folders tied to specific Twilio account String Identifiers (SIDs), unique 34-character strings that Twilio uses to identify resources like accounts, messages, and phone calls. The code notably avoids action if a folder with a specific SID name was present. Otherwise, if matching target folders were found, it scanned installed npm packages and node_modules to inject a custom npm PoC package, creating package.json and index.js inside.
By version 1.0.4, extra functionality was introduced to exfiltrate process.env.ACCOUNT_SID and process.env.AUTH_TOKEN over the webhook – directly compromising the user’s Twilio API credentials. The final three versions (1.0.8, 1.1.0 and 1.1.1) reverted to the basic probing profile of the package seen in version 1.0.0, stripping out the previous malicious activity.
Figure 3: Sending Twilio API sensitive information over webhook.
Following the clean version 1.0.8, the final, two versions published attempted to conduct OSINT gathering by probing various Twilio-related hosts (such as support-api.us1.twilio.com, kafka-ui.au1.twilio.com and litellm.ai-services.corp.twilio.com). One version even fetched AWS metadata located on [https://]169.254.169.254/latest/meta-data/ though it never actually used or exfiltrated it.
As noted earlier, comments placed within the tw-pkgprobe-7731 package claimed it was a security tool used in accordance with Twilio’s official bug bounty program, which is hosted by the firm HackerOne. That is a legitimate bug bounty program, complete with “Safe Harbor” legal protections for ethical researchers. So is this just a big misunderstanding? Almost certainly not.
The rules of engagement for Twilio’s bug bounty program are clear: sensitive information of any kind must never be exposed publicly, and customer or employee data shouldn’t be exfiltrated under any circumstances. Additionally, program guidelines clearly dictate how accounts and test assets must be managed. Twilio requires researchers to use an official @wearehackerone.com email address during testing and public PoC packages to follow a specific naming convention (such as twilio-hackerone-poc-).
Despite these clear guidelines, the packages we observed did not comply with Twilio’s guidelines in any way. The package name, tw-pkgprobe-7731, does not comply with Twilio’s naming conventions. Furthermore, the package author published them under an unrelated npm account (twdepprobe7731). In other words, these packages clearly violate the basic security research guidelines Twilio established, which suggests that the packages had malicious intent.
After notifying npm of our discovery, the tw-pkgprobe-7731 packages were removed an hour after they were published.
Unlike other campaigns RL has detected, the malicious packages the team discovered here lack a clear identity, and show no strong purpose or consistency between versions. And, while the threat actor behind the campaign attempted to mask malicious features in certain releases by surrounding them with seemingly benign features and code, they made no real effort to obscure the malicious code or hide their activity. There is no obfuscation, typosquatting, or attempt to make the publishing npm account look legitimate – tactics we’ve routinely seen in previous campaigns. This suggests that a less sophisticated threat actor is responsible for the malicious campaign targeting Twilio developers.
For a comparison, last year we wrote about discovering two npm packages published as part of a larger, highly sophisticated campaign. They contained malicious code downloading a malicious second stage using crypto smart contracts, but the main vector used to spread them was GitHub. The GitHub repositories in which they were included looked legitimate on the first glance – boasting numerous starts, followers and forks. All of that activity turned out to be completely fabricated to trick developers into using the repositories and ultimately incorporating the malicious code into their own environment.
Even in campaigns we have detected that weren’t as large or impactful, malicious actors still took steps to make their packages look legitimate. In March of this year, for example, packages downloaded second stage payload while displaying fake install logs trying to phish for the user’s sudo password. If the sudo password was successfully captured, then it was used to execute the downloaded second stage, delivering a remote-access trojan (RAT).
For developers, securing their environment and keeping their projects safe from tampering is essential. Maintaining a secure CI/CD pipeline and ensuring every package used is clean and free of malware are critical steps in that process.
RL’s free Spectra Assure Community site can help. It allows developers to search open-source packages used in their code to check for potential security issues, software vulnerabilities and hidden malware.
Figure 4: Spectra Assure Community page.
Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.
The following IOCs were collected as part of ReversingLabs investigation of this malicious software supply chain campaign. IOCa can be downloaded from secure.software after an account is made.
package_name | version | SHA1 |
|---|---|---|
1.0.0 | ea40177789e7a1b972c27c61dffff195dd85c544 | |
1.0.1 | 3fb29cf1ef3ce6b187e724c8e7dc4b6a5dfefa50 | |
1.0.2 | 7108c1079ac0de030902b049770e8cb822e82055 | |
1.0.3
985c294988e80f17414fb371b690080ee57387ea |
1.0.4 | 35b21553837b74e1fc5ac43efd839cdc28109fdf |
1.0.5 | 19c886b57a0c86e1efc82f4c4f2691f3ddc9f92c |
1.0.6 | fbc422912fa5af59ba278b30d8c1707e0fd1711b |
1.0.7 | fe4b42d7cf37ef2137fe5259626d51cb9922309e |
1.0.8 | d11da34ecdc3ff768fbe79a0aaf12f2340c2dd90 |
1.1.0 | 16574bd0538e6ae0ad4b7c73cd85c1232478f57d |
1.1.1 | c87db83ee84ae03b97b3cb11b07ad75a6c2a39ae |
Aurastealer, ACRStealer, and RemusStealer, a new potential LumaStealer variant, show MaaS in action. Here's what you need to know.
SVGs are difficult to detect, can be snuck into content — and can do malicious and legitimate actions. Here's how malicious SVGs work.