Terrarium-Sandbox-Lücke bedroht KI-Container-Sicherheit

7 Min. Lesezeit · Stand: 23.04.2026

Am 14. April 2026 wurde CVE-2026-5752 öffentlich, ein Sandbox-Escape im Open-Source-Projekt Terrarium. CERT/CC hat die Lücke am 22. April mit einer detaillierten Analyse versehen, CVSS 9.3, Root-Code-Execution im Sandbox-Container. Der Anbieter hinter Terrarium ist Cohere AI, nicht Cloudflare. Wer in den letzten Tagen den Hersteller verwechselt hat, sollte die eigenen Mitigations-Notizen korrigieren. Edge-Workers-Teams, MSPs mit Code-Execution-Pfaden in LLM-Anwendungen und alle Betreiber, die Terrarium für Container-basierte Sandbox-Logik einsetzen, brauchen jetzt eine Sofort-Reaktion in 72 Stunden.

Das Wichtigste in Kürze

CVE-2026-5752 betrifft das Open-Source-Projekt Terrarium von Cohere AI, nicht von Cloudflare.
CVSS 9.3, Root-Code-Execution im Sandbox-Container, potenzieller Container-Escape, CERT/CC-Advisory VU#414811.
Der Bug entsteht durch eine Schwäche in der JavaScript-Prototype-Chain-Isolation des Sandbox-Layers.
CERT/CC konnte zur Veröffentlichung keine koordinierte Patch-Bereitstellung mit dem Anbieter erreichen, Mitigation liegt aktuell bei Betreibern.
Edge-Workers-Teams, MSPs und LLM-Plattformen mit Code-Execution-Pfaden brauchen einen 72-Stunden-Inventar-Sweep mit IMDS-Lockdown und Egress-Hardening.

Faktencheck-Korrektur und tatsächlicher Vorfall

Was ist Terrarium? Terrarium ist eine Open-Source-Sandbox von Cohere AI, ausgeliefert als Docker-Container. Sie führt untrusted Code aus, häufig Python- oder JavaScript-Snippets von Nutzern oder von Large Language Models. Cohere AI ist der Anbieter, nicht Cloudflare. Die Verwechslung tritt in einigen Sekundärberichten auf, weil der Cloudflare-Workers-Stack eine eigene Sandbox-Architektur hat. Wer beide Stacks parallel betreibt, sollte die Begriffe sauber halten.

Der Bug selbst wurde am 14. April 2026 öffentlich, mit weiterer Detail-Analyse durch CERT/CC unter dem Eintrag VU#414811 am 22. April. Die Lücke liegt in der JavaScript-Prototype-Chain. Ein in die Sandbox geladener Code kann über das Prototype-Property des Function-Konstruktors auf das globale Objekt zugreifen. Das Mock-Document-Objekt in Terrarium wird als Standard-JavaScript-Objektliteral erzeugt und erbt damit Properties aus Object.prototype. Diese Erbe-Mechanik erlaubt Sandbox-Code, sich bis zu globalThis hochzuhangeln und Root im Container zu erreichen.

Die Praxisfolgen sind ernst. Ein erfolgreicher Exploit liefert Root im Container, liest oder schreibt /etc/passwd und SSH-Schlüssel, liest Umgebungsvariablen mit kurzlebigen API-Keys und erreicht Nachbar-Services im Container-Netzwerk. Je nach Konfiguration sind Container-Escape-Pfade auf den Host wahrscheinlich. Besonders heikel ist die Kombination mit kurzlebigen Anmeldedaten in Environment-Variablen, die ein Angreifer in Sekunden extrahiert, bevor Detection-Pipelines reagieren.

CVSS 9.3

Sandbox-Escape mit Root-Code-Execution im Container

14. April

CVE-2026-5752 öffentlich, CERT/CC-Detail am 22. April

VU#414811

CERT/CC-Advisory mit technischer Analyse

Wer im Haus betroffen ist und was Soforthandlung bedeutet

Drei Klassen von Anwendungen verdienen die schnellste Reaktion. Die erste sind LLM-Anwendungen mit eingebautem Code-Interpreter. Wer eine Chat-Anwendung mit Python-Ausführung betreibt, hat fast sicher eine Sandbox-Schicht im Stack. Wenn diese Schicht Terrarium ist, sollte der Patch oder die Mitigation in 24 Stunden in Produktion sein. Eine Inventur per SBOM-Scan oder Container-Image-Audit klärt das in wenigen Stunden.

Die zweite Klasse sind Enterprise-Edge-Stacks, in denen Terrarium als Komponente in größeren Plattformen mitläuft. Hier ist die Verbreitung schwieriger zu erkennen, weil Terrarium oft tiefer in Container-Images verbaut ist. SBOM-Tools wie Trivy, Grype oder Snyk liefern in der Regel verlässliche Treffer, sofern die SBOMs aktuell sind. Wer keine SBOM-Disziplin hat, verliert in solchen Wellen wertvolle Reaktionszeit.

Die dritte Klasse sind Multi-Tenant-Anwendungen, die Code-Execution für Endkunden anbieten. Hier ist die Lücke besonders kritisch, weil ein Angreifer mit Root-Zugriff im Sandbox-Container potenziell Zugriff auf andere Tenant-Daten erlangen kann. Multi-Tenant-Betreiber sollten parallel zur Mitigation eine forensische Auswertung der letzten 30 Tage fahren und Kunden aktiv informieren, sobald die Mitigation greift.

Was Security-Operations sofort tun

SBOM-Suche nach Terrarium-Komponenten in eigenen Container-Images
IMDS-Lockdown auf Cloud-Plattform-Ebene erzwingen
Egress-Allowlist für Sandbox-Container enger ziehen
Berechtigungen prüfen, kurzlebige Tokens statt Env-Variablen einsetzen

Was nicht ausreicht

Reine WAF-Regeln vor der Anwendung ohne Container-Härtung
Vertrauen auf „wir sind nicht produktiv“ ohne SBOM-Beleg
Container-Restart ohne Image-Rebuild und Re-Deploy
Patch ohne Re-Deployment in allen aktiven Cluster-Knoten

Ein 72-Stunden-Reaktionsplan für Edge- und Plattform-Teams

Drei Tage reichen für die initiale Reaktion auf den Vorfall. Die Mechanik ist eng verwandt mit der ASP.NET-Core-Reaktion vom selben Wochenende, was eine geteilte Choreografie zwischen Engineering und Security erleichtert.

Stunde 0-12

Inventur. SBOM-Scan, Container-Image-Audit, Befragung der Plattform-Teams. Welche Services nutzen Terrarium oder Code-Execution-Pfade in LLM-Anwendungen?

Stunde 12-24

Triage. Welche Anwendungen sind Internet-exponiert, welche Multi-Tenant, welche mit kurzlebigen Tokens? Priorisierung nach Risiko-Klasse.

Stunde 24-36

Härtung. IMDSv2 erzwingen, Egress-Allowlist auf Container-Ebene konfigurieren, Sekrete aus Env-Variablen in Vault-basierte Token migrieren.

Stunde 36-48

Detection. SIEM-Regeln für verdächtige Sandbox-Container-Spawns, EDR-Hunt auf /etc/passwd-Zugriff, Anomalie-Alerts für ungewöhnliche Outbound-Connections.

Stunde 48-60

Forensische Sichtung. Letzte 30 Tage Logs auf verdächtige Sandbox-Aktivität prüfen. Bei Funden Incident-Kette starten und Multi-Tenant-Kunden informieren.

Stunde 60-72

Reporting. Status an CISO, Compliance, ggf. Datenschutz und Aufsichtsbehörde. Architektur-Doku zur Sandbox-Schicht aktualisieren, 90-Tage-Review terminieren.

Was die Lücke über die AI-Sandbox-Welt 2026 zeigt

Drei strukturelle Lessons verdienen Beachtung. Erstens: AI-Sandbox-Bugs sind 2026 keine Nischen-Disziplin. Mit dem Boom an LLM-Anwendungen mit Code-Interpreter-Funktion ist die Sandbox zur kritischen Komponente in Enterprise-Stacks geworden. Wer eine Chat-Anwendung mit Python-Ausführung deployed, hat eine Sandbox-Verantwortung, die häufig nicht im Pflichtenheft stand.

Zweitens: SBOM-Disziplin entscheidet über Reaktionszeit. Wer einen vollständigen Software-Stückliste pflegt, reagiert in Stunden. Wer keine SBOM hat, sucht in Tagen. Bei kritischen Lücken wie CVE-2026-5752 ist diese Differenz operativ relevant. Investitionen in SBOM-Tooling lohnen sich im ersten ernsten Vorfall mehrfach.

Drittens: Open-Source-Verantwortung verdient strategische Aufmerksamkeit. Cohere AI ist ein kommerzieller Anbieter, Terrarium ein Open-Source-Projekt mit weitem Einsatzfeld. CERT/CC hat keine koordinierte Patch-Bereitstellung erreicht. Das ist nicht ungewöhnlich, zwingt Betreiber aber zur Eigenverantwortung. Wer Open-Source-Komponenten in produktive Stacks einbaut, sollte den Lifecycle-Status pro Komponente regelmäßig prüfen. Die Tief-Analyse zur strategischen Sandbox-Architektur liefert die längere Diskussion zu diesem Thema.

Wie sich der Vorfall in das Q2-Patch-Bild einfügt

CVE-2026-5752 reiht sich in eine Serie ein. Microsoft ASP.NET Core CVE-2026-40372 kam am selben Wochenende, das CISA-KEV-Update vom 20. April brachte acht weitere Lücken. Das Q2 2026 zeigt eine Frequenz an kritischen Vorfällen, die Security-Operations 2024 nicht gewohnt waren.

Strukturell verlangt das eine andere Reaktions-Architektur. Wer 2024 mit zwei kritischen CVEs pro Monat planen konnte, sieht 2026 vier bis sechs pro Woche. Plattform-Engineering-Sichtbarkeit, automatisierte Patch-Pipelines und SBOM-basierte Inventur müssen zur Standard-Ausstattung gehören. Wer das verschiebt, baut sich eine wachsende Reibung ein, die in den nächsten Quartalen sichtbar wird.

Für Vorstände ergibt sich aus dem Vorfall ein konkreter Prüf-Anlass. Eine Frage nach dem aktuellen Patch-Status zur nächsten Vorstandssitzung schärft das Thema bei CISO und CIO. Eine zweite Frage nach SBOM-Reife und Multi-Tenant-Vorfalls-Kommunikation gibt einen guten Steuerungs-Check. Wer auf beide Fragen in 30 Sekunden eine konkrete Antwort hat, hat eine funktionierende Sicherheits-Governance. Wer Vagheit liefert, hat einen identifizierbaren Investitionsbedarf für 2026.

Häufige Fragen

Stimmt es, dass Terrarium von Cloudflare ist?

Nein. Terrarium ist ein Open-Source-Projekt von Cohere AI. Die Verwechslung mit Cloudflare-Workers ist in einigen Sekundärberichten aufgetreten. Wer in eigenen Mitigations-Notizen Cloudflare als Anbieter geführt hat, sollte das korrigieren.

Welche Patch-Möglichkeiten gibt es?

Aktuell hat CERT/CC keine koordinierte Patch-Bereitstellung mit dem Vendor erreicht. Mitigations-Optionen liegen bei Betreibern: IMDS-Lockdown, Egress-Hardening, Container-Härtung, Berechtigungs-Reduktion. Wer Cohere-Updates aktiv beobachtet, sollte die Patch-Veröffentlichung sofort einspielen.

Welche Detection-Regeln sind sinnvoll?

SIEM-Alerts für Sandbox-Container-Prozess-Spawns, EDR-Hunt auf /etc/passwd-Zugriffe, Anomalien in Outbound-Connections aus Sandbox-Containern. Bei Multi-Tenant-Setups zusätzlich Cross-Tenant-Boundary-Monitoring.

Wie verhält sich der Bug zu klassischen Container-Escape-Lücken?

Verwandt, aber anders. Klassische Container-Escapes treffen die Container-Runtime selbst. CVE-2026-5752 trifft die JavaScript-Sandbox-Schicht innerhalb des Containers, eskaliert aber bis Root und potenziell zum Container-Escape. Defense-in-Depth ist die richtige Antwort.

Was bedeutet die Lücke für Multi-Tenant-Anbieter?

Besonders kritisch. Ein Angreifer mit Root-Zugriff im Sandbox-Container kann potenziell andere Tenant-Daten erreichen, wenn Isolation unzureichend ist. Multi-Tenant-Anbieter sollten umgehend Kunden-Kommunikation vorbereiten und forensische Auswertung der letzten 30 Tage fahren.

Wie ist das Reporting an Aufsichtsbehörden zu handhaben?

NIS2-Betreiber wesentlicher und besonders wichtiger Einrichtungen müssen die Schwere bewerten und ggf. melden. DORA-Betreiber im Finanzsektor klassifizieren als ICT-related incident und folgen dem internen Reporting-Pfad. Wer in regulierten Branchen arbeitet, sollte die Bewertung dokumentieren, auch wenn keine Meldepflicht greift.