Python developer Roman Imankulov nearly took the bait. The fact that he didn't can be chalked up to human intuition and AI code vetting.

A person claiming to be a recruiter from a small crypto startup got in touch through LinkedIn, looking for help with what she described as proof-of-concept code that didn't work. The company, she explained, needed a lead engineer. 

As Imankulov described the exchange in a blog post, the recruiter asked him to look into an issue with a deprecated Node module. Something about the request seemed off.

"I'd heard, as probably all of us have, about those types of attacks," Imankulov explained in a phone interview. "And I was like, 'what if this could be I could be the target?' It was just based on the past experience that I had."

So he took the unusual step of spinning up a VPS on Hetzner where he cloned the repo. He then used his Pi coding agent (running Codex) to conduct a read-only analysis of the code. 

"I ran an agent to test how it worked, and I was almost certain that it would return to me 'everything is clear, the code is ugly but in general it's safe to run and just go ahead and perform your review,'" he explained. "To my surprise, almost immediately the agent returned a response like, 'Don't run this code, just walk away because there's a trap.'"

The AI model had flagged one of the files, app/test/index.js.

The file contained a backdoor. It took the form of a server URL, fragmented to look like a test suite configuration, and a network request that will run anything the server sends in response to the request.

Imankulov credited his AI agent with catching details that he had missed.

"I opened this code myself and I skimmed through this code and it looked to me like just, you know, a regular sloppy file written by a sloppy developer," he said. "So I just scroll down, [thinking] 'Yeah, yeah, it's awful, but you know if they can pay me to fix this code, I don't mind.' But the agent in the very same file found the exact vulnerability that I overlooked."

Just installing the repo using npm would have been sufficient to trigger the backdoor. The repo's package.json file contained a "prepare" post-installation hook designed to run the script following the installation process.

The referenced malicious repo is no longer accessible – presumably GitHub removed it in response to Imankulov's complaint – but a clone can still be found.

"What makes this attack insidious is how it hijacks standard developer workflows," explained Devashri Datta, independent open source and security architect, in an email to The Register. "The adversary didn't rely on the target executing a suspicious binary; they relied on the target running a routine command: npm install. 

"By burying the execution logic inside the prepare lifecycle hook within package.json, the malicious payload triggers automatically during dependency resolution. This isn't a novel technique, but it remains highly effective precisely because developers run npm install on autopilot. The string fragmentation used to assemble the malicious URL, piecing together a domain from small constants, was deliberate obfuscation designed to defeat static analysis tools that scan for hardcoded indicators of compromise."

Imankulov said that the commits in the malicious repo appeared to be the work of a developer with an established web presence and body of work. But when he contacted the supposed author, the dev said he had been impersonated on GitHub more than once and didn't write that code.

The recruiter's LinkedIn profile referenced a real arts journalist, though Imankulov believes the associated profile was faked. His online interactions with the recruiter suggested a level of technical knowledge not evident in her work history.

LinkedIn likes to talk about the tens of millions of fake accounts it catches and removes before they interact with anyone. But hundreds of thousands of accounts still get created and interact with people before being detected and flagged. And that number keeps growing. In the period from January through June 2025, LinkedIn restricted 386,000 accounts after user reports. That figure was 266,000 in the prior six month period. And it was a mere 86,000 in the January through June 2021 period.

These sorts of software supply chain social engineering attacks have become commonplace. Earlier this month, we noted how North Korean-linked scammers have been running various campaigns to compromise developer accounts using fake interviews and job offers.

Other developers have reported nearly falling for these scams (and also being saved by their AI agent) and have posted code analyses. 

Datta said Imankulov's response highlights a shift in how security-conscious developers are approaching code review hygiene.

"Historically, the guidance was to sandbox untrusted code or review it manually," she said. "Here, Roman deployed a local AI agent in a constrained, read-only environment to analyze the codebase before executing anything. This is a useful counterpoint to the dominant narrative around AI as an offensive threat vector. Used defensively at the developer endpoint, an AI agent isn't susceptible to fatigue or social pressure; it simply surfaces anomalous behavior, such as a test suite initiating an outbound network connection to retrieve unverified code, in seconds."

npm 12 could change the game

If it's any consolation, the relevant attack vector should be addressed next month.

GitHub, which maintains npm, is preparing to release npm 12 which changes the behavior of the npm install command. The allowScripts setting will be defaulted to off. "npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in your project," GitHub explains.

"Install-time lifecycle scripts are the single largest code-execution surface in the npm ecosystem," explained GitHub product manager Leo Balter in a community discussion post last week. "Every npm install runs scripts from every transitive dependency, so 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 one command away for the packages you trust."

Imankulov said he doesn't have a strong opinion about that. "From my perspective, just for the sake of personal safety, I switched to pnpm just to make sure that I don't execute those scripts by default," he said.

Datta said the incident underscores why enterprise software supply chain security had to extend beyond the perimeter of the corporate network.

"Attackers are now shifting left all the way to individual engineering endpoints before a single line of code enters the corporate supply chain," she said. "When a developer's local workstation is compromised during what appears to be a routine job interview, that machine frequently holds active SSH keys, cloud provider tokens, and live access to internal repositories."

Proper defense, Datta contends, requires enforcing technical guardrails such as isolated developer containers or secure cloud workstations for evaluating third-party or untrusted code.

"Emerging frameworks are beginning to extend exploitability context down to the workstation layer itself, recognizing that VEX-style signal needs to travel further left than the enterprise SBOM inventory if it is to intercept threats at the point of introduction," she said. ®