TL;DR: Between May 19, 2026 01:07:01 and 15:20:43 UTC, the default branch of the react18-use GitHub repository contained malicious commits that executed attacker-controlled code on developer machines during npm install. The commits were force-pushed away, but anyone who cloned or forked during that window may still have the payload. There is no fixed version. Assume full compromise of any machine that ran npm install against an affected checkout.

The Attack Chain

The attacker pushed a series of commits to the default branch of dai-shi/react18-use on GitHub. The first commit in the chain is 7b79148d1495a2505f9277da295a98cf176f4496. The last is the same hash. During that window, the branch contained a new file called src/install.js, wired into the package's postinstall script.

When a developer ran npm install against the affected checkout, Node executed src/install.js automatically. That script fetched a JavaScript payload from an attacker-controlled HTTPS endpoint. The endpoint URL was configurable via an environment variable, giving the attacker flexibility to rotate infrastructure. The script disabled TLS certificate verification before making the request, so it would accept any response from any server claiming to be the endpoint. It then passed the response body to eval with require available in scope, turning the downloaded string into arbitrary code running with the developer's permissions.

The payload deliberately skipped execution on CI systems and cloud and serverless environments. It checked for known CI environment variables and bailed out if it detected them. This targeting means the attacker wanted developer workstations specifically, not build pipelines. Developer machines tend to have SSH keys, cloud credentials, source code, and access tokens scattered across configuration files. A Node process running as the user can read all of them.

What react18-use Is

react18-use is a React hooks shim library that bridges React 19's use hook API to React 18 applications. Developers install it when they want to use the newer use() pattern for reading promises and context in components running on React 18. The package is maintained by dai-shi, a well-known maintainer in the React open-source ecosystem who publishes several reactive state management libraries.

The package was never published to the npm registry. The malicious code lived only in the GitHub repository's default branch. Developers who pointed their package.json dependency at the repo directly, or who cloned the repo and ran npm install during the attack window, are affected. This narrows the blast radius compared to a registry-published supply chain attack, but anyone who references the repo by SHA or branch in their lockfile is still vulnerable if the malicious commits persist in their clone.

Who Is Affected

You are affected if you ran npm install against the dai-shi/react18-use repository on a developer machine between May 19, 2026 01:07:01 UTC and May 19, 2026 15:20:43 UTC. You are also affected if you have a clone, fork, or direct-SHA URL reference that still contains commits in the range starting at 7b79148d1495a2505f9277da295a98cf176f4496. Running npm install against such a checkout today still triggers the payload.

There are no fixed versions. The affected package is react18-use in the dai-shi namespace. The fixedVersions field is empty because the repository was remediated by force-push, not by a patched release. If you pinned to a specific commit SHA during the attack window, that pin still resolves to malicious code.

What to Do

Treat any machine that ran npm install against an affected checkout as fully compromised. The second-stage payload was hosted on attacker infrastructure and cannot be reconstructed, so you cannot audit what it did. Take these steps:

• Rotate every credential the machine could reach: SSH keys, AWS keys, GCP service account keys, npm tokens, GitHub tokens, database passwords, API keys in .env files, and anything in ~/.config or ~/.aws or ~/.ssh.
• Audit account activity for every service the machine had access to, going back to May 19, 2026 01:07:01 UTC. Look for unauthorized access, new tokens, modified access controls, or data exfiltration.
• Delete local clones of the affected repository. Do not keep them. Force-pushing removed the commits from the remote default branch, but your local clone or fork still has them in reflog and object storage.
• Check your lockfiles for any git+ or https://github.com/dai-shi/react18-use URLs that resolve to commit SHAs in the attack window. Replace them or remove the dependency entirely.

Why It Matters

This CVE demonstrates a supply chain attack vector that infrastructure defenders often miss: repository-only compromise. The npm registry was never touched. No malicious package was published. The attack lived entirely in the git history of a GitHub repository, and the delivery mechanism was the postinstall script that runs every time someone runs npm install against a git URL.

The CI detection logic is notable. The attacker knew that CI environments are usually ephemeral and monitored. By skipping them, they avoided triggering alerts in build pipelines and avoided wasting payload executions on throwaway containers. Developer workstations are persistent, rich in credentials, and rarely audited at the process level. This is a deliberate targeting choice, not an accident.

Not in CISA KEV. Not known to be exploited in the wild. NVD enrichment is pending.

References

• hol.org CVE entry: https://hol.org/guard/security/cves/CVE-2026-48161-react18-use-was-vulnerable-to-malicious-code
• Malicious commit range: 7b79148d1495a2505f9277da295a98cf176f4496 (GitHub, dai-shi/react18-use)