A malicious npm package posing as a Twilio bug-bounty tool stole developer credentials. Here’s exactly what it did and how to check your own dependencies.
Table of Contents
A package called “tw-pkgprobe-7731” sat on the npm registry describing itself, in its own source comments, as an “Authorized bug-bounty research probe (Twilio HackerOne program)” that “runs only inside Twilio’s serverless packager sandbox” and performs “no destructive action.” None of that was true. Security firm ReversingLabs disclosed this month that the package was malicious from its first version, and by its fourth release it was actively exfiltrating Twilio account credentials from any developer who installed it.
What the malicious npm package actually did
The account “twdepprobe7731” uploaded eleven versions of the package to npm in quick succession over roughly 45 minutes in mid-August 2026, then the account itself was deleted. The first version checked whether it was running inside an actual Twilio developer environment and exited immediately if not, a detail that matters because it means casual scanning or a sandboxed test wouldn’t necessarily trigger the malicious behavior. When the check passed, it collected environment variables, mount points, temporary folder locations, and other host configuration details, then sent that data out through a webhook.
Later versions narrowed their focus specifically to Twilio’s own account identifiers, searching installed node_modules for folders tied to particular Twilio account SIDs and, in version 1.0.4, adding code to exfiltrate process.env.ACCOUNT_SID and process.env.AUTH_TOKEN directly, the two values that together let an attacker authenticate as the victim’s Twilio account and use it to send messages or incur charges.
Oddly, the final three versions dropped the credential-stealing code entirely and reverted to the basic probing behavior of the original release, while adding reconnaissance against internal Twilio infrastructure hostnames and even a request to AWS’s internal metadata endpoint, the kind of request that can leak cloud credentials on a misconfigured EC2 instance. ReversingLabs researcher Lucija Valentić noted the package made no attempt to disguise its account name or obfuscate its code, unlike more sophisticated supply-chain campaigns, concluding a less experienced threat actor was likely behind it.
Why the “bug bounty” framing mattered
The specific trick here wasn’t technical sophistication; it was social engineering aimed at a developer’s own judgment. A comment claiming authorized status under a real company’s real bug-bounty program is designed to make a developer who notices the package at all conclude it’s legitimate research rather than something to remove. Twilio does run a HackerOne program, which made the claim superficially plausible, but ReversingLabs confirmed the package never actually followed Twilio’s published bug-hunting guidelines on that platform. A package’s own comments describing its authorization are not verification of anything; they’re just more text an attacker controls.
What this means if you build on Twilio or any similar API
The practical risk here isn’t limited to Twilio specifically. Any developer integrating a third-party API, payment processors, cloud providers, communication platforms, is a plausible target for a similarly named “probe,” “tester,” or “validator” package designed to look like tooling related to that integration. A few checks catch most of this class of attack before it reaches a production environment:
Check the publish history before installing anything unfamiliar. A legitimate diagnostic or testing tool has a development history: multiple releases over weeks or months, an active maintainer account, other packages from the same author. Eleven versions shipped in 45 minutes by an account that no longer exists is not what a real tool’s history looks like, and that pattern is visible on the npm package page before you ever run npm install.
Don’t trust in-code claims of authorization from anyone, including a package that says it’s sanctioned by the very company whose API you’re using. If a tool genuinely needs elevated access to test against a live account, that access should come through the platform’s own documented testing credentials and sandbox environment, not a third-party npm package asserting its own legitimacy in a code comment.
Treat .env files and environment variables as the actual target, because they were the actual target here. Never commit .env files to a repository, even a private one, and audit which processes on your server can actually read them. On a shared or improperly configured server, a compromised dependency reading process.env can capture far more than the one credential it was built for, since most Node.js applications store several API keys and database credentials in the same environment.
Run npm audit and keep it in your deployment pipeline, and consider a short delay before adopting brand-new packages or brand-new versions of packages you depend on. Most npm supply-chain attacks like this one are identified and pulled from the registry within hours to days; a package that’s been live and unflagged for a few weeks has already cleared a meaningful filter that installing it the day it’s published skips entirely.
What to do if you already installed it
If your project ever included tw-pkgprobe-7731 at any version, rotate your Twilio Account SID and Auth Token immediately regardless of which specific version you had installed, since the account itself is compromised the moment those values are considered exposed, not just when you can prove they were transmitted. Check your Twilio console’s usage and billing logs for any activity you didn’t initiate. If your application also runs on AWS infrastructure, review whether the package’s requests to the EC2 metadata endpoint could have reached real instance credentials in your environment, and rotate those too if there’s any ambiguity.
How to check whether this specific package ever touched your project
Before rotating credentials as a precaution, it is worth confirming directly whether tw-pkgprobe-7731 was ever actually installed. Search your project’s package-lock.json or yarn.lock for the exact string tw-pkgprobe-7731 or the publisher account name twdepprobe7731; either one appearing confirms it was pulled in at some point, even if it was later removed from package.json.
If you use a monorepo or manage several Node.js projects, run that same search across all of them rather than just the one you remember touching Twilio integration work in, since a dependency installed for testing in one place sometimes lingers in a lockfile long after the code that needed it was removed. If nothing turns up, you almost certainly were not affected by this specific campaign, though the broader hygiene steps above are worth adopting regardless.
Part of a larger pattern this year
This is not an isolated incident. 2026 has seen a steady run of npm supply-chain campaigns beyond this one, including a worm researchers dubbed Shai-Hulud that spread through compromised packages including Keyv and several related dependencies, and separate campaigns that hijacked AI coding assistant sessions to propagate malicious changes across roughly 100 repositories.
None of those are the same attack as the Twilio-probe package, and the specific mechanics differ each time, but the pattern across all of them is consistent: attackers increasingly target the trust developers place in the npm registry itself rather than trying to break into better-defended infrastructure directly.
A registry account with no track record, publishing many versions in a short window, remains one of the most reliable warning signs across nearly every one of these incidents, which is exactly why checking publish history before installing anything unfamiliar is worth building into a team’s actual workflow rather than treating it as a one-off response to this specific story.
The hosting side of this
None of the checks above are specific to any particular hosting environment, but where your application actually runs affects how much damage a compromised dependency can do once it’s inside. A Node.js application deployed with proper user isolation and without root-level access can limit what a malicious package’s file-system and network access actually reaches, compared to an app running with broader permissions than it needs.
If you’re deploying Node.js applications and haven’t reviewed what level of server access your deployment process actually uses, that’s worth auditing alongside your dependency list; a VPS hosting setup with properly scoped user permissions is one layer of defense that keeps working even on the day a malicious package like this one slips past your own review.
Further reading: npm docs: auditing package dependencies for security vulnerabilities.