Researchers at ReversingLabs found an npm package pretending to be an authorized research tool for Twilio’s own bug bounty program on HackerOne. It had nothing to do with that program. The package, tw-pkgprobe-7731, harvested environment variables, hunted for Twilio account identifiers, and in one version pulled the exact tokens a Twilio integration authenticates with. It went up in mid-August 2026, and researcher Lucija Valentić is credited with catching it.
A fake credential to a real bug bounty program
The package was published by an account called twdepprobe7731, which no longer exists on npm. Eleven versions went out within roughly 45 minutes on the same day, a pace that looks like someone iterating on functionality live during the campaign rather than shipping one finished release. The package description referenced Twilio’s HackerOne program directly, which is itself a violation of how that program works: an authorized security research tool doesn’t get distributed through the public npm registry disguised as an ordinary dependency.
How the payload evolved across versions
Version 1.0.0 checked whether it had landed in something resembling a Twilio developer environment, then collected environment variables, mounted drives, temp folders, and configuration details, exfiltrating all of it through a webhook.
Versions 1.0.1 through 1.0.3 went further: hunting for folders tied to Twilio Account String Identifiers (SIDs), scanning installed npm packages and node_modules, and injecting its own proof-of-concept packages into the target project.
Version 1.0.4 got direct about it, pulling process.env.ACCOUNT_SID and process.env.AUTH_TOKEN, the exact pair of values a Twilio integration uses to authenticate against the API and that hand over real account access to whoever holds them.
Then versions 1.0.8, 1.1.0, and 1.1.1 stepped back to something simpler: OSINT-style probing of Twilio-related hosts, plus requests to the standard AWS metadata endpoint at 169.254.169.254/latest/meta-data/, the internal address that, on a permissively configured instance, can hand over temporary IAM credentials to anyone who asks.
Why researchers don’t rate this a sophisticated actor
The report is specific on this point: no obfuscation, no typosquatting, and no attempt to make the publishing account look legitimate. Real supply-chain campaigns usually disguise malicious code as routine updates and spend real time building account reputation before anything harmful gets planted. This was blunter than that, a package name that references Twilio outright, behavior that reads more like reconnaissance or a tool being tested live than a polished operation. What the actor’s actual end goal was, and whether there’s any real connection to Twilio’s bug bounty program, is still unclear.
Our take
Skip the obfuscation and skip the fake legitimacy, and you’d expect that package to get pulled fast. It didn’t, at least not before shipping eleven versions in under an hour, which says less about this specific actor and more about how thin registry moderation actually is on npm. A team willing to add obfuscation and a more convincing account history, running the exact same playbook, would likely last a lot longer than this one did.
The AWS metadata requests in the later versions are worth sitting with specifically. Developers testing Twilio integrations do that work on cloud instances constantly, and if that instance carries an overly broad IAM role, one plain HTTP request to the internal metadata address can hand over credentials with reach well beyond a single Twilio account.
Not the first fake-legitimacy npm campaign we’ve covered
We wrote about a similar pattern in the ChainDrop npm worm, which compromised 444 packages and stole CI credentials. Different payload, same underlying trick: abuse a developer’s trust in the npm ecosystem, or in this case trust in the idea of a legitimate security research tool, to get inside an environment without raising suspicion.
What to do about it
- If
tw-pkgprobe-7731was ever installed anywhere in your build pipeline, rotate every associated TwilioACCOUNT_SIDandAUTH_TOKENimmediately, regardless of which version landed, since behavior varied significantly release to release. - Check the IAM role attached to any cloud instance where developers test third-party API integrations. Access to
169.254.169.254shouldn’t hand over more privilege than that specific service genuinely needs. - Get secure code review on the project and its dependency tree if there’s any reason to suspect a package like this made it in, since the real question isn’t just whether it was installed, it’s what it managed to exfiltrate before anyone noticed.
- If credentials may already have leaked, run an assumed breach assessment rather than guessing at scope from the package version number alone.
- For teams running Twilio or similar integrations on AWS specifically, an AWS penetration test that checks IAM role scope and metadata exposure directly is a better use of budget than a generic dependency scan.