Wenn Ihre Vektordatenbank Pre-Auth-RCE ermöglicht, hat RAG ein Problem auf der Datenebene
Am 18. Mai 2026 veröffentlichte HiddenLayer Forschungsergebnisse zu ChromaToast — offiziell CVE-2026-45829. CVSS-Score: 10.0. Angriffsvektor: Netzwerk. Erforderliche Berechtigungen: keine. Benutzerinteraktion: keine. Die Schwachstelle befindet sich im create_collection-Handler des ChromaDB Python FastAPI Servers: Der Server vertraut auf vom Client bereitgestellte Modellkennungen und handelt entsprechend — einschließlich dem Laden von Code aus externen HuggingFace-Repositories mit trust_remote_code auf true — bevor die Authentifizierungsprüfung erfolgt. Ein nicht authentifizierter Angreifer sendet eine HTTP-Anfrage, der Server lädt und führt angreifergesteuerten Modellcode aus, was zu beliebiger Codeausführung mit Zugriff auf API-Schlüssel, Umgebungsvariablen, gemountete Secrets und alle vom Serverprozess lesbaren Dateien führt.
HiddenLayers Shodan-basierter Scan ergab, dass etwa 73 % der Deployments exponiert sind. HiddenLayer berichtet vom ersten Kontakt mit dem Chroma-Projekt am 17. Februar 2026, mit dokumentierten Nachfassaktionen am 24. Februar, 5. März und 16. April — ohne jegliche Antwort. Der unabhängige Forscher Azraelxuemo meldete dieselbe Schwachstelle im November 2025 und erhielt ebenfalls keine Antwort. Die Zwischenmaßnahme ist eine Netzwerkrestriktion. Es gibt keinen Patch.
5 Wichtige Erkenntnisse
1. ChromaToast ist eine CVSS-10.0-Pre-Auth-RCE, die aktiv ausgenutzt wird.
HiddenLayer veröffentlichte CVE-2026-45829 am 18. Mai 2026. Betroffen sind alle ChromaDB Python FastAPI Server-Versionen ab 1.0.0. Rund 73 % der internetzugänglichen Deployments sind ausnutzbar. Es gibt keinen Patch. Capital One und UnitedHealthcare werden auf Chromas Homepage präsentiert. Dies ist kein Nischen-Tool — es ist Infrastruktur, die RAG im großen Maßstab betreibt, und das Incident Response beginnt ohne Lösungsweg.
2. Der Bug offenbart ein tiefergehendes RAG-Architekturversagen.
ChromaDB verzeichnet 13 Millionen monatliche pip-Downloads und steht hinter produktiven RAG-Pipelines bei Mintlify, Factory AI und Weights & Biases. Ist die Datenbank, die Embeddings, Prompts und abgerufene Dokumente enthält, vor Authentifizierung ausnutzbar, sind alle vom Serverprozess lesbaren Geheimnisse betroffen — API-Schlüssel, Umgebungsvariablen, gemountete Zugangsdaten und alles, was damit verbunden ist. Dies ist keine Schwachstelle auf Anwendungsebene. Es ist eine Schwachstelle in der darunterliegenden Dateninfrastruktur.
3. Schwachstellenausnutzung ist erstmals seit 19 Jahren der führende Angriffsvektor.
Der Verizon DBIR 2026 berichtet, dass 31 % der Datenpannen auf ungepatchte Schwachstellen zurückzuführen sind, gegenüber 13 % durch Missbrauch von Zugangsdaten — erstmals in der Geschichte des Berichts ist Ausnutzung führend. IBM X-Force meldet, dass die Ausnutzung öffentlich erreichbarer Anwendungen um 44 % gegenüber dem Vorjahr gestiegen ist, wobei 56 % der veröffentlichten Schwachstellen keine Authentifizierung zur Ausnutzung benötigen. RAG-Infrastruktur ist unter diesen Bedingungen ein reales Ziel, kein hypothetisches.
4. Die meisten Unternehmen verfügen nicht über eine gesteuerte KI-Datenschicht.
Nur 43 % der Unternehmen betreiben heute ein zentrales AI Data Gateway. 57 % arbeiten mit fragmentierten, teilweisen oder gar keinen Kontrollen. 90 % der Behörden und 77 % der Gesundheitsorganisationen fehlt jegliche Zentralisierung. Die Geschwindigkeit der KI-Einführung überholt die Reife der KI-Governance — und ChromaToast zeigt, wie diese Lücke in der Praxis aussieht.
5. Die architektonische Antwort ist Data Governance, nicht das Patchen der Infrastruktur.
Wenn RAG-Pipelines Unternehmensdaten über ein gesteuertes Gateway mit zero-trust-Zugriff, ABAC-Durchsetzung, FIPS 140-3-Verschlüsselung und manipulationssicherem Audit-Logging erreichen, kann eine Pre-Auth-RCE in einer einzelnen Komponente nicht zu einem Datenabfluss führen. Die Schwachstelle wird zu einem Containment-Problem, nicht zu einem Exfiltrationsproblem.
Sie vertrauen auf die Sicherheit Ihres Unternehmens. Aber können Sie es auch nachweisen?
Jetzt lesen
Warum Pre-Auth-RCE in einer Vektordatenbank ein anderes Problem ist
Pre-Auth-RCE-Schwachstellen kommen vor. Was diese jedoch architektonisch unterscheidet, ist die Position von ChromaDB im KI-Stack. Eine Vektordatenbank in einer RAG-Pipeline befindet sich direkt bei den sensibelsten Inhalten des Systems: Embeddings von Unternehmensdokumenten, abgerufene Chunks als Grundlage für Modellantworten, Prompts mit potenziell regulierten Daten und Applikationsgeheimnissen für den Zugriff auf Upstream-Datenquellen. Wird die Vektordatenbank kompromittiert, betrifft der Schaden die gesamte RAG-Pipeline — Embeddings offenbaren Dokumenteninhalte, gespeicherte Prompts können personenbezogene Daten (PII), Gesundheitsdaten (PHI) oder kontrollierte Informationen (CUI) enthalten, und API-Schlüssel ermöglichen Zugriff auf alles, was mit diesen Schlüsseln erreichbar ist.
Das eigentliche Versagen ist architektonisch. Die Vertrauensannahme im Python-Server von ChromaDB — dass es akzeptabel sei, Modellcode aus einem externen Registry zu laden und auszuführen, bevor geprüft wird, wer anfragt — ist dieselbe Annahme, die heute in den meisten RAG-Deployments gilt. Die Retrieval-Schicht wird als reine Infrastruktur betrachtet, nicht als gesteuerter Zugang zu Unternehmensdaten. Wenn diese Infrastruktur eine Pre-Auth-RCE aufweist, kann Governance, die nur auf Anwendungsebene implementiert ist, nicht kompensieren. KI-Infrastruktur ist Dateninfrastruktur, und dieselben Kontrollen, die regeln, wer einen sensiblen Ordner lesen darf, müssen auch steuern, wer — oder was — einen Embedding-Store abfragen, ein Modell-Artefakt mounten oder ein Tool über eine Agentenlaufzeit aufrufen darf.
Schwachstellenausnutzung ist jetzt der Angriffsvektor, der zählt
Der Verizon DBIR 2026 zeigt, dass Schwachstellenausnutzung erstmals seit 19 Jahren Zugangsdiebstahl überholt hat. Ungepatchte Schwachstellen waren für 31 % der Datenpannen verantwortlich; Missbrauch von Zugangsdaten sank auf 13 %. Unternehmen patchten 2025 nur 26 % der im CISA-Katalog gelisteten Schwachstellen, gegenüber 38 % im Jahr 2024. Die mittlere Zeit bis zum vollständigen Patch stieg von 32 auf 43 Tage. Die Geschwindigkeit der Verteidiger nimmt ab, während die Geschwindigkeit der Angreifer steigt.
Der IBM X-Force 2026 Threat Intelligence Index ergänzt die Dimension der öffentlich erreichbaren Anwendungen: Die Ausnutzung solcher Anwendungen stieg um 44 % gegenüber dem Vorjahr, Schwachstellenausnutzung war für 40 % der beobachteten Vorfälle verantwortlich, und 56 % der veröffentlichten Schwachstellen erforderten keine Authentifizierung. Vektordatenbanken sind öffentlich erreichbare Anwendungen, wenn sie mit einem netzwerkzugänglichen Port selbst gehostet werden — genau dieses Deployment-Muster misst HiddenLayers 73-%-Expositionsrate.
KI-Angreifer sind schneller als Patches
Ein zweiter Trend verstärkt das ChromaToast-Muster zusätzlich zur Schwachstellenausnutzung. Das UK AI Security Institute berichtet, dass sich die Schwierigkeit von Cyber-Aufgaben, die fortschrittliche KI-Modelle bewältigen können, Ende 2025 alle acht Monate und bis Februar 2026 alle 4,7 Monate verdoppelte. Der Stanford AI Index 2026 zeigt, dass die Erfolgsquote auf dem Cybench-Cybersicherheits-Benchmark von 15 % im Jahr 2024 auf 93 % im Jahr 2025 stieg.
Die GTG-1002-Offenlegung von Anthropic im November 2025 macht das Abstrakte konkret: Eine chinesische, staatlich unterstützte Gruppe nutzte Claude Code plus MCP-Tools, um 80–90 % der taktischen Arbeit einer mehrzieligen Cyber-Spionagekampagne gegen etwa 30 Organisationen zu orchestrieren — Aufklärung, Schwachstellenfindung, Ausnutzung, laterale Bewegung, Zugangsdaten-Ernte — alles KI-gesteuert. Vergleichen Sie dies mit der ChromaDB-Disclosure-Timeline: HiddenLayer kontaktierte Chroma erstmals am 17. Februar 2026, folgte bis April dreimal nach und erhielt keine Antwort. Die Schwachstelle ist öffentlich, die Proof-of-Concept-Logik dokumentiert, ein Patch existiert nicht. Die Uhr der Verteidiger steht still. Die Uhr der Angreifer misst jetzt in Rechenzyklen.
Wo Unternehmen bei KI Data Governance stehen
Nur 43 % der Unternehmen betreiben ein zentrales AI Data Gateway. 27 % setzen auf verteilte Kontrollen mit Richtlinien. 19 % verfügen über teilweise oder Ad-hoc-Kontrollen. 7 % haben keinerlei dedizierte KI-Kontrollen. Im öffentlichen Sektor sind 90 %, im Gesundheitswesen 77 % und im Finanzsektor 60 % ohne Zentralisierung. Diese Zahlen beschreiben die exponierte Population im ChromaToast-Muster. Ein Unternehmen mit zentralem Gateway hat einen architektonischen Punkt, an dem Authentifizierung, Autorisierung, Verschlüsselung und Audit für jede KI-Dateninteraktion durchgesetzt werden. Unternehmen mit teilweisen oder keinen Kontrollen haben eine Vielzahl einzelner Vektordatenbanken, Embedding-Stores und Agentenlaufzeiten — jede davon ist eine Pre-Auth-Angriffsfläche, die entdeckt werden kann.
Die architektonische Antwort: Die Datenschicht steuern, nicht einzelne Komponenten patchen
Die architektonische Alternative ist, KI-Datenzugriff wie seit Jahren in der Unternehmenssicherheit zu behandeln: zero trust auf der Datenschicht, jede Anfrage authentifiziert, richtlinienbasiert autorisiert und unabhängig vom anfragenden System auditiert.
Der Kiteworks Secure MCP Server und das AI Data Gateway setzen dieses Muster um. RAG-Pipelines greifen über eine gesteuerte Brücke auf Unternehmensdaten zu. KI-Assistenten erreichen Dateien über das Model Context Protocol mit OAuth 2.0-Authentifizierung — Tokens im OS-Schlüsselbund, nie im Modell. ABAC-Richtlinien prüfen jede Operation in Echtzeit. Rate Limiting verhindert Massenausleitung selbst bei kompromittierten Upstream-Komponenten. FIPS 140-3-validierte Verschlüsselung, TLS-Validierung und eine gehärtete virtuelle Appliance sichern den gesamten Pfad. Jede Interaktion wird in Echtzeit manipulationssicher an SIEM protokolliert.
Der architektonische Test ist einfach: Wird die Vektordatenbank morgen kompromittiert, wie groß ist der Schaden? In einer Gateway-Architektur begrenzt die ABAC-Richtlinie den Radius, nicht die von der kompromittierten Komponente gehaltenen Zugangsdaten. Das Kiteworks Private Data Network erweitert dies auf E-Mail, Filesharing, Managed File Transfer, SFTP, Web-Formulare, APIs und KI-Integrationen unter einer Policy Engine und einem konsolidierten Audit-Log.
Was Security-Verantwortliche dieses Quartal tun sollten
Erstens: Erfassen Sie jede Vektordatenbank, jeden Embedding-Store und jede Agentenlaufzeit, die Unternehmensdaten berühren. Dokumentieren Sie das Authentifizierungsmodell, die Netzwerkanbindung und die erreichbaren Zugangsdaten jeder Komponente. Die meisten Security-Teams haben kein vollständiges Bild, da KI-Infrastruktur oft von Data-Science-Teams ohne CMDB-Eintrag aufgebaut wurde.
Zweitens: Behandeln Sie KI-Infrastruktur wie Produktionsinfrastruktur im Schwachstellenmanagement. Wenden Sie dieselben Patch-SLAs, Disziplin im Exposure Management und KEV-basierte Priorisierung an. Die DBIR 2026 zeigt: Nur 26 % der KEV-gelisteten Schwachstellen wurden gepatcht — dies gilt für KI-Komponenten genauso wie für klassische Infrastruktur.
Drittens: Führen Sie RAG- und Agenten-Datenzugriff über ein gesteuertes AI Data Gateway. Nur 43 % der Unternehmen haben dies umgesetzt. Die übrigen 57 % stehen vor dem ChromaToast-Muster, multipliziert mit jeder KI-Workload. Zentralisierung auf der Datenschicht reduziert Dutzende Komponenten-Angriffsflächen auf eine gesteuerte Kontroll-Ebene.
Viertens: Verlangen Sie zero-trust-Datenzugriff für KI-Agenten wie für menschliche Anwender. Jede KI-Datenanfrage muss authentifiziert, richtlinienbasiert autorisiert, rate-limitiert, verschlüsselt und mit voller Attribution protokolliert werden. Der Stanford AI Index 2026 zeigt: Sicherheits- und Risikobedenken sind das größte Hindernis für skalierbare agentische KI, genannt von 62 % der Unternehmen — zero-trust-Datenzugriff ist die steuerbare Variable.
Fünftens: Instrumentieren Sie die KI-Datenschicht für SIEM-Transparenz. Eine Pre-Auth-RCE erzeugt definitionsgemäß keine Authentifizierungs-Logs. Die Transparenz muss upstream kommen — vom Gateway, das jede Dateninteraktion vermittelt. Echtzeit-SIEM-Feeds zu KI-Datenzugriff sind die forensische Grundlage, wenn die nächste ChromaToast-ähnliche Schwachstelle publik wird.
Erfahren Sie mehr darüber, wie Sie Ihre sensiblen Daten vor KI-basierten Bedrohungen schützen: Vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Beschränken Sie den Netzwerkzugriff ausschließlich auf vertrauenswürdige Mandanten und betrachten Sie jede exponierte Instanz bis zur Klärung als potenziell kompromittiert. Rotieren Sie alle Geheimnisse, die der Serverprozess lesen konnte — API-Schlüssel, gemountete Zugangsdaten, Umgebungsvariablen. Verschieben Sie den RAG-Datenzugriff langfristig hinter ein gesteuertes AI Data Gateway; Netzwerkrestriktion ist nur eine Sofortmaßnahme, keine Architektur.
Erheblich exponiert, wenn eine RAG-Komponente internetzugänglich und unreguliert ist. 77 % der Gesundheitsorganisationen verfügen laut Kiteworks Prognose 2026 über kein zentrales AI Data Gateway und 14 % haben keinerlei dedizierte KI-Kontrollen. Die HIPAA Security Rule verlangt Zugriffskontrollen und Audit-Trails, die unregulierte RAG-Komponenten nicht liefern können. Eine Pre-Auth-RCE auf einer Komponente mit PHI-Embeddings ist ein meldepflichtiges Ereignis.
Pre-Auth-RCE in einer KI-Komponente mit CUI ist ein meldepflichtiges Ereignis nach CMMC und DFARS. 90 % der Behörden verfügen laut Kiteworks Prognose 2026 über kein zentrales AI Data Gateway. Die CMMC-Kontrollfamilien AC, AU und IA verlangen durchgesetzte Autorisierung und Audit-Logging für jeden Datenzugriff, auch durch KI-Komponenten. Data-Layer-Governance mit ABAC und manipulationssicheren Logs erfüllt alle drei Anforderungen gleichzeitig.
Patching behebt eine Schwachstelle in einer Komponente. Governance von KI-Datenzugriff legt fest, wer oder was überhaupt auf Unternehmensdaten zugreifen darf, unabhängig davon, welche nachgelagerte Komponente kompromittiert ist. Zentrale Gateways werden zum architektonischen Standard, weil Patching mit der Entdeckung neuer Schwachstellen in KI-Infrastruktur nicht Schritt halten kann — die ChromaToast-Disclosure-Timeline (Monate ohne Reaktion, kein Patch) zeigt, warum.
Ja — es ist die personal-effiziente Lösung. Eine gesteuerte Kontroll-Ebene ersetzt Dutzende Komponenten-Kontrollen. Der Kiteworks Secure MCP Server und das AI Data Gateway bieten diesen zentralen Enforcement Point — kleine Security-Teams profitieren mehr von einer architektonischen Kontrolle als vom Patchen jeder einzelnen Vektordatenbank, jedes Embedding-Stores und jeder Agentenlaufzeit.
Weitere Ressourcen
- Blog Post
Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz - Blog Post
Wie 77 % der Unternehmen bei KI-Datensicherheit versagen - eBook
AI Governance Gap: Warum 91 % kleiner Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blog Post
Für Ihre Daten gibt es kein „–dangerously-skip-permissions“ - Blog Post
Regulierungsbehörden fragen nicht mehr nach einer KI-Policy. Sie wollen den Nachweis, dass sie funktioniert.