OpenHands-Lücke öffnet die Agenten-Sandbox für fremde Befehle

Worum es geht

Wer einen Coding-Agenten in einem Container betreibt, erwartet eine abgegrenzte Arbeitsumgebung. Eine am 26. Oktober 2026 veröffentlichte Sicherheitswarnung zeigt, dass diese Grenze wenig hilft, wenn die Steuerung der Umgebung von außen erreichbar ist. VulnCheck beschreibt unter CVE-2026-112346 eine kritische Schwachstelle im OpenHands Software Agent SDK vor Version 1.52.0.

Der konkrete Schaden betrifft nicht nur den Programmierassistenten: Angreifer können laut Warnung Befehle innerhalb seiner Sandbox ausführen, eingebundene Projektdateien erreichen und dort gespeicherte Geheimnisse lesen. Voraussetzung ist, dass sie den veröffentlichten Container-Port über das Netzwerk erreichen. Das ist ein überprüfbares Konfigurationsproblem, kein Beleg dafür, dass jede OpenHands-Installation öffentlich angreifbar ist.

Was die OpenHands-Lücke tatsächlich macht

Das SDK ist ein Baukasten, mit dem Entwickler Softwareagenten in eigene Werkzeuge integrieren. Die Warnung betrifft die Arbeitsumgebungen DockerWorkspace und Apptainer. Deren Startmechanismen binden den Agentenserver an alle Netzwerkschnittstellen, bezeichnet als 0.0.0.0, während eine leere Liste von Sitzungsschlüsseln die Anmeldung standardmäßig deaktiviert.

Damit wird aus einer internen Steuerleitung unter ungünstigen Netzwerkbedingungen eine offene Fernbedienung. Erreichbare HTTP- und WebSocket-Schnittstellen können laut Advisory ohne vorherige Anmeldung Shell-Befehle entgegennehmen. Diese laufen mit Root-Rechten in der Sandbox. Das ist ausdrücklich nicht dasselbe wie nachgewiesene Root-Rechte auf dem Host, also dem Rechner außerhalb des Containers.

Die offizielle Veröffentlichung von Version 1.52.0 ist bereits auf den 5. Oktober datiert. Sie nennt eine Korrektur, die Docker-Ports nur an die lokale Loopback-Schnittstelle bindet. Neu ist hier die Sicherheitswarnung vom 26. Oktober, nicht die Existenz dieses Updates. Die Versionsgrenze im Advisory lautet: betroffen vor 1.52.0.

Warum das wichtig ist

Coding-Agenten erhalten häufig genau die Dinge, die für einen Angreifer interessant wären: Quellcode, einen beschreibbaren Arbeitsordner und Zugangsdaten für Entwicklungsdienste. Der Nutzen des Agenten entsteht durch diese Werkzeuge. Deshalb muss ihre Steuerung ebenso sorgfältig geschützt werden wie eine normale Verwaltungsoberfläche.

VulnCheck bewertet die Schwachstelle nach CVSS 4.0 mit 9,3 von 10 Punkten. The Hacker Wire führt 9,8 nach CVSS 3.1 auf; OpenCVE zeigt beide Bewertungen. Die unterschiedlichen Zahlen beruhen auf unterschiedlichen Bewertungsversionen und sind kein Beleg für eine zwischenzeitliche Verschärfung. Beide ordnen die Lücke als kritisch ein.

Für Betreiber ergibt sich eine klare Priorität: betroffene SDK-Versionen aktualisieren und anschließend die tatsächlich veröffentlichten Ports, Netzwerkschnittstellen und Zugangskontrollen prüfen. Eine Versionsnummer allein beschreibt nicht die gesamte Bereitstellung. Eigene Proxy-Regeln, Portweiterleitungen oder abweichende Startparameter müssen ebenfalls in die Prüfung einfließen. Das ist eine praktische Empfehlung aus dem beschriebenen Angriffsweg, keine Behauptung über einen zusätzlichen Fehler.

Einfach erklärt

Ein Container ist hier wie eine abgeschlossene Werkstatt. Darin liegen Werkzeuge, Pläne und Schlüssel für andere Arbeitsräume. Die Werkstatt schützt das übrige Gebäude aber nur begrenzt, wenn ihre Fernbedienung ungesichert im öffentlichen Flur hängt.

Ein Fremder muss dann nicht die Wand durchbrechen. Er benutzt den vorgesehenen Zugang und lässt die Werkzeuge für sich arbeiten. Die Reparatur besteht deshalb nicht darin, dem Assistenten bessere Anweisungen zu geben, sondern den Zugang zur Werkstatt technisch zu begrenzen.

Praktisches Beispiel

Ein fiktives Entwicklungsteam betreibt drei Agenten-Container auf einem gemeinsam genutzten Testserver. Jeder Container hat einen eigenen Projektordner; einer enthält einen Testschlüssel für einen externen Dienst. Das Team entdeckt, dass zwei veröffentlichte Ports auch aus einem Netz erreichbar sind, das nicht für die Agentensteuerung vorgesehen war.

Es beschränkt zuerst diese Erreichbarkeit, prüft die SDK-Versionen und aktualisiert betroffene Installationen. Danach kontrolliert es aus den vorgesehenen und den nicht vorgesehenen Netzen, welche Zugriffe noch möglich sind. Die drei Container und zwei Ports sind Beispielzahlen, keine Angaben aus dem Sicherheitsbericht.

Falls sich ein unberechtigter Zugriff nicht ausschließen lässt, gehört auch die Prüfung der eingebundenen Dateien und verwendeten Zugangsdaten zur Aufarbeitung. Einen möglicherweise offengelegten Schlüssel zu ersetzen, beseitigt ein anderes Risiko als das Schließen des Ports. Beides sollte getrennt betrachtet werden.

Einordnung und Grenzen

• Erreichbarkeit ist Voraussetzung. Die Warnung beschreibt einen Angriff über einen zugänglichen Container-Port. Sie beweist nicht, dass jede lokale Installation aus dem Internet erreichbar ist.
• Sandbox ist nicht Host. Beschrieben sind Root-Befehle innerhalb der Sandbox sowie Zugriff auf eingebundene Dateien und Geheimnisse. Ein allgemeiner Ausbruch aus dem Container wird damit nicht nachgewiesen.
• Keine belegte Angriffswelle. Die geprüften Einträge führen keine bestätigte Kampagne auf. Ein fehlender Eintrag in einer Liste ausgenutzter Schwachstellen beweist allerdings auch nicht, dass es keinerlei Missbrauch gab.

SEO- und GEO-Schlüsselbegriffe

OpenHands, Software Agent SDK, CVE-2026-112346, Coding-Agenten, Sandbox-Sicherheit, DockerWorkspace, Apptainer, Zugangskontrolle, VulnCheck, Entwicklerwerkzeuge