CVE-2026-48161 in react18-use
Summary
by MITRE • 08/11/2026
react18-use is a React 19 use hook shim. Between 2026-05-19 01:07:01 and 2026-05-19 15:20:43, the default branch contained malicious commits 7b79148d1495a2505f9277da295a98cf176f4496 through 7b79148d1495a2505f9277da295a98cf176f4496 that executed remote attacker-controlled code on developer machines during `npm install`. The commits were removed by force-push, but local clones, forks, and direct-SHA URLs may still contain them, and `npm install` against an affected checkout will still execute the code today. The package was not published to npm. `src/install.js` was added and wired into the `postinstall` script. It fetched a JavaScript payload from an attacker-controlled HTTPS endpoint (configurable via an environment variable), disabled TLS verification, and evaluated the response as code with `require` available. Execution was deliberately skipped on CI and cloud/serverless environments, targeting developer workstations. The second-stage payload was attacker-hosted and cannot be reconstructed. Assume full compromise of anything reachable from a Node process with the user's permissions. Those who ran `npm install` against an affected checkout on a developer machine on or after 2026-05-19 01:07:01 should treat the machine as compromised, rotate every credential the machine could reach, audit account activity since 2026-05-19 01:07:01, and clean local clones.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/11/2026
This vulnerability represents a sophisticated supply chain attack targeting the React 19 use hook shim package through a malicious npm package that was never actually published to the npm registry. The attack exploited the postinstall lifecycle script mechanism in node.js package management by inserting a malicious script called src/install.js into the default branch of the repository between specific timestamps. This malicious code executed during npm install operations on developer machines and represented a targeted approach to compromise individual workstations rather than enterprise infrastructure, following common attack patterns where developers are often less protected than production environments.
The technical implementation of this vulnerability leveraged several dangerous practices that align with CWE-494 and CWE-94 categories. The malicious code specifically fetched JavaScript payloads from attacker-controlled HTTPS endpoints using environment variable configuration, which allowed for dynamic payload delivery and evasion of static analysis. The payload execution mechanism disabled TLS certificate verification entirely, creating a man-in-the-middle attack vector that would allow attackers to intercept or modify traffic without detection. The use of require within the evaluation context provided full access to Node.js module system capabilities, enabling attackers to execute arbitrary code with the permissions of the user running npm install.
The operational impact of this vulnerability was severe and specifically designed to target developer environments where credential exposure and privilege escalation opportunities are more common than in production systems. The attack deliberately bypassed CI/CD environments and serverless deployments, focusing exclusively on workstation compromise where attackers could potentially gain access to development credentials, source code repositories, and other sensitive information accessible from the compromised machine. This approach aligns with ATT&CK technique T1583.001 for supply chain compromises and T1078 for valid accounts exploitation, where attackers leverage developer permissions and access patterns to maximize their impact.
The attack's sophistication is evident in its use of force-pushed commits that were removed from the default branch but could still be accessed through local clones, forks, or direct SHA references. This persistence mechanism ensured that even after the initial removal, affected systems could continue to execute malicious code if developers had already cloned repositories containing the compromised commits. The second-stage payload delivery approach using attacker-hosted resources made it impossible to reconstruct the full attack vector and demonstrated a complete compromise of any system where npm install was executed against an affected checkout. Organizations must treat any machine that executed npm install during the affected time window as fully compromised, requiring immediate credential rotation, account activity auditing, and comprehensive system cleanup.
Mitigation strategies for this vulnerability require immediate action including verification of all local clones against known good commit hashes, removal of any affected packages from development environments, and comprehensive security auditing of developer workstations. The attack pattern demonstrates the importance of supply chain security practices and highlights vulnerabilities in how npm package integrity is verified during installation processes. System administrators should implement monitoring for unusual postinstall script activity and consider implementing network-level controls to block connections to known malicious domains. Additionally, organizations should review their development environment security configurations and potentially implement stricter npm install policies that prevent execution of arbitrary code during package installation phases.