Roman Imankulov stopped an npm backdoor with an AI read-only scan

Roman Imankulov nearly took the bait. A recruiter impersonating a recruiter from a small crypto startup reached out via LinkedIn and asked him to look into proof-of-concept code that “didn’t work,” with a request to investigate an issue tied to a deprecated Node module. Something about the exchange felt off to him, and he acted on that instinct by spinning up a VPS on Hetzner, cloning the repository, and running a read-only analysis with his Pi coding agent running Codex.

Here is where the story turns from “developer diligence” into “systemic supply chain alarm.” Almost immediately, the AI agent returned a response telling him not to run the code and that there was a trap. It flagged a specific file, app/test/index.js, and that is exactly where the backdoor lived. Imankulov later described how he initially skimmed the file and thought it looked like a “regular sloppy file written by a sloppy developer,” the kind of mess you fix for money. The AI found the exact vulnerability he missed.

The trap matters because of how boring it would have been to trigger. The repo’s package.json included a prepare post-installation hook designed to run a script following the installation process. In other words: simply installing the dependency with npm would have been sufficient to activate the backdoor. Imankulov’s report also describes the backdoor’s form as a server URL assembled in fragmented pieces to look like test suite configuration, plus a network request that would run anything the server sent back in response.

This is the crux for executives and security owners: the attack did not require a bizarre “download and execute” step. It hijacked standard developer workflows. As Devashri Datta, independent open source and security architect, put it in an email to The Register, the adversary relied on the routine command: npm install. By burying execution logic inside the package.json prepare lifecycle hook within npm’s install lifecycle, the malicious payload triggers automatically during dependency resolution. Datta also flagged the obfuscation angle: the string fragmentation that assembles the malicious URL from small constants to defeat static analysis tools that scan for hardcoded indicators.

Layer in the social engineering, and the risk stops being theoretical. Imankulov said the malicious repo commits appeared to be from a developer with an established web presence and body of work. But when he contacted the supposed author, the dev told him they had been impersonated on GitHub more than once and did not write that code. The recruiter’s LinkedIn profile referenced a real arts journalist, which Imankulov believes was faked. LinkedIn says it catches and removes tens of millions of fake accounts before they interact with anyone, but that still leaves “hundreds of thousands” that get created and interact before detection. The Register cites LinkedIn restrictions after user reports: 86,000 accounts restricted in January through June 2021, rising to 266,000 in the prior six-month period, and then to 386,000 in January through June 2025. The implication is uncomfortable and operational: attackers do not need to break your defenses globally, they only need one engineer to run one command.

If that sounds like a “shift left” headline, it is, but this time the evidence is in the workflow. Datta said Imankulov’s response highlights a change in how security-conscious developers are approaching code review hygiene. Historically, guidance centered on sandboxing untrusted code or reviewing manually. Here, Roman deployed a local AI agent in a constrained, read-only environment to analyze the codebase before executing anything. Datta framed it as a useful counterpoint to the narrative of AI as an offensive threat vector: used defensively at the developer endpoint, an AI agent is not susceptible to fatigue or social pressure. It can surface anomalous behavior fast, like a test suite initiating an outbound network connection to retrieve unverified code.

Then the ecosystem side of the story adds a second line of defense. GitHub, which maintains npm, is preparing to release npm 12. The allowScripts setting will be defaulted to off, meaning npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless explicitly allowed in the project. GitHub product manager Leo Balter explained that “Install-time lifecycle scripts are the single largest code-execution surface in the npm ecosystem,” because every npm install runs scripts from every transitive dependency. A single compromised package anywhere in your tree can execute arbitrary code on a developer machine or CI runner. Making script execution opt-in closes that path while keeping it a one-command away convenience for trusted packages.

For organizations trying to keep up, the operational stake is clear: Datta argued that enterprise software supply chain security had to extend beyond the corporate perimeter. Attackers are shifting left to individual engineering endpoints before any line of code enters the corporate supply chain. If a developer’s local workstation is compromised during what looks like a routine job interview, that machine often holds active SSH keys, cloud provider tokens, and live access to internal repositories. Datta said proper defense includes technical guardrails such as isolated developer containers or secure cloud workstations for evaluating third-party or untrusted code. She also referenced emerging frameworks extending exploitability context down to the workstation layer, pushing the “signal” leftward beyond SBOM inventory so it intercepts threats at the point of introduction.

The payoff for boards and leaders is not “AI saved a developer.” The payoff is the model of how to reduce blast radius when the next LinkedIn lure arrives. Imankulov’s near-miss shows how quickly a routine npm install can become a code execution path, and how small deviations in workflow, like using a constrained read-only scan before running anything, can interrupt the attacker’s chain. With npm 12 changing defaults next month and platforms steadily tightening controls, the next era of supply chain security will be won or lost in developer environments, not just in the centralized gates you already have.