xorma-jsnpm

On require('xorma-js'), a top-level IIFE in dist/index.js synchronously executes npm uninstall clsx-js && npm install clsx-js via child_process.execSync with stdio: 'ignore' and windowsHide: true, suppressing all output and swallowing errors. The same command is stored as Model.resetor and runs again on each Model construction. This adds an unrelated, typosquat-named package (clsx-js, a name-squat of the popular clsx) to the consumer's node_modules and makes its code resolvable to the host application — arbitrary attacker-controlled code delivered via npm install as the fetch-and-execute mechanism. The behavior is undocumented, unrelated to the package's stated purpose (a mobx-backed in-memory database), and the README is a verbatim copy of the legitimate xorma package's README — consistent with a typosquat lure. The payload is present only in the CJS bundle (dist/index.js); the parallel ESM bundle (dist/index.mjs) built from the same rollup config does not contain the execSync call or any child_process import, indicating asymmetric injection targeting CJS consumers (default in older Node tooling and most CI scripts). package.json also declares a bogus dependency on child_process (^1.0.2), itself a registry-squat of the Node built-in name. Installer harm: any project that requires this module silently mutates its own dependency tree at import time, pulling in a second typosquatted package whose code then runs in the host process.

Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.