DEF CON 34: Eine Pyodide-Schwachstelle gefährdete sieben Produkte

Da KI-Agenten und Automatisierungsplattformen zunehmend von Modellen oder Nutzern erzeugten Code ausführen, sind die Sicherheitsgrenzen rund um diesen Code entscheidend geworden. 

Eine von den Cyera-Forschern Vladimir Tokarev und Saar Pearl auf der DEF CON 34 vorgestellte Forschung ergab, dass sieben Produkte, die Pyodide einsetzen, auf Einschränkungen auf Python-Ebene vertrauten, die nicht für eine vollständige Isolierung nicht vertrauenswürdigen Codes von der zugrunde liegenden Host-Umgebung sorgten.

Zentrale Erkenntnisse der Cyera-Forschung

• Die Forscher identifizierten bei sieben Produkten Ausbrüche aus der Pyodide-Sandbox und stellten fest, dass Einschränkungen auf Python-Ebene nicht für eine vollständige Isolierung nicht vertrauenswürdigen Codes von der zugrunde liegenden Host-Umgebung sorgten.
• Die Forschung führte zu vier CVEs mit Bewertungen zwischen 8,3 und 9,9, darunter eine kritische n8n-Schwachstelle, durch die möglicherweise Zugangsdaten für verbundene Integrationen offengelegt werden konnten.
• Die Host-Umgebung bestimmt die potenziellen Auswirkungen eines Ausbruchs aus der Sandbox und bringt dadurch API-Zugangsdaten, Quellcode, Signaturschlüssel, interne Dienste, Datenbanken und andere sensible Ressourcen in Gefahr.
• Organisationen sollten bei der Ausführung nicht vertrauenswürdigen Codes auf mehrschichtige Sicherheitskontrollen setzen, darunter unabhängige Isolierung, Zugriffe nach dem Prinzip der geringsten Rechte, Netzwerkbeschränkungen, kurzlebige Zugangsdaten, Überwachung und regelmäßige Tests der Incident-Response-Fähigkeiten.

Warum die Sicherheit der Pyodide-Sandbox für KI-Anwendungen wichtig ist

Pyodide führt CPython in WebAssembly (WASM) aus und ermöglicht es Anwendungen, Python in JavaScript-Umgebungen wie Browsern, Node.js und Deno auszuführen. 

Produktentwickler können potenziell gefährliche Python-Module wie os und subprocess einschränken und so eine Sandbox für die Ausführung nicht vertrauenswürdigen Codes schaffen.

Die Forscher stellten jedoch fest, dass die Einschränkungen in allen sieben getesteten Produkten weder das Python-Modul ctypes noch von Emscripten exportierte Funktionen berücksichtigten. 

Dadurch entstand ein Pfad von vermeintlich eingeschränktem Python-Code in die JavaScript-Host-Laufzeitumgebung. 

Die Offenlegungen führten zu vier CVEs mit Schweregraden zwischen 8,3 und 9,9.

Das grundlegende Problem war architektonischer Natur und nicht auf eine einzelne Anwendung beschränkt. 

WASM schützt seinen eigenen linearen Speicher, verhindert aber nicht, dass Software auf Fähigkeiten zugreift, die die einbettende Umgebung absichtlich zur Verfügung stellt. 

In den getesteten Konfigurationen blieb ctypes verfügbar und konnte relevante Emscripten-Funktionen auflösen.

Sieben von Pyodide-Schwachstellen in der Sandbox betroffene Produkte

Die Forscher reproduzierten entsprechende Ausbrüche aus der Sandbox in Workflow-Automatisierung, Tabellenkalkulationen, Laufzeitumgebungen für KI-Agenten, Desktop-Anwendungen sowie Tools für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD).

Zu den schwerwiegendsten Funden gehörte CVE-2025-68668, bewertet mit 9,9, die n8n betraf. 

Der Code-Knoten ermöglichte die Ausführung von Python über Pyodide auf Node.js. 

Die Umgehung konnte Angreifern Zugriff auf den n8n-Dienstprozess und möglicherweise auf Zugangsdaten für verbundene Integrationen ermöglichen. 

Als Reaktion darauf verlagerte n8n die Ausführung von Python-Code in einen externen Runner und isolierte sie dadurch zusätzlich vom Kerndienst.

Grist, eine Open-Source-Plattform für Tabellenkalkulationen und Datenbanken, die Python-basierte Formeln unterstützt, war von CVE-2026-24002 betroffen. Die Schwachstelle erhielt einen CVSS-Wert von 9,1. 

Coheres Terrarium, eine Sandbox-Umgebung für die Ausführung von KI-generiertem Code, war von CVE-2026-61522 betroffen, die einen CVSS-Wert von 9,3 aufweist. 

Auch Hugging Faces smolagents, ein Framework zum Erstellen von KI-Agenten, die Code ausführen und externe Tools verwenden können, war von CVE-2026-10613 betroffen und erhielt einen CVSS-Wert von 8,3.

Die Forschung identifizierte außerdem Sicherheitsbedenken im Zusammenhang mit langchain-sandbox, stlite und cibuildwheel. 

Die Reaktionen der Maintainer unterschieden sich je nach Projekt: Einige nahmen architektonische Änderungen vor, andere archivierten betroffene Komponenten, während manche darauf beharrten, dass die ordnungsgemäße Isolierung auf Bereitstellungsebene durchgesetzt werden müsse.

Wie Host-Laufzeitumgebungen die Sicherheitsrisiken der Pyodide-Sandbox erhöhen

Der Ausbruch aus Pyodide war nur ein Teil der Sicherheitsgleichung. Die Forscher betonten, dass die Host-Laufzeitumgebung und die umgebende Umgebung die potenziellen Auswirkungen bestimmen.

So können Node[.]js-Prozesse beispielsweise APIs für Dateisystem, Prozesse und Umgebungsvariablen offenlegen. 

Deno verwendet explizite Berechtigungen, die Fähigkeiten wie den Zugriff auf Dateisystem, Netzwerk und Subprozesse begrenzen können. 

In CI/CD-Umgebungen könnte ein Ausbruch aus der Sandbox sensible Ressourcen wie Veröffentlichungstoken, Signaturschlüssel, proprietären Quellcode und Release-Artefakte offenlegen. 

Umgebungen für KI-Agenten bergen ähnliche Risiken und könnten Angreifern Zugriff auf API-Zugangsdaten, interne Dienste, Datenbanken, verbundene Tools und sensible Kundendaten verschaffen.

So sichern Sie Pyodide mit mehrschichtigen Sicherheitskontrollen ab

Die Ergebnisse zeigen, warum Organisationen Einschränkungen von Python-Imports nicht als vollständige Sicherheitsgrenze betrachten sollten. 

Produktteams sollten unnötige ctypes-Funktionen einschränken, Modul-Allowlists bevorzugen, unnötige Emscripten-Exporte entfernen und die Berechtigungen der Host-Laufzeitumgebung minimieren. 

Nicht vertrauenswürdiger Code sollte außerdem hinter einer unabhängigen Isolierungsgrenze ausgeführt werden, etwa in einem separaten Prozess oder Container.

Organisationen, die betroffene Frameworks einsetzen, sollten auf gepatchte Versionen aktualisieren oder die vom Anbieter empfohlenen Maßnahmen zur Risikominderung anwenden. 

Über die Behebung einzelner Schwachstellen hinaus sollten Teams mehrschichtige Sicherheitskontrollen einführen, die darauf ausgelegt sind, den Zugriff eines Angreifers zu begrenzen, falls die Sandbox umgangen wird.

• Zugriffe nach dem Prinzip der geringsten Rechte durchsetzen – mit dedizierten Dienstkonten und eng gefassten Berechtigungen für Workloads, die nicht vertrauenswürdigen Code ausführen.
• Beschränken Sie den ausgehenden Netzwerkzugriff , um zu verhindern, dass kompromittierte Workloads unnötige interne Dienste erreichen oder sensible Daten exfiltrieren.
• Kurzlebige, workloadspezifische Zugangsdaten verwenden und vermeiden, langlebige Geheimnisse Sandbox-Umgebungen zugänglich zu machen.
• Sensible CI/CD-Funktionen und Zugangsdaten trennen, darunter Build-, Signier-, Veröffentlichungs- und Produktionszugriffe, um die Auswirkungen einer kompromittierten Pipeline-Phase zu begrenzen.
• Dateisystem- und Hostzugriff beschränken – mit schreibgeschützten Einbindungen, minimalen Host-Berechtigungen und Zugriff ausschließlich auf die vom Workload benötigten Ressourcen.
• Ephemere Container oder isolierte Prozesse verwenden für nicht vertrauenswürdige Workloads, damit Umgebungen nach der Ausführung verworfen werden können, anstatt dauerhaften Zugriff oder Zustand beizubehalten.
• Sandbox-Workloads auf verdächtiges Verhalten überwachen, einschließlich unerwarteter Prozesserstellung, Netzwerkverbindungen, Dateizugriffe und Versuche einer Rechteausweitung.
• Testen Sie regelmäßig Szenarien für Sandbox-Ausbrüche und Incident Response mit Tools zur Angriffssimulation , um zu überprüfen, ob Teams kompromittierte Workloads eindämmen, Zugriffe entziehen und offengelegte Zugangsdaten schnell austauschen können.

Die Kombination dieser Kontrollen kann sowohl die Wahrscheinlichkeit eines erfolgreichen Ausbruchs aus der Sandbox als auch den potenziellen Schadensradius verringern, wenn ein Isolierungsmechanismus versagt.

Das Wichtigste in Kürze

Die Forschung verdeutlicht eine umfassendere Lehre für die KI-Sicherheit: Eine Sandbox ist nur so sicher wie die Grenzen, auf denen sie aufbaut. 

Da KI-Systeme zunehmend weitreichende Befugnisse erhalten, Code auszuführen und mit sensiblen Ressourcen zu interagieren, müssen Organisationen nicht nur absichern, welche Funktionen Code innerhalb eines Interpreters aufrufen kann, sondern auch, worauf er zugreifen kann, wenn diese Grenze auf Interpretereebene versagt.

Eine Zero-Trust-Architektur kann dazu beitragen, diese Grenzen zu stärken, indem sie Zugriffe kontinuierlich überprüft, das Prinzip der geringsten Rechte durchsetzt und beschränkt, worauf kompromittierte KI-Workloads in der gesamten Umgebung zugreifen können.