autoheal-dev-clinpm
Malicious code in autoheal-dev-cli (npm) Remove it immediately and rotate any exposed credentials.
What this malware does
autoheal-dev-cli is a setup wizard (bin/setup.js) that, when run, performs three installer-harm actions against the developer running it: (1) syncConfigToServer() POSTs the user's GitHub Personal Access Token (with repo + user:email scopes), Vercel deploy hook URL, GitHub repo/branch, and n8n webhook to the hardcoded URL https://auomation.vercel.app/api/settings (note the misspelled auomation vs automation); the destination is not user-configurable. A holder of that endpoint can push code to every user's GitHub repos. (2) Despite the README presenting a choice to use the user's own n8n instance, the code unconditionally sets useSharedBridge = true and overwrites n8nWebhook to https://creativekulhad.onrender.com/webhook/autoheal-patch-handler, routing every patch dispatch from every user through the author's Render server. (3) The wizard rewrites the user's index.html to add <script src="https://auomation.vercel.app/autoheal.js"></script> with no SRI or version pinning, then git push --forces and triggers a Vercel deploy — so every visitor to the user's production site fetches and executes mutable JavaScript served from the author's domain in the user's origin. Additionally, the user's GitHub PAT is embedded directly into the git remote URL (https://<token>@github.com/...) and persisted in the local .git/config, and the wizard force-pushes without confirmation. The combination of silent relay of credentials to a typo-domain, forced routing of all generated patches through author infrastructure, and unpinned remote-script injection into the user's deployed site is a multi-channel installer-harm pattern that gives the publisher persistent control over both the developer's GitHub account and any site deployed through this wizard.
Malicious versions
Indicators of compromise (SHA-256)
Detection & response playbook
Credential / info stealerFind it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for autoheal-dev-cli (9 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging autoheal-dev-cli across your stack and pipelines.
If you installed it — respond
autoheal-dev-cli is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If autoheal-dev-cli 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 autoheal-dev-cli 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
Campaign
References
Credits
- Amazon Inspector · finder
Detect & block this
O3 blocks autoheal-dev-cli-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.