Which versions of react-check-error are malicious?

The following npm versions of react-check-error are flagged malicious: 2.1.6, 2.1.7. Treat any of these as compromised.

How do I remediate react-check-error if I installed it?

react-check-error establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.

I already installed react-check-error — how do I know if it already compromised me?

If react-check-error was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is react-check-error part of a known attack campaign?

Yes — react-check-error is associated with the IN-MAL-2026-007360, IN-MAL-2026-007359 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find react-check-error across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for react-check-error (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging react-check-error across your stack and pipelines.

Malicious package

react-check-errornpm

Malicious code in react-check-error (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-6341

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall react-check-error

What this malware does

On require(), index.js invokes _initMsgCache() at module top level. The function derives an AES-256-CBC key, IV, and ciphertext from a hardcoded 161-byte array (index.js:62) processed through an LCG-derived sbox, decrypts a URL, performs an https.get to that URL, parses the JSON response, and executes the response's cookie field via new Function('require', mod)(require) (index.js:155). This is a fully attacker-controlled remote code execution payload that runs on every consumer's machine the moment the package is imported, with full require access in the Node process. The package additionally impersonates the legitimate chai utility check-error — it copies chai's author metadata, description, the chaijs/check-error repository URL, and the original API surface (compatibleInstance, compatibleConstructor, compatibleMessage, getMessage, getConstructorName), with the dropper grafted onto the genuine sources. Unused runtime dependencies (axios, form-data, socket.io-client) are declared as further cover. The URL obfuscation (byte array + sbox XOR + per-index subtraction + bit rotation + AES-256-CBC) exists solely to hide the C2 endpoint from scanners — legitimate packages do not encrypt their network destinations.

Malicious versions

2 flagged

2.1.62.1.7

Indicators of compromise (SHA-256)

d89ef9716015743217a9492f4b4469459da701a1b6198851f1527033f1e5c9ae

e993c042cdc389f0889fe65e200ecfde7a0c9e18cb3ccfce76c3382c1379aead

Detection & response playbook

Backdoor / remote access

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for react-check-error (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging react-check-error across your stack and pipelines.
If you installed it — respond
react-check-error establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.
Did it already run?
If react-check-error was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks react-check-error before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. react-check-error on npm has been identified as a malicious package (versions 2.1.6, 2.1.7 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-007360IN-MAL-2026-007359

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks react-check-error-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the C2 callback and severs the channel.

Malware detection Runtime egress monitoring