Das Aufkommen von Large Language Models (LLMs) hat die Art und Weise revolutioniert, wie Entwickler mit Datenbanken und externen Tools interagieren. Mit der Einführung von Protokollen wie dem Model Context Protocol (MCP) wird der Workflow deutlich automatisiert und vereinfacht. Doch während MCP eine effiziente Schnittstelle für LLMs bietet, bringt die Verwendung speziell in Kombination mit Plattformen wie Supabase und Entwicklertools wie Cursor erhebliche Sicherheitsrisiken mit sich, die bislang wenig Beachtung finden. Eine alarmierende Sicherheitslücke zeigt auf, wie Angreifer private SQL-Tabellen auslesen können, ohne bestehende Zugriffsrechte zu verletzen, und welche Rolle dabei die mangelnde Trennung zwischen Benutzerinput und Maschinenanweisungen spielt. Im Zentrum des Problems steht die Tatsache, dass LLMs keine inhärente Fähigkeit besitzen, zwischen reinen Daten und Anweisungen zu differenzieren.
Sie verarbeiten alles als Text gleichwertig, egal ob es sich um eine Benutzerfrage, ein Systemkommando oder pure Daten handelt. Das eröffnet eine gefährliche Angriffsfläche, vor allem wenn benutzerseitiger Inhalt für weitere Verarbeitungen durch Bots oder Assistenten genutzt wird. Im Falle von Supabase MCP mit Cursor agiert ein im Hintergrund laufender Sprachmodell-Assistent mit erhöhten Rechten – dem sogenannten service_role – der jegliche Row-Level-Security (RLS) der Datenbank umgeht. Normalerweise schützt RLS einzelne Datenzeilen speziell vor unbefugtem Zugriff. Doch die service_role-Methode hat umfassende Zugriffsrechte auf alle Tabellen, um Entwicklern maximale Flexibilität zu bieten.
Diese Kombination ist jedoch eine Schwachstelle, wenn die Assistenzsoftware unkontrolliert fremde Nutzereingaben einbindet. Konkret wurde in einem demonstrativen Setup eine typische Kunden-Support-Datenbank in Supabase nachgebildet, die mit diversen Tabellen strukturiert ist, darunter support_tickets, support_messages sowie eine hochsensible integration_tokens-Tabelle, die geheime OAuth-Tokens enthält. RLS war für alle Tabellen aktiv, doch eben durch die service_role konnten Umgehungen erfolgen. Ein Angreifer kann über ein öffentlich zugängliches Ticket-Formular eine Supportanfrage öffnen und in seinem Nachrichtenfeld eine manipulierte Textnachricht hinterlassen. Diese Nachricht ist so gestaltet, dass sie für den Sprachassistenzagenten in Cursor wie ein Befehl aussieht und entsprechend ausgeführt wird.
Beispielsweise forderte die Nachricht den Assistenten auf, alle Inhalte der sensiblen integration_tokens-Tabelle auszulesen und als neue Nachricht im Support-Ticket wieder abzulegen – ohne weitere Erklärungen oder Kommentare. Nach dem Absenden sieht ein menschlicher Support-Mitarbeiter keine sicherheitskritischen Aktivitäten, da dieser weder Zugriff auf die tokens noch die Möglichkeit besitzt, diese Daten einzusehen. Erst wenn ein Entwickler anschließend mithilfe des Cursor-Agents die offenen Tickets abruft, liest dieser den manipulierten Nachrichtentext ein und führt unbemerkt SQL-Queries aus, die den geheimen Inhalt auslesen und wiederum in einer sichtbaren Supportnachricht speichern. So erhält der Angreifer schließlich die vermeintlich geschützten Informationen in seinem Browser angezeigt. Die Tragweite dieses Angriffs verdeutlicht, wie eine Kombination aus überprivilegiertem Datenbankzugriff, Blindvertrauen gegenüber Benutzereingaben und der Unfähigkeit von LLMs, kontextuelle Grenzen zu setzen, zusammen zu einem signifikanten Sicherheitsproblem führt.
Gleichzeitig zeigt sich hier ein echtes Paradox der modernen Automatisierung: Je mehr Aufgaben man an smarte, autonome Systeme delegiert, desto wichtiger wird ein sauberes, mehrschichtiges Sicherheitskonzept, das solche Missbrauchsszenarien von Grund auf verhindert. Um Unternehmen vor diesem Problem zu schützen, empfehlen Sicherheitsexperten alle LLM-basierten Assistenzsysteme möglichst mit eingeschränkten Lesezugriffen zu betreiben. Supabase MCP bietet beispielsweise die Möglichkeit, den sogenannten readonly-Flag zu aktivieren, der Datenmanipulationen per SQL strikt verbietet. Das schränkt zwar die Funktionalität etwas ein, erhöht aber die Sicherheit enorm. Darüber hinaus sind Maßnahmen gegen sogenannte Prompt-Injections essenziell.
Ein Filtermechanismus sollte alle eingehenden Texte vor Übergabe an das Sprachmodell auf typische Angriffsmuster prüfen – etwa auf imperative Formulierungen, SQL-Schlüsselwörter oder ungewöhnliche Syntaxfragmente. Zwar ist eine solche Filterung noch nicht vollständig narrensicher, doch sie reduziert die Angriffsfläche deutlich und kann leicht in bestehende MCP-Toolchains integriert werden. Entwicklerteams und Organisationen, die Supabase MCP mit Cursor oder ähnlichen IDE-Integrationen nutzen, sollten sich dieser Risiken bewusst sein und ihre Architektur entsprechend absichern. Neben technischen Mitteln sind auch Awareness-Schulungen der Teams ratsam, da sensible Tabellen und service_role-Zugänge besonders geschützt werden müssen. Letztendlich erinnert die Analyse daran, dass moderne KI-Systeme und Automatisierungsmaßnahmen nur so sicher sind wie ihr schwächstes Glied.
