Kritische Schwachstelle in KI-basiertem Coding-Tool Cursor

[English]Sicherheitsforscher von Check Point haben eine schwerwiegende Sicherheitslücke im KI-Entwickler-Tool Cursor gefunden. Die von Check Point als MCPoison bezeichnete Schwachstelle (CVE-2025-54136) ermöglicht Angreifern über das MCP-System von Cursor, schädlichen Code in die Projekte der Nutzer einzuschleusen. Das ist ein Paradebeispiel für neuartige Lieferketten-Angriffe in KI-gestützten Entwickler-Umgebungen.

Check Point Research (CPR) hat eine kritische Schwachstelle im KI-basierten Coding-Tool Cursor entdeckt, die es Hackern erlaubt, dauerhaft Remote-Code auszuführen. CPR kam der Schwachstelle (CVE-2025-54136) bei der Untersuchung von Sicherheitsmodellen innerhalb von MCP-Systemen KI-unterstützter Coding-Tools auf die Schliche. Die Sicherheitslücke betrifft das Model Context Protocol (MCP) von Cursor und kann zur wiederholten Einschleusung von schädlichem Code missbraucht werden. 

Was ist Cursor?

Bei Cursor handelt es sich um eine IDE (Integrierte Entwicklungsumgebung), die eines der am schnellsten wachsenden KI-gestützten Coding-Tools ist. Cursor kombiniert die lokale Code-Bearbeitung mit leistungsstarken LLM-Integrationen, um Teams beim Schreiben, Debuggen und Durchsuchen von Code zu helfen. Aufgrund seiner Flexibilität wird Cursor zunehmend von Startups, Forschergruppen und einzelnen Entwicklern eingesetzt, die KI-Tools direkt in ihre Entwicklung integrieren möchten.

Die zunehmende Beliebtheit hat CPR veranlasst, sich das Sicherheitsmodell hinter diesen Tools genauer anzuschauen. In das Blickfeld der Untersuchung geriet das MCP-System von Cursor. Dabei handelt es sich um Konfigurationsdateien, die Cursor mitteilen, wie bestimmte Aufgaben zu automatisieren sind. Entwickler können über diese Funktion verschiedene Tools, Skripte oder KI-gesteuerte Workflows direkt in ihre Programmierumgebung einbinden.

CPR untersuchte, ob Cursor Code-Änderungen innerhalb von MCP angemessen berücksichtigt. Bei der kollaborativen Entwicklung kommen Bearbeitungen häufig vor und jede Lücke in der Validierung kann zu Befehlsinjektionen, Code-Ausführung oder dauerhaften Kompromittierungen führen.

Wie die Sicherheitslücke funktioniert

Wenn ein Benutzer ein Projekt öffnet, das eine MCP-Konfiguration enthält, zeigt Cursor eine einmalige Genehmigungsaufforderung an, in der gefragt wird, ob der Nutzer der Konfiguration vertraut. Doch hier liegt das Problem: Sobald ein MCP genehmigt ist, wird er von Cursor nie wieder überprüft, selbst wenn die darin enthaltenen Befehle später stillschweigend geändert werden.

Das bedeutet, dass ein Angreifer, der mit demselben gemeinsamen Repository arbeitet, eine sicher erscheinende MCP-Konfiguration zu einem Projekt hinzufügen und dann darauf warten kann, dass jemand anderes aus dem Team sie abruft. Diese Konfiguration kann er später für bösartige Zwecke nutzen, zum Beispiel, um ein Skript zu starten, eine Hintertür zu öffnen oder Daten an einen externen Server zu senden. Jedes Mal, wenn das Opfer das Projekt in Cursor öffnet, wird der neue Befehl automatisch ausgeführt, ohne eine neue Eingabeaufforderung oder Warnung auftauchen zu lassen.

CheckPoint hat die technischen Einzelheiten und ein Demo-Video des Angriffs in diesem Artikel veröffentlicht. 

Warum die Sicherheitslücke gefährlich ist

CPR fand genau das: eine schwerwiegende Schwachstelle im MCP-System von Cursor, die eine dauerhafte Remotecode-Ausführung (RCE) ermöglicht. Sobald ein Benutzer eine MCP-Konfiguration genehmigt hat, kann ein Angreifer deren Verhalten unbemerkt ändern. Von diesem Moment an können bösartige Befehle jedes Mal ausgeführt werden, wenn das jeweilige Projekt ohne weitere Aufforderungen oder Benachrichtigungen geöffnet wird. Ein Angreifer kann in diesem Fall:

• eine harmlos aussehende MCP-Konfiguration zu einem freigegebenen Repository hinzufügen.
• warten, bis das Opfer den Code abruft und ihn einmal in Cursor IDE freigibt.
• die MCP-Konfiguration durch eine bösartige Nutzlast ersetzen.
• jedes Mal, wenn das Opfer Cursor öffnet, unbemerkt und dauerhaft Code ausführen.

In gemeinsam genutzten Programmierumgebungen verwandelt die Schwachstelle einen vertrauenswürdigen MCP in einen versteckten, kontinuierlichen Angriffspunkt. Für Unternehmen, die sich auf KI-Tools wie Cursor verlassen, hat dies schwerwiegende Folgen: unbemerkter, ständiger Zugriff auf Entwicklerrechner, Anmeldedaten und Code-Fundamente, ausgelöst durch eine einzige Genehmigung.

Auswirkungen in der realen Welt

Da in vielen Unternehmen Projekte über Repositories gemeinsam genutzt und synchronisiert werden, bietet diese Schwachstelle Angreifern eine ideale Möglichkeit, langfristig und unbemerkt Fuß zu fassen.

• Das macht die Schwachstelle gefährlich: Es gibt ein stilles Fortbestehen von bösartigem Code- Jedes Mal, wenn ein Nutzer das Projekt öffnet, wird (bösartiger) Code ausgeführt, ohne eine Benachrichtigung der Benutzer oder das Erfordern weiterer Genehmigungen. Das bedeutet, dass Angreifer auf unbestimmte Zeit Zugriff auf das Projekt erhalten können.
• Große Angriffsfläche: Jeder Entwickler mit Schreibzugriff auf ein gemeinsam genutztes Repository kann diese vertrauenswürdige MCP-Konfiguration einspeisen und ändern, wodurch ganze Teams und Organisationen gefährdet werden.
• Risiken der Privilegien-Eskalation: Auf den Rechnern von Entwicklern sind häufig sensible Anmeldedaten, Cloud-Zugangsschlüssel oder andere sensible Informationen lokal gespeichert. Ein Angreifer, der diese Schwachstelle ausnutzt, kann den Zugriff auf Unternehmensnetzwerke erweitern.
• Offenlegung von Daten und Code: Neben der direkten Ausführung von Code könnten Angreifer unbemerkt Quellcode, geistiges Eigentum oder interne Kommunikation ausspähen.
• Vertrauen in KI-Tools wird untergraben: Da KI-Tools wie Cursor immer stärker in die Software-Entwicklung integriert werden, muss ihr Sicherheitsmodell hieb- und stichfest sein. Diese Schwachstelle verdeutlicht die Gefahren von blindem Vertrauen in automatisierte Arbeitsabläufe.

Für Unternehmen, die sich auf Cursor und ähnliche KI-gestützte IDEs verlassen, ist das Verständnis und die Behebung dieser Schwachstelle entscheidend für den Schutz ihrer Entwicklungsumgebungen und sensiblen Ressourcen.

Um Schwachstelle in KI-gestützten Entwicklungsumgebungen zu entschärfen, empfiehlt CPR:

• MCP-Konfigurationsdateien als Angriffsfläche behandeln: Genau wie der Quellcode sollten auch Automatisierungsskripte und MCP-Konfigurationsdefinitionen sorgfältig geprüft, auditiert und über Versionen kontrolliert werden.
• Implizites Vertrauen in KI-gesteuerte Automatisierungen vermeiden: Auch dann, wenn ein MCP oder ein Vorschlag harmlos aussieht, sollten Nutzer sicherstellen, dass alle Team-Mitglieder verstehen, was dieser tut, bevor man ihn genehmigt.
• Schreibrechte in kollaborativen Umgebungen einschränken: Sicherheitsverantwortliche sollten kontrollieren, wer vertrauenswürdige Konfigurationsdateien ändern darf, insbesondere in gemeinsam genutzten Repositories.

„KI-gestützte Entwickler-Tools verändern die Software-Entwicklung, schaffen aber auch neue Angriffsflächen, die das Vertrauen der Entwickler ausnutzen wollen", so Oded Vanunu, Chief Technologist & Head of Product Vulnerability Research bei Check Point Software Technologies: „MCPoison zeigt, wie einfach Automatisierung und Komfort für heimliche, langfristige Ausbeutung in kollaborativen Programmierumgebungen missbraucht werden können."

Verantwortungsvolle Offenlegung und Entschärfung

Nach der Entdeckung dieser Schwachstelle hat Check Point Research das Cursor-Entwickler-Team am 16. Juli 2025 verantwortungsbewusst über das Problem informiert. Cursor veröffentlichte am 30. Juli 2025 einen Fix.

Weitere Informationen finden sich im Beitrag Cursor IDE: Persistent Code Execution via MCP Trust Bypass im CPR-Blog.