Anfang März 2026 sorgte eine Meldung für Aufsehen in der IT-Sicherheitsbranche: Ein autonomer KI-Agent des Startups CodeWall hatte laut eigenen Angaben innerhalb von zwei Stunden eine schwerwiegende Sicherheitslücke in McKinseys interner KI-Plattform „Lilli“ ausgenutzt. Die Plattform, die von über 43.000 McKinsey-Beratern weltweit genutzt wird, war über unauthentifizierte API-Endpunkte und eine klassische SQL-Injection-Schwachstelle angreifbar. Der Vorfall wirft Fragen auf – nicht nur über die Sicherheit von KI-Plattformen in Unternehmen, sondern auch über die Glaubwürdigkeit der beteiligten Akteure, die regulatorischen Konsequenzen und die tatsächliche Tragweite des Angriffs.
Was: SQL-Injection-Angriff auf McKinseys interne KI-Plattform „Lilli“ durch einen autonomen KI-Agenten
Wer: Das Startup CodeWall (Anbieter von KI-basiertem Red Teaming) als Angreifer; McKinsey als Betreiber
Wann: 1. März 2026 (Meldung) – 2. März (Patch) – 9. März (Veröffentlichung durch CodeWall)
Methode: SQL Injection über unauthentifizierte API-Endpunkte, JSON-Key-Verarbeitung als Einfallstor
Behauptete Exposition: 46,5 Mio. Chat-Nachrichten, 728.000 Dateien, 57.000 Nutzerkonten (nicht unabhängig verifiziert)
Status: Schwachstelle bestätigt und gepatcht; tatsächliche Datenkompromittierung umstritten
Was ist passiert? Die Chronologie des Vorfalls
McKinseys KI-Plattform Lilli wurde 2023 eingeführt und dient als internes Wissensmanagement-Tool. Berater nutzen Lilli, um auf das kollektive Wissen der Firma zuzugreifen – von früheren Projektberichten über Branchenanalysen bis hin zu internen Methodiken. Die Plattform verarbeitet natürlichsprachige Anfragen und greift dabei auf eine umfangreiche Wissensbasis zu, die Dokumente, Chat-Verläufe und strukturierte Daten umfasst.
Am 1. März 2026 setzte das Cybersecurity-Startup CodeWall einen autonomen KI-Agenten auf die öffentlich erreichbaren Schnittstellen von Lilli an. Der Agent identifizierte zunächst die öffentlich zugängliche API-Dokumentation der Plattform. Von den insgesamt 22 API-Endpunkten waren laut CodeWall 20 ohne jegliche Authentifizierung erreichbar – ein fundamentaler Architektur-Fehler, der einem Angreifer die systematische Erkundung der gesamten Angriffsfläche ermöglichte.
Der entscheidende Durchbruch gelang über eine SQL-Injection-Schwachstelle in der JSON-Key-Verarbeitung eines der offenen Endpunkte. Schlüsselnamen aus JSON-Anfragen wurden direkt in SQL-Abfragen konkateniert – ohne jede Validierung oder Parametrisierung. Über diesen Vektor erlangte der Agent nach CodeWalls Darstellung vollen Lese- und Schreibzugriff auf die Datenbank, einschließlich der Möglichkeit, System-Prompts der KI zu manipulieren.
Hier ergibt sich eine erste Unstimmigkeit: CodeWall spricht von der „Produktionsdatenbank“, McKinsey hingegen nahm nach dem Patch die „Entwicklungsumgebung“ offline. Ob der Angriff die Produktions- oder eine Entwicklungsumgebung traf, ist ein erheblicher Unterschied in der Tragweite – und eine Frage, die bislang nicht abschließend geklärt ist.
McKinsey reagierte innerhalb von 24 Stunden: Am 2. März wurde die Schwachstelle gepatcht. Eine neuntägige forensische Untersuchung schloss sich an – branchenübliche Incident-Response-Analysen bei vergleichbaren Vorfällen dauern typischerweise mehrere Wochen bis Monate. Am 9. März veröffentlichte CodeWall die Details des Angriffs, ohne eine in der Security-Community übliche Responsible-Disclosure-Frist einzuhalten.
Quellenbewertung: Was ist bestätigt – und was nicht?
Bei der Einordnung des Lilli-Hacks ist eine differenzierte Betrachtung der Quellenlage unerlässlich. Denn beide Seiten – CodeWall und McKinsey – haben erhebliche kommerzielle Interessen, die ihre Darstellung beeinflussen.
| Aussage | Status | Bewertung |
|---|---|---|
| SQL-Injection-Schwachstelle in Lilli | Bestätigt | Durch McKinseys eigenes Statement und den sofortigen Patch belegt |
| 20 unauthentifizierte API-Endpunkte | Plausibel | Technisch konsistent mit dem Angriffsmuster, nicht unabhängig verifiziert |
| 46,5 Mio. Nachrichten / 728.000 Dateien exponiert | Nicht belegt | Keine PoC-Payloads, Screenshots oder Hashes vorgelegt |
| Schreibzugriff auf System-Prompts | Behauptet | Kein unabhängiger Beleg; wäre sicherheitskritisch, da Manipulation der KI-Antworten möglich |
| Kundendaten tatsächlich kompromittiert | Strittig | McKinsey bestreitet; Forensik ergab laut Firmenangaben keinen Nachweis einer Datenkompromittierung |
Zwei Parteien, zwei Interessen
CodeWall ist ein Startup, das KI-basierte Red-Teaming-Dienste verkauft. Ein erfolgreicher Hack gegen den bekanntesten Beraternamen der Welt liefert enorme Gratis-PR und validiert das eigene Geschäftsmodell. Der Anreiz, die Darstellung möglichst dramatisch zu gestalten, liegt auf der Hand. Auffällig ist, dass die spektakulärsten Zahlen – 46,5 Millionen Nachrichten, 728.000 Dateien, 57.000 Nutzerkonten – ausschließlich von CodeWall stammen und nicht durch Screenshots, Hashes oder Proof-of-Concept-Payloads belegt werden.
McKinsey wiederum hat ein ebenso starkes Gegeninteresse. Vertrauen ist das Kernprodukt einer Beratungsfirma. Wenn Klienten befürchten müssen, dass ihre strategischen Gespräche mit McKinsey-Beratern in einer kompromittierten Datenbank landen, steht die Geschäftsgrundlage auf dem Spiel. Das Interesse, den Vorfall herunterzuspielen, ist offensichtlich. Hinzu kommt, dass das neuntägige Forensik-Fenster zwischen Patch und Veröffentlichung vergleichsweise kurz für eine vollständige Analyse ist. Laut einem Bericht der Financial Times betonte McKinsey, dass „Dateien separat gespeichert und nie gefährdet gewesen seien“.
Die Klienten-Perspektive: Der blinde Fleck
In der öffentlichen Debatte zwischen CodeWall und McKinsey gerät eine dritte Partei aus dem Blick: McKinseys Klienten. Wenn Berater über Lilli Fragen eingeben wie „Soll unser Klient Standort X schließen?“ oder vertrauliche Strategiedokumente in die Wissensbasis einspeisen, betrifft eine Kompromittierung nicht nur McKinseys eigene Daten. Die Frage, welche vertraulichen Unternehmensinformationen in Lilli-Chats geteilt wurden und ob diese Klienten sicher sein können, dass ihre Daten nicht exponiert waren, hat bislang keine zufriedenstellende Antwort erhalten.
Regulatorische Konsequenzen
Falls tatsächlich personenbezogene Daten betroffen waren – und bei 57.000 Nutzerkonten mit Chat-Verläufen ist das kaum auszuschließen – greift die DSGVO-Meldepflicht nach Art. 33: Der Verantwortliche muss die zuständige Aufsichtsbehörde innerhalb von 72 Stunden über eine Verletzung des Schutzes personenbezogener Daten informieren. Ob McKinsey eine solche Meldung abgegeben hat, ist nicht bekannt. Die Darstellung, es habe „keine Datenkompromittierung“ gegeben, könnte auch dem Umstand geschuldet sein, dass eine Bestätigung automatisch Meldepflichten und potenzielle Bußgelder auslösen würde.
Hinzu kommt: Seit Januar 2025 ist der Digital Operational Resilience Act (DORA) anwendbar. McKinsey ist als IKT-Drittdienstleister für zahlreiche Finanzinstitute tätig. Unter DORA sind viele der im Folgenden beschriebenen Maßnahmen – Penetrationstests, Incident Response, Monitoring – für solche Dienstleister keine Empfehlung mehr, sondern regulatorische Pflicht.
Ursachenanalyse: Warum war der Angriff möglich?
Unabhängig davon, wie viele Daten tatsächlich exponiert waren – die Tatsache, dass der Angriff überhaupt möglich war, verdient eine genauere Analyse. Die unbequemste Erkenntnis: Nicht die KI wurde gehackt, sondern die klassische Infrastruktur darunter. Dass eine Plattform dieses Profils an genau dieser Stelle versagt, deutet auf systematische Defizite hin.
SQL Injection – der Angriffsvektor im Detail
Um zu verstehen, warum der Lilli-Hack so einfach war, lohnt ein Blick auf die Funktionsweise von SQL Injection. Webanwendungen kommunizieren mit Datenbanken über sogenannte SQL-Abfragen – strukturierte Befehle, die Daten abfragen, einfügen oder verändern. Das Problem entsteht, wenn Eingaben eines Nutzers direkt in diese Befehle eingebaut werden, ohne sie vorher zu prüfen.
Ein vereinfachtes Beispiel: Wenn ein Berater in Lilli nach dem Thema „Automotive“ sucht, erzeugt die Anwendung intern eine Datenbankabfrage wie SELECT * FROM documents WHERE topic = 'Automotive'. Das funktioniert wie erwartet – die Datenbank liefert alle Dokumente zum Thema Automotive zurück.
Bei einer SQL Injection gibt der Angreifer statt eines normalen Suchbegriffs einen manipulierten Text ein, der von der Datenbank als Befehl interpretiert wird. Statt „Automotive“ könnte ein Angreifer beispielsweise ' OR 1=1 -- eingeben. Die Datenbank interpretiert das als: „Gib mir alle Dokumente, bei denen das Thema leer ist oder 1 gleich 1 ist“ – und da 1 immer gleich 1 ist, liefert die Datenbank sämtliche Dokumente zurück. Die beiden Bindestriche am Ende kommentieren den Rest der ursprünglichen Abfrage aus, sodass keine Fehlermeldung entsteht.
Im Fall von Lilli war die Schwachstelle besonders perfide: Nicht die eigentlichen Sucheingaben der Nutzer waren das Einfallstor, sondern die Schlüsselnamen in JSON-Anfragen – also die technischen Feldbezeichnungen in der Kommunikation zwischen Browser und Server. Statt eines normalen JSON-Feldes wie {"topic": "Automotive"} konnte der Angreifer den Schlüssel selbst manipulieren: {"topic' OR 1=1--": "irrelevant"}. Da die Entwickler zwar möglicherweise die Werte, nicht aber die Schlüsselnamen validierten, wurde dieser manipulierte Text direkt in die Datenbankabfrage eingebaut.
Der Schutz dagegen ist nicht neu und eigentlich lange bekannt – er ist in jeder modernen Programmiersprache verfügbar: Parameterized Queries. Dabei werden die SQL-Abfrage und die Nutzereingaben strikt getrennt verarbeitet. Die Datenbank erhält zuerst den Befehl als festes Template mit Platzhaltern, dann separat die Eingabewerte. Da die Datenbank die Eingaben nur noch als Daten behandelt – nie als ausführbaren Code – ist SQL Injection strukturell unmöglich. Dass eine Plattform mit dem Reifegrad und der Nutzerbasis von Lilli ohne diesen Schutz in Produktion ging, deutet auf fehlende Security Code Reviews, unzureichende Qualitätssicherung oder eine Kultur, in der Geschwindigkeit systematisch über Sicherheit gestellt wurde.
Offene API-Endpunkte
Laut CodeWall waren 20 von 22 API-Endpunkten ohne Authentifizierung erreichbar. Hinzu kam eine öffentlich zugängliche API-Dokumentation, die dem Angreifer eine detaillierte Karte der Angriffsfläche lieferte. Das Fehlen eines zentralen API-Gateways mit einheitlicher Authentifizierungsprüfung verweist auf eine Architektur, in der Sicherheit nicht als Querschnittsfunktion implementiert wurde, sondern – wenn überhaupt – jedem einzelnen Service überlassen blieb.
Fehlendes Monitoring
Der KI-Agent von CodeWall arbeitete zwei Stunden lang unbemerkt auf den Systemen. Keine Anomalie-Erkennung schlug an, kein Alert wurde bei den unbekannten API-Zugriffen ausgelöst, keine Rate-Limiting-Mechanismen bremsten die systematische Enumeration. Für eine Plattform, die sensible Unternehmensdaten einer der größten Beratungsfirmen der Welt verarbeitet, ist das ein gravierendes Versäumnis.
Alle drei Ursachen sind vermeidbare Basics – keine davon erfordert innovative Sicherheitstechnologie. Im Lilli-Fall hätte bereits eine einzige dieser Maßnahmen (Parameterized Queries oder API-Authentifizierung) den Angriff vollständig verhindert. Dass alle drei gleichzeitig fehlten, spricht für ein systemisches Problem.
Was Unternehmen daraus lernen sollten
Der Lilli-Hack ist kein isolierter Einzelfall. Er steht exemplarisch für ein Muster, das sich in vielen Unternehmen beobachten lässt: KI-Plattformen werden mit hohem Tempo entwickelt und ausgerollt, während die Absicherung der darunterliegenden Infrastruktur nicht Schritt hält. Die Empfehlungen lassen sich in zwei Kategorien unterteilen: grundlegende Infrastrukturmaßnahmen und KI-spezifische Sicherheitsvorkehrungen.
Infrastruktur: Die Basics richtig machen
Parameterized Queries müssen ausnahmslos eingesetzt werden – niemals dürfen Nutzereingaben in SQL-Statements konkateniert werden. Input-Validierung muss an jeder Systemgrenze stattfinden, auch bei internen KI-Agenten. Die OWASP Top 10 sollten als verbindlicher Mindeststandard für jede Anwendung gelten. Security-fokussierte Code Reviews vor jedem Deployment sind keine optionale Maßnahme, sondern Pflicht.
Kein API-Endpunkt darf ohne Authentifizierung erreichbar sein – weder in Produktion noch in Staging- oder Entwicklungsumgebungen. Ein zentrales API-Gateway sollte die Authentifizierung einheitlich durchsetzen, statt diese Verantwortung an einzelne Services zu delegieren. API-Dokumentationen wie Swagger oder OpenAPI dürfen nicht öffentlich exponiert werden. Rate Limiting muss systematisches Enumerieren und Brute-Force-Angriffe blockieren.
Jeder Request muss verifiziert werden – unabhängig von seiner Netzwerkherkunft. Das Least-Privilege-Prinzip muss konsequent umgesetzt werden: Jede Anfrage erhält nur Zugriff auf die minimal benötigten Daten. Datenbereiche wie Chat-Verläufe, Dokumente, System-Prompts und Nutzerverwaltung müssen segmentiert werden. Insbesondere darf kein Schreibzugriff auf System-Prompts über User-Interfaces möglich sein.
Anomalie-Erkennung muss Massenabfragen sofort flaggen. Realtime-Alerting bei ungewöhnlichen Zugriffsmustern – etwa unbekannte API-Clients oder atypische Abfragefrequenzen – ist unverzichtbar. Audit Logging für alle Datenbankzugriffe schafft die Grundlage für forensische Untersuchungen. Incident-Response-Pläne müssen spezifisch für KI-Plattformen vorbereitet werden, da diese eigene Angriffsvektoren mitbringen.
KI-spezifische Sicherheitsmaßnahmen
Neben der grundlegenden Infrastrukturabsicherung erfordern GenAI-Plattformen zusätzliche Schutzmaßnahmen, die den besonderen Risiken dieser Technologie Rechnung tragen.
System-Prompts definieren das Verhalten einer KI-Plattform. Wer sie manipulieren kann, kontrolliert die Antworten des Systems – mit potenziell verheerenden Konsequenzen. System-Prompts müssen daher versioniert und auditiert werden, mit einem definierten Change-Prozess. Schreibzugriff darf nur über eine separate, gesicherte Admin-Schnittstelle möglich sein. Regelmäßige Integritätsprüfungen der aktiven Prompts sind unerlässlich.
Retrieval-Augmented Generation (RAG) greift auf Wissensdatenbanken zu. Dabei muss die KI die Berechtigungen des anfragenden Nutzers respektieren – ein Berater darf nicht über die KI auf Dokumente zugreifen, für die er keine Berechtigung hat. Output Filtering gegen Cross-User Data Leakage und eine konsequente Datenklassifizierung in der Wissensbasis sind weitere notwendige Maßnahmen.
Regelmäßige Penetrationstests müssen explizit KI-Plattformen einschließen. Red Teaming mit automatisierten KI-Agenten – genau die Methode, die CodeWall einsetzte – sollte Teil des eigenen Sicherheitsprogramms sein. Bug-Bounty-Programme mit klar definiertem Scope schaffen zusätzliche Sicherheitsschichten. Entscheidend: Pentests müssen vor dem Go-live stattfinden, nicht erst im laufenden Betrieb.
Die strikte Trennung von System- und Nutzer-Prompts ist die erste Verteidigungslinie gegen Prompt Injection. Input Sanitization für alle Nutzeranfragen, Monitoring auf bekannte Prompt-Injection-Muster und regelmäßige Tests mit bekannten Angriffsvektoren ergänzen den Schutz. Diese Maßnahmen sind für jede GenAI-Plattform in einer Unternehmensumgebung obligatorisch.
Prioritätenmatrix: Was hätte den Lilli-Hack verhindert?
Nicht alle Maßnahmen haben denselben Hebel. Die folgende Matrix ordnet die wichtigsten Sicherheitsmaßnahmen nach ihrer Wirksamkeit im konkreten Fall und dem erforderlichen Implementierungsaufwand ein:
| # | Maßnahme | Hätte Hack verhindert? | Aufwand |
|---|---|---|---|
| 1 | Parameterized Queries durchsetzen | Ja – direkt | Gering |
| 2 | Alle API-Endpunkte authentifizieren | Ja – direkt | Gering |
| 3 | API-Dokumentation nicht öffentlich exponieren | Reconnaissance erschwert | Gering |
| 4 | Anomalie-Erkennung auf API-/DB-Ebene | Früherkennung | Mittel |
| 5 | Zero Trust / Least Privilege | Schadensradius begrenzt | Mittel |
| 6 | Regelmäßige Pentests inkl. KI-Plattformen | Vorher gefunden | Mittel |
| 7 | Security Review vor Deployment | Vorher gefunden | Gering |
Die Botschaft ist eindeutig: Die wirksamsten Maßnahmen sind gleichzeitig die einfachsten und kostengünstigsten. Unternehmen, die KI-Plattformen betreiben, sollten ihre eigenen Systeme mit genau dieser Prioritätenlogik überprüfen – zuerst die Basics absichern, dann die komplexeren Maßnahmen angehen.
Fazit: KI-Sicherheit beginnt bei den Basics
Der McKinsey-Lilli-Hack ist ein Lehrstück – allerdings weniger über die Gefahren von KI als vielmehr über die Konsequenzen vernachlässigter IT-Sicherheitsgrundlagen. Die Schwachstelle, die CodeWalls Agent ausnutzte, war keine neuartige KI-Attacke, kein Zero-Day-Exploit, kein Supply-Chain-Angriff. Es war SQL Injection – ein Angriffsvektor, den die OWASP seit ihrer Gründung dokumentiert.
Das sollte Unternehmen, die eigene GenAI-Plattformen betreiben oder planen, nachdenklich stimmen. Die Verlockung ist groß, sich auf die vermeintlich innovativen Risiken von KI zu konzentrieren – Prompt Injection, Halluzinationen, Model Poisoning – und dabei die Sicherheitsanforderungen an die darunterliegende Infrastruktur zu vernachlässigen. Der Lilli-Hack zeigt: Die größte Gefahr lauert nicht in der KI selbst, sondern in den Grundlagen, die als selbstverständlich gelten und deshalb nicht mehr geprüft werden.
Gleichzeitig mahnt der Fall zur Vorsicht bei der Bewertung spektakulärer Sicherheitsvorfälle. Die Kernfrage ist nicht, ob 46,5 Millionen oder „nur“ einige Millionen Nachrichten exponiert waren – die Kernfrage ist, warum eine Plattform dieses Stellenwerts überhaupt so verwundbar sein konnte. Und diese Frage müssen sich nicht nur McKinsey, sondern auch alle Unternehmen stellen, die ihre vertraulichsten Daten KI-Plattformen von Dienstleistern anvertrauen.
Der Lilli-Hack könnte einen Wendepunkt markieren. Wenn selbst McKinsey – eine Firma, die andere Unternehmen über Sicherheitsstrategien berät – an den Basics scheitert, müssen Organisationen ihre Annahmen über die Sicherheitskompetenz ihrer Dienstleister hinterfragen. Fordern Sie Pentest-Reports und SOC-2-Zertifizierungen. Fragen Sie, wie KI-Plattformen Ihrer Partner abgesichert sind. Und prüfen Sie zunächst das Offensichtliche in Ihren eigenen Systemen: Sind alle API-Endpunkte authentifiziert? Nutzen alle Datenbankzugriffe Parameterized Queries? Existiert ein Monitoring, das ungewöhnliche Zugriffsmuster erkennt? Wer eine dieser Fragen nicht sofort bejahen kann, hat sein Handlungsfeld gefunden.