A compromised Cursor marketplace extension tried to plant SSH backdoors: how to stop AI tooling from owning developer machines

I’m Denis Shokhirev, an Agentic AI Systems Architect based in Freiburg im Breisgau, Germany, and at DennisCraft AI Studio I ship production AI systems for DACH B2B clients on Claude, Supabase, n8n, Doppler, and self-hosted Postgres. When an AI coding extension attempts to write SSH persistence onto a developer laptop, this stops being an IDE convenience issue and becomes an infrastructure access problem within minutes.

The important lesson from a compromised Cursor marketplace extension is not just “another supply-chain incident happened.” The real issue is that AI tooling now runs inside the most trusted zone in a software company: the developer workstation with shell access, repo access, local tokens, SSH agent forwarding, and often cached credentials. If your team is already using editor agents, Claude Code, or tool-calling workflows, the question is not whether one tool will eventually behave in a way you did not expect. The question is which control layer catches it first.

Why AI extensions are a different class of workstation risk

A normal editor extension can already do damage, but AI extensions get a wider trust envelope. Developers expect them to read the codebase, modify files, call terminal commands, inspect project configuration, and suggest fixes across multiple directories. Behavior that would look suspicious from a browser add-on looks “helpful” when it comes from an AI coding assistant.

The attacker only needs persistence, not immediate exfiltration

In practice, an attacker does not need to dump all secrets on first run. Writing to ~/.ssh/config, changing a global Git hook path, or dropping a shell startup command into .zshrc is enough. That creates a quiet foothold that survives reboots and gives later opportunities for repo access, bastion access, or token theft. On enterprise teams I work with, the weakest boundary is often not production itself. It is the “temporary” privilege accumulated on developer laptops.

What your control chain should look like

OWASP’s guidance is useful here from two directions. The OWASP Top 10 for LLM Applications 2025 calls out excessive agency and tool misuse as recurring failure modes in AI systems: https://genai.owasp.org/. For workstation compromise, the software supply-chain angle matters too. The point is not to quote a list in a policy deck; it is to put controls exactly where the extension expects implicit trust.

1. Separate AI-assisted coding from long-lived access

If AI tooling runs in the same user context that stores your stable SSH identities and production cloud access, you have already made the attacker’s job easier. My preferred pattern is simple: run AI coding tools inside an isolated profile, container, or dedicated user where long-lived SSH keys are absent by default. If the tool is compromised, its blast radius should terminate inside a disposable boundary.

#!/usr/bin/env bash
set -euo pipefail

mkdir -p "$HOME/.config/git-hooks-empty"
chmod 700 "$HOME/.config/git-hooks-empty"

export GIT_CONFIG_GLOBAL="$HOME/.gitconfig-ai"
git config --global --file "$GIT_CONFIG_GLOBAL" core.hooksPath "$HOME/.config/git-hooks-empty"

if [ -f "$HOME/.ssh/config" ]; then
  grep -nE "ProxyCommand|IdentityFile" "$HOME/.ssh/config" || true
fi

echo "Start AI tooling only in this isolated shell context"

2. Treat editor tooling and scripts as reviewable code

Teams routinely run semgrep, bandit, and gitleaks on application repositories but ignore bootstrap scripts, editor config repositories, and local automation wrappers. That gap is exactly where this class of attack hides. If an extension relies on a post-install script or shell wrapper, review it the same way you review backend code.

name: tooling-review
on: [push, pull_request]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
      - run: pip install bandit
      - run: bandit -r scripts tooling
      - uses: gitleaks/gitleaks-action@v2

3. Remove permanent secrets from laptops

This is where many teams still lose. If a developer workstation contains production credentials, a malicious plugin does not need a sophisticated chain. It already won. Use short-lived credentials where possible, issue secrets by role, and keep production actions behind a separately logged control path. In my own stack, that usually means Doppler for controlled secret delivery, narrow database roles in Postgres or Supabase, and no assumption that a local machine is trustworthy because it belongs to an employee.

How to check whether persistence is already in place

If you suspect workstation tampering, do fast triage before debating policy. Look at SSH config, shell startup files, global Git settings, hooks, and user-level persistence mechanisms. You are not only hunting malware binaries. You are hunting legitimate operating system features used for illegitimate persistence.

from pathlib import Path

targets = [
    Path.home() / ".ssh" / "config",
    Path.home() / ".bashrc",
    Path.home() / ".zshrc",
    Path.home() / ".gitconfig",
]

markers = ["ProxyCommand", "core.hooksPath", "curl ", "wget ", "nc -e"]

for target in targets:
    if target.exists():
        data = target.read_text(errors="ignore")
        for marker in markers:
            if marker in data:
                print(f"Review {target}: found {marker}")

What to inspect manually

On macOS, check LaunchAgents. On Linux, inspect cron and user-level systemd units. In Git, inspect hooks and credential helper configuration. In SSH, inspect new keys, changed config directives, and unexpected host aliases. In shell profiles, look for aliases or functions shadowing tools like ssh, git, or curl. Malicious developer-tool persistence usually tries to look like ordinary automation.

What a production policy for AI tooling should actually say

Do not write a vague rule saying “use approved AI tools responsibly.” That is not enforceable. Write a short allowlist policy: which extensions are permitted, where they may be installed from, who owns version approval, how rollback works, and which filesystem locations or command classes are forbidden. I would explicitly prohibit any tool from writing to SSH configuration, global Git hook paths, or shell init files without manual approval.

This matters in regulated environments because it translates directly into auditable workstation controls. If you work under ISO 27001, NIS2-related security programs, or internal vendor-risk requirements, “developers can install arbitrary code execution agents because they seem useful” is not a defensible position. Keep it simple: one page of policy, one reviewed config repository, one recurring drift check.

FAQ

Is endpoint antivirus enough?

No. The problem here is not only malicious binaries. It is trusted tooling performing suspicious actions inside an expected workflow. You need permission boundaries and artifact review, not just signatures.

Should we ban all AI coding extensions?

No. Blanket bans usually create shadow usage. A tighter allowlist with isolated execution and update control works better in practice.

What should we change first if the team already uses Claude Code?

First, remove long-lived secrets and SSH identities from the environment where the tool runs. Second, start scanning local scripts, editor config repositories, and Git hook paths as part of engineering review.

Can MDM solve this by itself?

MDM helps establish a baseline and block some persistence paths, but it does not replace code review for local automation or secret management discipline. It is one layer in the chain.

Is this only a Cursor problem?

No. Any marketplace, extension host, or agent runtime with local file and shell access creates the same risk pattern. The product name changes; the workstation trust problem does not.

Which stage in your AI toolchain catches more real issues today: install-time controls, static analysis, runtime isolation, or human review after something strange already landed on a developer machine? I’d genuinely like to compare notes with teams shipping in regulated environments.

I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.