My Ubuntu-based development laptop appears to have been infected by malware after working with a cloned Node.js project. The machine uses nvm, pnpm, VS Code, an AI coding agent, and asdf. I found and killed an obfuscated `node -e` process that fetched and evaluated remote JavaScript, sent system information to an external server, and had an established outbound connection. I also found evidence of earlier malware involving editor task triggers, altered project assets, persistence mechanisms, and credential theft.
I checked cron, systemd user services, shell startup files, editor configuration, project scripts, package scripts, hidden project files, and network connections. The process has not returned, but the machine contained an `.env` file with database passwords, API keys, authentication secrets, OAuth credentials, and other service tokens. The project also contains a merge hook, and its history includes commits removing malicious code. Some shell dotfiles are missing.
My main concerns are whether the system can be trusted, whether the Node.js installation or dependencies were modified, whether there is deeper persistence such as kernel modules or preload libraries, and whether the project or AI coding tools could reinfect a clean system. Should I rotate every credential, wipe and reinstall the laptop, replace the project from a known-good source, and use additional monitoring or isolation afterward?
4 Answers
Treat the laptop as fully compromised. A malicious process could have read the `.env` file, captured credentials or browser sessions, and accessed anything available to your user account. Rotate every password, API key, token, database credential, signing secret, and active session from a different trusted device. Revoke old sessions and review provider logs for suspicious access. Do not wait until you prove that a secret was exfiltrated; that proof may not be obtainable.
Hashing the current Node binary is useful for documentation, but it does not prove the host is clean. Compare a freshly downloaded official release against its published checksums and install it after the rebuild. On the existing system, you can inspect startup files, cron, systemd, autostart entries, `/etc/profile.d`, shell completion, PATH and library settings, preload configuration, PAM files, kernel modules, and eBPF activity, but a negative result is not definitive after compromise. Do not rely on malware scanners or manual inspection as a substitute for rebuilding.
Assume the repository and its dependencies are hostile until independently verified. Review recent commits, tags, hooks, workspace scripts, install and prepare scripts, lockfiles, editor task and launch configurations, generated files, and package provenance. Inspect suspicious packages from an isolated environment and avoid running lifecycle scripts while investigating. Temporarily disable automatic tasks and AI-agent actions, and use a disposable VM or container with no production credentials for untrusted projects.
For a machine you need to trust again, preserve only necessary personal data and forensic evidence, then wipe the disk and reinstall the operating system from verified installation media. Reinstall Node, pnpm, editors, and other tools from official sources, and restore only reviewed source files—not executables, dependencies, shell configuration, or build artifacts. Re-clone from a verified clean commit or repository, and audit the repository history, hooks, editor tasks, dependency lockfiles, and CI credentials before running anything.
I have repeatedly seen the suspicious code return after cloning the project, even after cleaning local files. Several collaborators and contractors have reported similar infections, so I suspect the repository, dependency chain, credentials, or development tooling may still be contaminated rather than this being only a local persistence issue.