CVE-2026-48158 in use-context-selector
Summary
by MITRE • 08/10/2026
use-context-selector is a React useContextSelector hook in userland Between 2026-05-18 15:57:18 and 2026-05-19 15:24:34, the default branch contained malicious commits 9d8481a513b7b0d1c0941b220c69b25de748641b through 6f2dae054ca014068bdbbb4db96006424d674124 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-18 15:57:18 should treat the machine as compromised, rotate every credential the machine could reach, audit account activity** since 2026-05-18 15:57:18, and clean local clones.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The use-context-selector package experienced a sophisticated supply chain attack targeting developer workstations through malicious commits introduced between May 18-19, 2026. This vulnerability represents a classic case of code injection in the npm ecosystem where attackers leveraged legitimate package maintenance processes to deliver remote code execution payloads. The attack was specifically designed to exploit the postinstall lifecycle hook mechanism that is commonly used in node.js packages for setup and initialization tasks. The malicious commits were committed directly to the default branch and subsequently removed via force-push, but this cleanup method leaves behind persistent infection vectors through local clones, forks, and direct SHA references that may still contain the compromised code.
The technical implementation of this attack involved creating a new file named src/install.js that was automatically wired into the postinstall script execution flow. This approach aligns with CWE-494 vulnerability patterns where downloaded code is executed without proper validation or verification mechanisms. The malicious script demonstrated sophisticated evasion techniques by implementing conditional execution logic that specifically avoided running in CI environments, cloud, or serverless contexts while targeting developer workstations exclusively. This selective targeting strategy reduced detection probability and focused the attack on high-value targets where credential compromise would yield maximum impact.
The payload delivery mechanism exploited environment variable configuration to fetch JavaScript code from attacker-controlled HTTPS endpoints, demonstrating a technique consistent with ATT&CK framework's T1105 (Ingress Tool Transfer) and T1059.001 (Command and Scripting Interpreter). The implementation disabled TLS verification entirely, which represents a critical security flaw that bypasses standard transport layer security protections and makes the system vulnerable to man-in-the-middle attacks. The code execution was performed using require functionality with full Node.js process privileges, enabling attackers to access all resources reachable by the compromised user account. This approach directly maps to CWE-94 (Improper Control of Generation of Code) and represents a severe privilege escalation vector.
The attack's operational impact was designed to be maximally destructive while remaining stealthy during initial infection phases. The second-stage payload was hosted on attacker-controlled infrastructure, making it impossible to reconstruct or analyze the full scope of potential damage. Attackers specifically targeted developer machines with the assumption that these systems would contain valuable credentials, access tokens, and potentially sensitive project data. The compromise timeline from May 18, 2026, onwards indicates that any developer who executed npm install against affected checkouts during this period should be considered as having suffered complete system compromise. This vulnerability highlights fundamental security gaps in the npm ecosystem's trust model where legitimate package maintainers can unknowingly become vectors for malicious code delivery.
Organizations and individual developers must treat systems compromised through this attack vector with extreme caution, implementing comprehensive incident response procedures including credential rotation, account activity auditing, and complete system reinstallation. The persistent nature of the threat through local clones and direct SHA references means that simple package updates may not resolve the vulnerability. This attack demonstrates the critical need for enhanced supply chain security measures including package integrity verification, automated dependency scanning, and improved trust verification processes in package management systems. The incident serves as a stark reminder of how supply chain attacks can leverage legitimate development workflows to achieve persistent access and credential theft across development environments.