Kritische Schwachstelle führt Code beim Öffnen von Ordnern aus
Das Cybersicheitsteam von Baobab Risk Solutions hat folgende kritische Sicherheitslücke aufgedeckt. Nutzt ein Unternehmensentwickler die Cursoder IDE, droht aktuell folgende Gefahr: Schon das bloße Öffnen eines Projektordners kann Code auf dem Laptop ausführen — ohne Nachfrage, ohne Warnung und mit vollem Zugriff auf alle Rechte dieses Nutzers.
Das unterschätzte Risiko auf Entwickler-Geräten
Die meisten mittelständischen Unternehmen haben kein eigenes Security-Operations-Team, das Entwickler-Laptops rund um die Uhr überwacht. Doch genau auf diesen Laptops liegen oft unternehmenskritische Daten und Zugänge: SSH-Keys, AWS- oder Azure-Zugangsdaten, VPN-Zugänge, Kundendaten und der Quellcode des eigenen Produkts.
KI-gestützte Entwicklungsumgebungen (IDEs) wie Cursor verbreiten sich schnell in Entwicklerteams, weil sie die Produktivität steigern. Das Problem: Sie bringen eine neue Risikokategorie mit sich, auf die in traditionellen Sicherheitstrainings bisher nicht hingewiesen wird. Das Klonen oder Öffnen eines Git-Repositories ist keine passive Handlung mehr, sondern kann zu einer potenzieller Code-Ausführung führen.
Die Gefahr: Automatische Codeausführung ohne Warnung oder Sandbox
Cursor unterstützt eine Funktion namens Hooks — kleine Automatisierungsskripte, die ein Projekt in einer versteckten Datei (.cursor/hooks.json) mitliefern kann. Ursprünglich wurden sie entwickelt, damit der KI-Assistent die jeweilige Codebase besser versteht.
Der Ablauf in der Praxis:
- Ein Entwickler klont oder öffnet ein Repository (Open-Source-Code wie z. B. der Code eines externen Dienstleisters, ein Bewerber-Testcode oder eine geforkte Dependency).
- Der Cursor liest die Datei
.cursor/hooks.jsonaus dem Projektordner. - Der Inhalt dieser Datei wird sofort ausgeführt — mit den Rechten des angemeldeten Benutzers.
- Es gibt keine Sandbox, keine Sicherheitsabfrage und auch keinen sichtbaren Log-Eintrag.
Das Sicherheitsnetz der IDE, die Funktion „Workspace Trust“, die eigentlich vor dem Ausführen von Projekt-Automatisierungen warnen soll, ist in Cursor standardmäßig deaktiviert.
Die geschäftlichen Auswirkungen
Wird ein präpariertes Repository geöffnet, kann ein Angreifer folgendes anrichten:
Die Reichweite des Angriffs entspricht exakt dem, worauf der Laptop des Entwicklers Zugriff hat.
Warum klassische Schutzmaßnahmen versagen
Antiviren-Programme und EDR-Lösungen sehen Cursor als eine legitime, signierte Anwendung. Die schädliche Aktivität sieht aus wie ganz normales Entwicklerverhalten und bleibt unentdeckt:
- Code-Reviews prüfen selten versteckte Konfigurationsordner. Prüfer winken
.cursor/genauso ungeschaut durch wie.vscode/. - Workspace Trust würde helfen — ist aber standardmäßig ausgeschaltet. Die meisten Nutzer sehen also nie eine Warnung.
- Kein Befehl eingetippt. Der Entwickler hat nur einen Ordner geöffnet. Es gibt keine bewusste Handlung, an der ein Training ansetzen könnte.
Drei Sofortmaßnahmen zur Schutz vor Angriffen
Das Enwicklerteam braucht kein neuen Tool einzuführen, sollte aber folgende drei Gewohnheiten etablieren:
1. IDE-Konfigurationsordner wie ausführbaren Code behandeln
Bevor ein Repository aus externen Quellen geöffnet wird wie z. B. Drittanbieter-Code, Dienstleister, Bewerber oder neue Dependencies, lohnt sich ein kurzer Blick in folgende Ordner:
.cursor/(besondershooks.jsonundmcp.json).vscode/(tasks.json,settings.json,launch.json).devcontainer/.husky/und.git/hooks/
Wer ein beliebiges Skript aus diesem Repo nicht einfach ausführen würde, sollte es auch nicht in Cursor öffnen, ohne diese Dateien vorher zu prüfen. Ein kurzer Blick in einem einfachen Texteditor reicht völlig aus.
2. Konfiguration auf Benutzerebene auditieren
Die persönliche Cursor-Konfiguration liegt unter ~/.cursor/ (macOS/Linux) bzw. %USERPROFILE%\.cursor\ (Windows). Routinemäßig einmal im Quartal (oder im Rahmen der Endpoint-Pflege) prüfen:
~/.cursor/hooks.json~/.cursor/mcp.json~/.cursor/rules/
Alles, was dort nicht bewusst abgelegt wurde, ist eine Warnung und erfordert eine Überprüfung.
3. Unbekannten Code nicht auf Systemen mit Root-Zugriff öffnen
Für die Überprüfung von externem Code bietet sich eine Einweg-Umgebung an: eine VM, ein Container oder ein dedizierter Review-Laptop ohne Zugangsdaten zur Produktionsumgebung, ohne SSH-Keys und ohne Cloud-Profile. Über die Remote-SSH- und Dev-Container-Features von Cursor geht das problemlos.
5-Minuten-Checkliste für das Entwicklerteam
Zusatzschutz durch Sichtbarkeit auf den Endpunkten
Gute Gewohnheiten helfen bei der Schließung von dSicherheitslücken, doch Fehler passieren. Da Cursor Skripte lokal ausführt, schützt ein MDR-Service wie Baobab MDR dort, wo klassische Antiviren-Software versagt: Statt statischer Dateimuster überwacht ein Expertenteam das Systemverhalten in Echtzeit. Da 75 % aller Cyberangriffe erst durch Log-Dateien entdeckt werden (Bitkom 2025), schließt diese Analyse eine kritische Lücke.
Drei Gründe sprechen für einen dedizierten MDR-Service:
- Erkennung verhaltensbasierter Anomalien: Startet eine IDE unerwartet eine Hintergrund-Shell oder greift auf
~/.ssh/id_rsazu, schlägt das Team sofort Alarm. - Kontextuelle Alarm-Bewertung: Entwickler führen laufend Skripte aus. Um Alarm-Müdigkeit durch Fehlalarme zu vermeiden, unterscheiden Security-Experten reguläre Build-Skripte präzise von echten Exploits.
- Sofortige Isolierung im Ernstfall: Greift ein Exploit, zählt jede Sekunde. Der Service kann den betroffenen Laptop automatisch vom Netzwerk isolieren, bevor sich Angreifer weiter ausbreiten.
Fazit
KI-gestützte Entwicklungsumgebungen bieten erhebliche Produktivitätsvorteile und etablieren sich fest im Entwickleralltag. Gleichzeitig verändert sich die Sicherheitsarchitektur: Das Öffnen eines Projektordners entspricht technisch der Ausführung von Code. Die Behandlung von IDE-Konfigurationsdateien als ausführbarer Code reduziert dieses Risiko maßgeblich. Der Einschluss dieser Prüfroutinen in Standardprozesse und Onboardings schließt eine relevante Sicherheitslücke mit minimalem Aufwand.
Der Blogartikel wurde verfasst von
