AI Coding Tools: How to Spot and Avoid Malicious Code in Your Projects

AI-powered coding assistants like Cursor, Claude Code, and GitHub Copilot have become staples in many developers’ toolkits. They accelerate writing boilerplate, suggest fixes, and even generate entire functions from natural language prompts. The productivity gains are real, but recent security incidents show that these tools can also introduce dangerous vulnerabilities—sometimes without the developer noticing until it’s too late.

What Happened

In mid-2026, multiple reports from Dark Reading detailed specific attacks exploiting how AI coding tools handle code from external sources.

  • Cursor IDE auto‑executes malicious code from poisoned repositories. Attackers contaminated repositories with code that, when suggested by Cursor’s AI, was automatically run in the developer’s environment. The IDE’s “auto‑execute” feature made it easy to trigger malware without the user approving each command.

  • The “TrustFall” convention exposed a risk in Claude Code. This attack leveraged a pattern where developers implicitly trust AI‑suggested shell commands. By crafting prompts that led the assistant to output a dangerous command, attackers could trick users into executing it—especially when the command looked benign on first glance.

  • “Cordyceps” malicious pull requests. Attackers submitted pull requests to open‑source projects that contained subtly malicious code disguised as legitimate contributions. When AI assistants were used to review or merge these PRs, the bad code was often overlooked because the AI itself had been trained to recognize similar “improvements.”

These are not hypothetical vulnerabilities. Each incident has been observed in the wild, and the underlying techniques are straightforward to replicate.

Why It Matters

AI coding tools operate on a trust model: the assistant suggests code, and the developer typically accepts it after a quick scan. But that scan is often superficial. Attackers now design malicious payloads to appear as plausible, performance‑friendly changes—unusual imports, obfuscated strings, or network calls that blend into larger functions.

The productivity promise is real, but so is the risk. A single poisoned suggestion can compromise an entire project’s supply chain. Once the malicious code is committed, it can spread via CI/CD pipelines, affect end users, and become extremely difficult to trace back to the AI‑generated origin.

For solo developers and small teams, the danger is even greater because they lack the safety net of dedicated security reviewers.

What Readers Can Do

You don’t need to abandon AI tools, but you do need to adjust how you use them. Here are concrete, actionable steps:

  1. Disable auto‑execution where possible. Many IDEs and AI plugins have settings that automatically run or execute suggested code. Turn them off. Review every command—especially shell commands, imports, and network calls—before running them.

  2. Treat AI‑suggested code as a draft, not a final answer. Always review it with the same scrutiny you’d apply to code from an untrusted contributor. Check for unusual imports (pip install or npm install from unknown registries), base64‑encoded strings, and hidden subprocess calls.

  3. Use sandboxed environments for testing. Run AI‑generated code in a container, a virtual machine, or a disposable development environment first. This isolates any potential damage and makes it easier to revert changes.

  4. Apply static analysis before commit. Tools like ESLint, bandit, or CodeQL can flag suspicious patterns before code enters your repository. Integrate them into your pre‑commit hooks or CI pipeline.

  5. Prefer curated, well‑known sources. When the AI suggests a package or library, verify that it’s from a reputable source. Attackers often name malicious packages similarly to popular ones (typosquatting). Use package managers with built‑in security scanning.

  6. Stay informed about attack patterns. The incidents described above are not one‑offs. Follow security news sources like Dark Reading and subscribe to vulnerability databases relevant to your stack.

Sources

The incidents and techniques discussed in this article are drawn from reporting by Dark Reading:

  • “Cursor IDE Auto-Executes Malicious Code in Poisoned Repos” (July 14, 2026)
  • “‘TrustFall’ Convention Exposes Claude Code Execution Risk” (May 7, 2026)
  • “‘Cordyceps’: Mushrooming Malicious Pull Requests Threaten Developer Workflows” (June 23, 2026)

These reports provide technical details and mitigations that go beyond the scope of this article. Reading them in full is recommended for anyone regularly using AI coding assistants.

AI coding tools are here to stay, and their productivity benefits are substantial. But those benefits come with a requirement: treat the AI as a powerful junior developer who needs constant supervision. Adopt a security‑first mindset now, rather than after an incident forces your hand.