Malicious React Native npm Releases Trigger Supply Chain Exposure

On March 16, 2026, Aikido and StepSecurity reported that two popular React Native npm packages used for phone number input and country selection were published to npm with malicious install-time code execution:

• react-native-international-phone-number@0.11.8
• react-native-country-select@0.3.91

Both releases included an obfuscated preinstall hook that automatically executed malicious code during npm install on developer machines, CI runners and build systems. This shifts the point of compromise earlier in the lifecycle, from runtime or application logic to dependency installation itself. In this case, exposure is not determined by whether the package exists in a repository, but whether the install path was actually executed.

At the time of disclosure, the two packages accounted for roughly 135,000 monthly downloads combined. The maintainer deprecated the compromised versions the same day they were reported. This activity appears to be part of a broader GlassWorm campaign affecting hundreds of repositories, packages and extensions across platforms such as GitHub, npm and VS Code/OpenVSX since October 2025.

What Happened

The malicious versions were published within minutes of each other on March 16, 2026. Researchers found that the releases appeared to bypass the normal GitHub release flow and were pushed directly to npm. In one case, the gitHead matched the prior clean release, which strongly suggests the malicious package was not built from a legitimate new source commit. 

Aikido noted that react-native-international-phone-number@0.11.8 still referenced the earlier clean react-native-country-select@0.3.9, which suggests both packages were independently compromised rather than one inheriting the other’s release.

Impact

This is an install-time supply-chain attack: the malicious preinstall hook ran automatically  during npm install, before any application code executed.The exposure window means any environment that resolved or installed these versions should be considered potentially affected. This includes, but is not limited to, developer workstations, ephemeral CI agents, container build stages and release pipelines.

Researchers who recovered the payload chain found credential and crypto-theft functionality, persistence mechanisms and follow-on payload delivery. The deeper recovered stage was Windows-focused, but the loader itself was OS-aware and delivered content based on the victim environment.

Technical Details

The malicious releases introduced a preinstall script that executed an obfuscated install.js file automatically during package installation. From there, the malware queried a Solana wallet through public RPC endpoints to recover a payload location, fetched an encrypted next-stage script from attacker-controlled infrastructure and executed the result in memory using eval() or vm.Script. The loader also created a ~/init.json marker to control re-execution.

Researchers also observed a Russian locale and timezone exclusion check, a pattern commonly seen in criminal malware designed to avoid infecting systems in Russia or Russian-speaking regions. In the recovered later stage, the malware used Windows persistence through scheduled tasks and Run registry keys and even used Google Calendar as an additional indirection layer before fetching more content from the attacker’s server.

Across the broader GlassWorm campaign, later-stage payloads included Windows persistence mechanisms, while separate activity targeting macOS users with trojanized crypto wallet clients.

Immediate Actions

1. Remove or block the affected versions immediately: react-native-international-phone-number@0.11.8 and react-native-country-select@0.3.91 The last known clean adjacent versions identified by researchers were 0.11.7 and 0.3.9 respectively. 
2. Audit lockfiles, CI logs, build artifacts and container layers for those versions. If either package was installed, treat the build environment as potentially exposed, because the malicious preinstall hook runs automatically during installation. 
3. Rotate npm, GitHub, cloud and other credentials that may have been accessible on affected systems. Maintainer guidance specifically recommended checking npm access logs, reviewing publish access and rotating access tokens.
4. Review dependency and build activity for unexpected lifecycle scripts, obfuscated install files or package releases that bypassed the project’s normal GitHub release flow.

Why This Matters

This isn’t an isolated npm incident. Researchers had linked this activity to the broader Glassworm campaign, which has impacted a little over 400 components this month across GitHub, npm and VS Code/OpenVSX.

What stands out in this case isn’t just the scale, but the execution point. By embedding malicious logic in the install process, the attack targets environments that are typically trusted and ephemeral, including CI jobs, build containers and developer machines.

The Visibility Gap

Traditional SCA tells you that a package exists in a dependency graph, but not where or when its install path is actually executed. It usually does not tell you where a malicious install path actually executed, which repository triggered it, which CI job ran it, which image inherited it or what secrets were exposed at the moment of execution. In attacks like this, package presence is only the start. Real risk depends on whether the malicious path was actually reached in your environment. 

Kodem’s own vulnerability research framing makes the same broader point: inventory alone is necessary but not sufficient; teams need visibility into operationally relevant exposure and an understanding of what assets the exploit will work on.

How Kodem Helps

Kodem moves beyond telling you whether one of the compromised dependencies exist. We confirm whether the vulnerability is running in production and can be compromised by an adversary. We do this by combining code-level analysis, runtime evidence and function-level execution visibility. In incidents like Glassworm, that matters because security teams need to understand not only which repository referenced the package, but where the package was actually pulled, built and executed across the SDLC. That is the difference between a theoretical package match and a real compromise path. 

References

1. Aikido Security. March 16, 2026. Glassworm Strikes Popular React Native Phone Number Packages. Aikido
2. BleepingComputer. March 17, 2026. GlassWorm malware hits 400+ code repos on GitHub, npm, VSCode, OpenVSX. BleepingComputer
3. GitHub issue: Security Alert: Malicious npm Release Detected in v0.3.91. GitHub
4. SecurityWeek and Tom’s Hardware follow-up reporting on broader Glassworm activity. SecurityWeek
5. StepSecurity. March 16, 2026. Malicious npm Releases Found in Popular React Native Packages. StepSecurity
6. StepSecurity. March 14, 2026. ForceMemo: Hundreds of GitHub Python Repos Compromised via Account Takeover and Force-Push. StepSecurity