Eine wilde Woche in der IT-Sicherheit: Warum unser EU-KI-Chat vor den jüngsten Vorfällen sicher blieb

tl;dr: Diese dritte Oktoberwoche 2026 hat eine außergewöhnliche Welle an Sicherheitsvorfällen durch die Tech-Welt gejagt, aber DentroChat und deine Daten sind sicher.

Wenn du Security-News verfolgst, fühlt sich diese Woche wie eine Sturzflut an. Kleine Warnmeldungen gibt es ständig, aber dass so viele Basis-Tools und Cloud-Plattformen innerhalb weniger Tage getroffen werden, ist, man muss es einfach so sagen, WILD.

In weniger als einer Woche kam all das zusammen:

• Der Vorfall rund um die Zertifizierungsstelle eMudhra: Bei 8 Zwischenzertifikaten (Intermediate CAs) unter eMudhras Root-Zertifikat emSign wurden extrem schwache private Schlüssel entdeckt. Weil sich diese Schlüssel zurückrechnen ließen, um HTTPS-Verbindungen abzufangen, mussten die großen Browser die Zertifikate sperren, eMudhra hat heute angekündigt, sich komplett aus dem globalen SSL/TLS-Zertifikatsgeschäft zurückzuziehen (!), und für uv, pip, Node.js, Bun, Go und Rust (!) mussten Eil-Updates veröffentlicht werden, um die kompromittierte CA aus den mitgelieferten Trust-Stores zu werfen.
• Kritische CVEs in zentraler Internet-Software: In PHP wurden zwei unauthentifizierte Remote-Code-Execution-Lücken gepatcht (CVE-2026-109618 und CVE-2026-109619), dazu kamen ein kritischer Buffer Overflow in Google Brotli (CVE-2026-111497), eine unauthentifizierte RCE der höchsten Warnstufe in GitLab (CVE-2026-110264) und die Linux-Kernel-Lücke „PwnEscape“ (CVE-2026-99999).
• Die Supply-Chain-Kompromittierung bei LiteLLM: Gestern, am 21. Oktober, haben Angreifer (schon wieder) die Release-Pipeline von LiteLLM gekapert und eine manipulierte Version (v1.107.0) auf PyPI und Docker Hub veröffentlicht. Weil das schadhafte Paket einen Startup-Hook enthielt, der bei jedem Python-Start automatisch mitlief, wurden auf betroffenen Servern sofort Cloud-Zugangsdaten und API-Keys abgegriffen.
• Plattform-Einbrüche bei Railway und Zeabur: Zeabur hat angekündigt, den Betrieb dauerhaft einzustellen, nachdem ein zweiter Vorfall 3,2 Millionen Einträge mit Umgebungsvariablen von 321.000 Nutzerkonten offengelegt hat. Gestern teilte außerdem Railway mit, dass Angreifer auf Umgebungsvariablen von Kunden zugreifen und sie entschlüsseln konnten. Das Ziel waren interessanterweise vor allem KI-Inferenz-Keys.
• Große Enterprise-Angriffe: Über gestohlene Backup-Zugangsdaten von ConnectWise (SkyKick) verschafften sich Angreifer Zugriff auf Microsoft-365-Mandanten, und bei Capcom waren 11,7 Millionen Nutzerkonten von einem Datenleck betroffen.

Ist das eine „Cyberpocalypse“ oder wacht das Immunsystem des Internets gerade auf?

Warum tauchen plötzlich gleichzeitig so viele alte Fehler in Regex-Compilern, Kompressions-Decodern, Speicherverwaltungen und Krypto-Setups auf?

Die Antwort ist vor allem, dass KI inzwischen den Code der Welt liest. Sicherheitsforscher und Verteidiger (genauso wie Angreifer) lassen KI den Quellcode von Open-Source-Bibliotheken durchkämmen. Dadurch fallen haufenweise Randfälle auf, die menschliche Reviewer 15 Jahre lang übersehen haben. Selbst die schwachen CA-Schlüssel bei eMudhra wurden offenbar mit KI-Hilfe entdeckt.

Manche Kommentatoren nennen diese Woche schon eine „Cyberpocalypse“. Wir sehen das anders: Das Immunsystem des Internets wacht endlich auf und heilt sich selbst. Die meisten dieser Bugs schlummerten schon seit Jahren im Produktivcode, und erst wenn man sie findet, werden sie endlich behoben.

Weil ich vor all den Jahren meine Bachelorarbeit an der TU Graz über das Vertrauensmodell und die strukturellen Risiken von Zertifizierungsstellen geschrieben habe, hat mich die eMudhra-Kaskade bis hinein in uv, pip, Node.js und Bun sofort daran erinnert, warum mich das Thema damals so fasziniert hat. Vertrauen im Internet hat viele Gesichter und ist ein hochkomplexes System.

Wo DentroChat bei den Vorfällen dieser Woche steht

Wenn du DentroChat für deine tägliche Arbeit und vertrauliche Dokumente nutzt, waren deine Chats und Dateien von keinem dieser Vorfälle betroffen. Weil wir unsere Architektur bewusst schlank halten, kommt der Großteil der betroffenen Software bei uns gar nicht vor, und was wir nutzen, haben wir sofort aktualisiert:

• Das CA-Vertrauensproblem bei uv, pip, Node.js und Bun: Weil Kommandozeilen-Tools und Laufzeitumgebungen ihre eigene Liste vertrauenswürdiger Zertifizierungsstellen mitbringen, musste jedes Tool aktualisiert werden, das dem kompromittierten eMudhra-Root-Zertifikat vertraut hat. DentroChat nutzt auf seinen Servern weder uv noch pip. Unsere Webanwendung läuft allerdings auf Bun, deshalb haben wir unsere Produktiv-Container auf Bun 1.4.4 (zusammen mit aktualisierten Debian-Systemzertifikaten) gehoben, womit das kompromittierte eMudhra-Root restlos entfernt ist.
• LiteLLM (v1.107.0-Malware): Wir leiten KI-Anfragen zwar über ein europäisches Inferenz-Gateway (Cortecs), setzen aber nirgendwo in unserem Stack die Python-Bibliothek LiteLLM oder deren Docker-Images ein.
• Railway, Zeabur und Cloud-Deployment-Plattformen: Wir hosten nicht auf Multi-Tenant-PaaS-Plattformen wie Railway oder Zeabur und speichern auch keine Kundendaten bei US-Hyperscalern oder in Microsoft-Cloud-Tenants. Wie auf unserer Seite zu den Auftragsverarbeitern dokumentiert, verwalten wir unsere Deployments über unsere eigene, selbst gehostete Coolify-Instanz, die direkt auf unseren europäischen Servern läuft. Dadurch liegen unsere Umgebungsvariablen und Deployment-Secrets bei keinem externen PaaS-Anbieter.
• PHP, GitLab und Anwendungs-Abhängigkeiten: Wir betreiben weder PHP noch ein selbst gehostetes GitLab. Außerdem haben wir den gesamten Abhängigkeitsbaum unserer Chat-Plattform und unserer Website geprüft, aktualisiert und stehen aktuell bei null bekannten Schwachstellen.

Wie wir DentroChat aufbauen, damit deine Daten sicher bleiben

Weil KI-gestützte Code-Audits auch künftig neue CVEs in Open-Source-Software zutage fördern werden, wird Drittanbieter-Code nie völlig „fehlerfrei“ sein. Deshalb haben wir DentroChat mit strikter Isolation gebaut, sodass ein Fehler in einem Baustein weder deine Daten noch unsere Server gefährden kann.

1. Code-Ausführung in einer WebAssembly-Sandbox ohne Netzwerk

Dieses Jahr sorgte ein Sicherheitsbericht für Aufsehen, laut dem OpenAI-Agenten aus ihrer Sandbox ausgebrochen sind, während sie intern getestet wurden. Möglich war dieser Ausbruch, weil die Agenten in einem Linux-Container liefen, der noch Netzwerkzugriff auf einen internen Paket-Proxy hatte, und der Agent eine Zero-Day-Lücke in diesem Proxy ausnutzte, um ins Internet zu gelangen.

Bei DentroChat existiert dieser Angriffsweg (Stand heute) nicht, weil wir Nutzercode nicht in einem Linux-Container mit Shell oder Paket-Installer ausführen. Wenn du eine Tabelle hochlädst oder DentroChat bittest, eine Python-Analyse zu starten, läuft der Code stattdessen in einer isolierten WebAssembly-(WASM)-Sandbox:

• Jede unterstützte Python-Bibliothek für Datenanalyse und Dokumentenerstellung wird schon zur Build-Zeit fest eingebunden, sodass zur Laufzeit niemals etwas von PyPI oder einem internen Paket-Proxy nachgeladen wird.
• Bevor überhaupt Python-Code startet, werden sämtliche ausgehenden Netzwerk-APIs, dynamischen Library-Loader und Brücken zum Host-Dateisystem gekappt und aus der Laufzeitumgebung entfernt.
• Selbst wenn eine Python-Bibliothek jemals eine Supply-Chain-Hintertür wie das Startskript von LiteLLM enthalten sollte, hat die WebAssembly-Sandbox weder eine Netzwerkverbindung, um Daten nach außen zu senden, noch Zugriff auf Server-Umgebungsvariablen oder Dateien anderer Nutzer. Sobald dein Diagramm oder Dokument fertig ist, wird der temporäre Arbeitsbereich wieder komplett geleert.

2. 7 Tage Abkühlphase gegen Supply-Chain-Angriffe

Der LiteLLM-Angriff hat so funktioniert:

1. Die manipulierte Paketversion wird auf PyPI veröffentlicht
2. Automatisierte Build-Pipelines auf der ganzen Welt installieren sie sofort
3. Nach 2 Stunden merken Sicherheitsforscher, dass etwas faul ist
4. Bis dahin konnte der Schadcode aber schon viele Systeme kompromittieren

Um solche „Supply-Chain-Angriffe“ abzufangen, erzwingt unser Paketmanager neben eingefrorenen Lockfiles ein striktes Mindestalter von 7 Tagen für neue Releases. Eine frisch veröffentlichte Open-Source-Version muss erst eine volle Woche öffentlicher Prüfung überstehen, bevor unsere Build-Pipeline sie überhaupt installiert. Es sei denn natürlich, wir prüfen und pinnen ein dringendes Sicherheits-Update wie das heutige Runtime-Update gezielt von Hand…

3. Warum wir Zugriffe aufs interne Netzwerk blockieren, wenn die KI Websites liest

Wenn du DentroChat bittest, eine Webseite zu lesen oder einen öffentlichen Datensatz von einer Open-Data-API abzurufen, ruft unser Server diese URL in deinem Auftrag ab. Ohne strikte Netzwerkgrenzen könnte eine präparierte Webseite versteckte Anweisungen enthalten, die die KI dazu bringen, interne Serveradressen (wie 127.0.0.1 oder interne Docker-Ports) statt einer öffentlichen Website abzufragen. Diesen Trick nennt man Server-Side Request Forgery (SSRF), und er könnte interne Dienste auf dem Server selbst offenlegen.

Deshalb löst unser ausgehender Netzwerk-Fetcher DNS auf, bevor er sich verbindet, blockiert sämtliche privaten, Loopback- und internen IP-Bereiche und pinnt die geprüfte IP-Adresse bei jeder Weiterleitung. Selbst wenn eine Webseite versucht, das Modell auszutricksen, oder per DNS-Rebinding die IP-Adresse einer Domain in der letzten Millisekunde auf 127.0.0.1 umbiegt, wird die Verbindung abgewiesen, bevor sie unser internes Netz berührt.

4. Selbst verwaltete Verschlüsselung im Ruhezustand bei Hetzner in Europa

Alle DentroChat-Anwendungsserver, Datenbanken und selbst gehosteten Tools laufen bei Hetzner in Deutschland, während verschlüsselte Backups und pseudonymisierte Server-Logs bei Scaleway in Frankreich liegen, alles unter EU-Recht und außerhalb des US CLOUD Act. Unser komplettes Infrastruktur-Setup kannst du jederzeit auf unserer Seite zu den Auftragsverarbeitern einsehen.

Alle Daten sind durch Verschlüsselung bei der Übertragung und Verschlüsselung im Ruhezustand (Encryption at Rest) geschützt. Ein technisches Detail, das oft übersehen wird: Bei den meisten Hosting-Anbietern (auch bei Hetzner) sind Server-Festplatten im Ruhezustand standardmäßig überhaupt nicht verschlüsselt. Deshalb richten wir die Verschlüsselung im Ruhezustand selbst ein und verwalten sie eigenständig. Dieses sichere Infrastruktur-Setup greift nahtlos mit unseren Datenschutz-Funktionen ineinander:

• Kein Training mit deinen Chats oder Dateien
• Automatische Chat-Löschung, die du selbst steuerst
• Diskreter Chat-Modus, wenn ein Gespräch nicht im KI-Gedächtnis landen soll

Wachsam bleiben

Gute Sicherheit ist nie fertig.

Erst recht nicht jetzt, wo sowohl Forscher als auch Angreifer mit KI schneller denn je Zero-Day-Lücken finden. Auch wenn wir froh sind, dass unsere Architektur DentroChat komplett vor der Vorfallswelle dieser Woche geschützt hat, bleiben wir wachsam.

Wir prüfen gerade aktiv, wie wir unsere Reaktionszeit auf künftige Zero-Day-Exploits noch weiter verkürzen, unsere Servergrenzen noch stärker absichern und deine Daten schützen können, egal wie verrückt die nächste Woche in der IT-Sicherheit wird. Danke, dass du bei DentroChat dabei bist!