Your AI Coding Tool Walks Straight Past Your Defences

The AI tools you trust to write your code? They walk past your defences. Not by accident. Not as a side effect. They simply pass through your security mechanisms as though they were not there.

Let’s talk about Cursor – the tool that is supposed to save time, write code faster, make you productive.

A prompt injection in a README

It turned out you could open a malicious repository, hide a prompt injection inside an ordinary README file, and Cursor would simply carry out the instructions. Without the developer clicking anything. Without approval. Without a warning. The tool reads the file, gets poisoned, and writes code directly onto your machine.

The weakness – called NomShub – exploited the fact that Cursor did not block shell builtins. The attacker wrote to your zshenv. In your home directory. Every new shell that opens runs the attacker’s code. From there: full access to the system, a tunnel through Microsoft’s Azure servers, and almost impossible to detect.

And that is not all. Across 2025 and 2026, more than 11 CVEs were reported in Cursor alone. File-protection bypass through case sensitivity. Silent code execution through MCP. Command injection through environment variables.

But the thing that genuinely frightens me

Around 40% of the dependencies the tool recommends contain known vulnerabilities. It does not check whether the library is safe. It recommends whatever was popular at the time of its training – not what is safe today.

I have been saying this for two years. There are no shortcuts in security. You cannot let an AI write your code and trust it blindly. It is not a question of whether you get hurt. It is a question of when.

At AppSec Labs we see this in penetration tests every week. Code generated by AI, with exposed access keys, with API endpoints carrying no authentication, with SQL injections of the kind you learn about on day one of the course. These tools are not protecting you. They are creating the attack surface.

The industry decided to trade security for speed. That is a game you always lose.

I first shared a version of this as a LinkedIn post on 2026-06-23. It is republished here, lightly edited, so it is easier to find and reference. — Erez Metula