The discovery of the malicious npm package tw-pkgprobe-7731 highlights a growing software supply-chain risk: attackers are not always trying to imitate a popular library or exploit a compromised maintainer account. Sometimes they simply try to make malicious code look like legitimate security research.

According to ReversingLabs, the package was published to npm on August 14, 2026, under the account twdepprobe7731. Eleven versions were released within roughly 45 minutes. The package claimed to be an authorized research probe associated with Twilio’s HackerOne bug-bounty program, but researchers found behavior inconsistent with legitimate security testing.

The package specifically targeted developers working with Twilio-related environments and, in certain versions, attempted to collect sensitive environment information and exfiltrate Twilio credentials.

The deception was based on legitimacy, not imitation

Many malicious npm campaigns rely on familiar techniques such as:

  • typosquatting popular package names;
  • impersonating well-known maintainers;
  • dependency confusion;
  • hijacking legitimate packages; or
  • publishing convincing clones of trusted software.

This campaign took a somewhat different approach.

The package explicitly described itself as a security-research tool. Comments inside the code claimed it was an authorized bug-bounty probe for the Twilio HackerOne program and that it operated only within Twilio’s serverless packaging environment.

That wording is important.

Developers, security researchers and platform engineers may be more willing to tolerate unusual probing behavior when software claims to be part of an authorized security test.

The attacker was effectively attempting to borrow the credibility of a bug-bounty program.

The package first checked whether the target was relevant

The malware did not blindly collect information from every environment in which it executed.

The earliest version checked whether it was running in what appeared to be a Twilio developer environment. If the expected conditions were not present, it exited.

This selectivity is significant because it reduces unnecessary noise.

Target-aware malware can avoid generating suspicious behavior on unrelated systems and may make analysis harder if researchers execute it in generic sandbox environments.

Once the environment check succeeded, the package gathered:

  • environment variables;
  • system and process context;
  • mount information;
  • temporary-directory details; and
  • configuration data.

The collected information was then transmitted to an external webhook.

Later versions became more focused on Twilio developers

Subsequent releases changed behavior and searched specifically for directories associated with Twilio Account SIDs.

According to the analysis, the package behaved differently depending on whether certain target directories existed.

If particular matching folders were found, the package inspected installed npm packages and node_modules and attempted to inject a custom proof-of-concept package by creating its own package.json and index.js.

This behavior goes well beyond what developers should expect from a normal package dependency.

A package modifying neighboring application dependencies or writing code into node_modules should be treated as highly suspicious unless that behavior is explicitly required and well documented.

Version 1.0.4 introduced direct Twilio credential theft

The most concerning behavior appeared in version 1.0.4.

That version attempted to retrieve:

process.env.ACCOUNT_SID

and

process.env.AUTH_TOKEN

These environment variables commonly hold Twilio account credentials used by applications to authenticate with Twilio services.

If successfully stolen, such credentials could potentially allow unauthorized access to Twilio API functionality within the permissions of the compromised account.

Depending on account configuration, an attacker might attempt to:

  • send SMS messages;
  • initiate communications;
  • access application-related data;
  • abuse account resources;
  • generate fraudulent usage; or
  • create unexpected billing activity.

The exact impact would depend on the permissions, account configuration and protections associated with the stolen credentials.

Environment variables remain a high-value target

This campaign also reinforces a broader security problem in modern development environments.

Secrets are frequently stored in environment variables because doing so is preferable to hard-coding them directly into source code.

That is generally good practice.

But environment variables are not magically protected simply because they are not committed to Git.

Any malicious package executing inside the same application context may be able to read them.

That means a compromised dependency running during:

  • installation;
  • build;
  • development;
  • CI/CD execution; or
  • serverless deployment

may gain access to credentials that developers assumed were safely separated from application code.

Secrets management therefore needs to consider runtime exposure, not merely source-code exposure.

Why npm packages are attractive attack vectors

Modern JavaScript projects routinely install hundreds or even thousands of transitive dependencies.

A developer may explicitly install ten packages while indirectly importing hundreds more.

This creates an enormous trust graph.

Every package may:

  • execute JavaScript;
  • include install scripts;
  • access environment variables;
  • read local files;
  • communicate over the network; and
  • interact with build or deployment infrastructure.

That makes package registries attractive to attackers because malicious code can enter a development environment through what appears to be a routine dependency installation.

The attack surface is amplified further in CI/CD systems, where build environments may contain:

  • API tokens;
  • cloud credentials;
  • signing keys;
  • registry credentials;
  • deployment secrets; and
  • production access tokens.

A malicious dependency that runs during a build can therefore potentially reach far beyond the developer workstation.

Rapid version changes are another warning signal

The attacker published eleven versions in approximately 45 minutes.

The versions also changed functionality significantly.

Some introduced credential harvesting or injection behavior, while later releases reportedly reverted to a simpler probing profile.

This unusual version progression is important.

Legitimate packages generally evolve incrementally.

Rapid releases that add and then remove sensitive functionality may indicate:

  • experimentation;
  • targeting adjustments;
  • attempts to bypass detection;
  • testing against specific environments; or
  • attempts to create plausible deniability.

Security tooling should therefore consider package-version behavior rather than evaluating only the latest release.

A package whose current version appears harmless may still have distributed malicious code in an earlier version.

The package also probed internal and cloud infrastructure

The later versions reportedly performed OSINT-style probing of Twilio-related infrastructure, including hosts associated with Twilio support, Kafka services and AI-related infrastructure.

The package also attempted to access the well-known cloud metadata endpoint:

169.254.169.254/latest/meta-data/

This address is commonly associated with instance metadata services in cloud environments.

Attempts to reach cloud metadata should attract immediate attention when performed by a package that has no legitimate reason to query infrastructure credentials or instance configuration.

Historically, metadata services have been attractive targets because they may expose temporary cloud credentials or information about the underlying compute environment.

Organizations should therefore monitor software build environments for unexpected requests to link-local metadata addresses.

Was this really bug-bounty research?

ReversingLabs concluded that the behavior did not conform to Twilio’s published HackerOne bug-bounty guidelines.

The package was not affiliated with Twilio, despite claiming otherwise.

That distinction is important because legitimate vulnerability research operates within defined boundaries.

A researcher cannot simply label activity “bug bounty” and assume that credential harvesting, environment exfiltration or unauthorized probing becomes acceptable.

For defenders, this suggests a useful rule:

Claims of security research should be independently verified before unfamiliar tooling is executed in sensitive development environments.

Developer comments inside a package are not proof of authorization.

Lack of obfuscation does not make the package harmless

Researchers noted that the package made relatively little attempt to hide its behavior.

There was no sophisticated obfuscation, convincing typosquatting or effort to disguise the npm publisher account.

That may suggest a relatively unsophisticated actor.

But sophistication and impact are not the same thing.

A simple package that reads a secret and sends it to a webhook can still compromise an organization.

Attackers frequently succeed not because their malware is technically brilliant, but because they find a trusted execution path into an environment that already contains valuable credentials.

The dangerous part here was access, not elegance.

What should organizations do if the package was installed?

Organizations should search development systems, CI/CD environments and build logs for:

tw-pkgprobe-7731

Any system that executed the package should be treated as potentially exposed until the installed version and runtime environment are established.

Security teams should:

Remove the package

Ensure the malicious package and any artifacts it created are removed from development and build environments.

Identify the installed version

Behavior varied substantially between versions, so determining exactly which version executed is important.

Rotate Twilio credentials

If ACCOUNT_SID and AUTH_TOKEN were available to the package, affected secrets should be considered potentially compromised and rotated.

Review Twilio activity

Examine account activity for unexpected API calls, messaging activity, configuration changes or unusual billing events.

Review build and CI/CD secrets

If the package ran in automated pipelines, identify every secret available within that execution environment.

The exposure may extend beyond Twilio credentials.

Inspect outbound network activity

Look for webhook connections and other unexpected external communication associated with the package execution.

Review filesystem changes

Search for unexpected package.json, index.js or other modifications inside application directories and node_modules.

Organizations should tighten dependency governance

This incident demonstrates why developers should not automatically trust a package simply because it exists on npm.

Organizations should implement controls such as:

  • approved package repositories;
  • dependency allowlists;
  • package reputation checks;
  • lockfiles;
  • software composition analysis;
  • malware scanning for package contents;
  • restrictions on lifecycle scripts;
  • version pinning;
  • provenance verification; and
  • automated review of newly introduced dependencies.

New or extremely low-reputation packages deserve additional scrutiny, particularly when they claim to perform security testing or require access to credentials.

CI/CD pipelines deserve special protection

Build infrastructure should be treated as a privileged security environment.

CI/CD pipelines often combine source code, production secrets and deployment privileges in a single place.

Where possible:

  • expose only the secrets required for a particular job;
  • use short-lived credentials;
  • avoid making production credentials available to untrusted build stages;
  • isolate builds;
  • restrict outbound network access;
  • monitor metadata-service access; and
  • prevent arbitrary dependency scripts from accessing unrestricted secrets.

A malicious dependency should not automatically inherit access to every credential required by the entire deployment pipeline.

Public package repositories remain a growing supply-chain risk

ReversingLabs reports that by August 2026 it had already identified 5,723 unique malicious npm packages, exceeding the roughly 5,308 it observed during all of 2024.

That trend demonstrates the scale of the problem.

Public software repositories provide enormous value to developers, but they also give attackers an inexpensive distribution mechanism.

Publishing a malicious package requires considerably less effort than compromising a mature software vendor.

The attacker only needs one developer, one automated build or one poorly reviewed dependency to execute it.

The broader cybersecurity lesson

The tw-pkgprobe-7731 campaign demonstrates that software supply-chain attacks do not always require compromising a famous package.

An attacker can instead create a small, apparently specialized package and target developers who have access to particularly valuable environments.

In this case, the package attempted to exploit trust in three things simultaneously:

npm as a software distribution platform + Twilio as a trusted service + bug-bounty research as a plausible explanation for unusual behavior.

The actual code was relatively straightforward.

The social context surrounding the package was the more interesting weapon.

The incident therefore reinforces a fundamental principle for developer security:

Dependencies should be trusted based on provenance and verified behavior, not on package descriptions, comments or claims of affiliation.

A package that says it is conducting authorized security research deserves exactly the same scrutiny as any other untrusted code.

Possibly more.

Because whenever software asks you to believe that credential collection is “for research,” skepticism is not cynicism. It is simply functioning threat modeling.

Cybersecurity researchers have disclosed details of a malicious npm package named "tw-pkgprobe-7731" that masquerades as a security tool targeting developers integrating Twilio into their applications, while stealthily attempting to harvest sensitive data. The package, named "tw-pkgprobe-7731," was first uploaded to the npm registry in mid-August 2026 by an npm account named "twdepprobe7731."

Source: Malicious npm Package Poses as Twilio Bug-Bounty Probe, Can Exfiltrate Credentials via The Hacker News — published 22 Sep 2026.