The Signal #121 — Dakota’s read on the AI news that actually matters to people running a business.

The AI tooling stack is growing fast. Most operators are focused on what these tools can do. Fewer are thinking about what happens when the tools themselves get compromised.

This week gave a sharp reminder of why that question matters.

What happened

Security firm Phorion published a detailed advisory disclosing that the official Claude Code for VS Code extension on the Cursor Marketplace was compromised. Versions 2.1.312 and 2.1.313 contained an injected backdoor designed to establish persistent SSH access on the machines where the extension was installed. Cursor has since removed both versions from its marketplace.

SSH (Secure Shell) is a standard protocol that allows remote login to a computer over a network. An SSH backdoor means an attacker could, if the conditions were right, log into a developer’s machine as that user without needing a password.

Here is how it worked. The compromised extension file had a block of malicious code injected at the top of the normal extension bundle. That code ran immediately when the extension loaded, before the user interacted with anything at all. The payload first added an attacker-controlled SSH key to the developer’s authorized keys file, a system file that controls which remote keys are trusted for login. It then tried to enable the SSH daemon (the background process that listens for incoming SSH connections) on macOS, Linux, and Windows.

On macOS, the malware ran into a bug of its own making. The script checked whether Remote Login was turned off before trying to enable it, but the command it used to check that state requires administrator access. Running it as a standard user produces an error message rather than the expected output. Because the script only tried to enable SSH if the output said “Off,” it skipped the enablement step entirely on machines where SSH was not already running. The Windows code path had a separate bug involving a hardcoded shell path that does not exist on standard Windows installs.

Phorion noted that even with the SSH enablement failing on macOS, the malware still installed persistence and sent host reconnaissance (basic system information about the machine) back to the attacker. The goal of the payload, per the advisory, was long-term interactive access.

Why it matters

If your organization has developers using the Cursor editor, this is an incident response question, not just an interesting news item. Phorion recommends immediately reviewing environments for use of versions 2.1.312 or 2.1.313 and engaging incident response where those versions are found.

Beyond the immediate cleanup question, there is a structural issue worth understanding. The Cursor Marketplace, like any extension marketplace, serves code that runs directly inside a developer’s editor. Because extensions run with the permissions of the IDE and the user running it, a backdoored extension gets immediate access to local files, source code, and developer tooling the moment it loads. There is no sandbox protecting your codebase from a compromised extension in the way a browser might isolate a webpage.

For a SaaS company, that means an infected developer machine could mean source code exposure. For a professional services firm, it could mean client files sitting in a project folder are suddenly reachable by an unauthorized party. For a real estate or healthcare operation with developers building internal tools, the blast radius depends on what that developer’s machine can touch on the network.

AI developer tools are being adopted fast, often faster than security review processes can keep up. That gap is exactly the kind of thing a supply chain attack (an attack that compromises a trusted tool or dependency rather than attacking the target directly) is designed to exploit.

What most people get wrong

The instinct after reading something like this is to treat it as a story about one bad extension that got caught. That framing undersells the lesson.

The more accurate frame is that any rapidly growing software ecosystem, AI tools included, creates a larger surface for this kind of attack. Extensions, plugins, integrations, and packages are all potential entry points. The faster your team adopts new tooling, the more important it becomes to have a baseline process for reviewing what gets installed, who approved it, and what permissions it runs with.

It is also worth noting that the bugs in this particular payload reduced its real-world impact. The macOS SSH enablement failed on machines without SSH already running. The Windows path had its own implementation flaw. Attackers make mistakes too. But your security posture probably should not depend on the attacker having written sloppy code.

The SSH keys and persistence logic still dropped on affected machines regardless of whether the inbound access path fully opened. Cleanup matters even when the most dangerous piece did not fully execute.

The plain lesson

AI tooling is software. Software has vulnerabilities, and popular software attracts attention from people looking for those vulnerabilities. Reviewing what your developers install, keeping an eye on marketplace advisories, and having a process for responding when something like this surfaces are not exotic security practices. They are basic operational hygiene that applies to AI tools the same way it applies to anything else running on your team’s machines.

If you want to think through how AI tools fit into your operations without adding unnecessary risk, start at xovionlabs.com.