Unauthenticated Remote-Code-Execution-Schwachstelle in OpenCode entdeckt

 (cy.md)
3 Punkte von GN⁺ 2026-01-13 | 1 Kommentare | Auf WhatsApp teilen
  • In älteren Versionen von OpenCode wurde eine schwerwiegende Remote-Code-Execution-Schwachstelle entdeckt, die die Ausführung beliebigen Codes ohne Authentifizierung ermöglicht.
  • Versionen vor v1.1.10 starten automatisch einen HTTP-Server, der ohne Authentifizierung die Ausführung beliebiger Befehle, das Lesen von Dateien und das Erstellen von Terminal-Sitzungen erlaubt.
  • Vor v1.0.216 konnte bereits durch den Besuch einer Website Code in der lokalen Umgebung des Nutzers ausgeführt werden.
  • In der aktuellen Version (v1.1.10) ist der Server standardmäßig deaktiviert, aber bei Aktivierung weiterhin ohne Authentifizierung.
  • Die Schwachstelle wurde als CVE-2026-22812 registriert; Entwickler und Nutzer sollten sofort aktualisieren und ihre Einstellungen prüfen.

Überblick über die Schwachstelle

  • OpenCode ist ein Open-Source-AI-Coding-Assistent und startete vor v1.1.10 beim Ausführen automatisch einen HTTP-Server (Standardport 4096+).
    • Der Server stellt Endpunkte wie POST /session/:id/shell, POST /pty, GET /file/content bereit.
    • Da es keine Authentifizierung gibt, kann jeder erreichbare Client Code mit den Rechten des Nutzers ausführen.
  • Beim Start des Servers gibt es keine visuelle Anzeige für den Nutzer, wodurch eine Exponierung schwer erkennbar ist.
  • Die CORS-Richtlinie ist fest auf *.opencode.ai kodiert, sodass Seiten, die von opencode.ai oder einer Subdomain ausgeliefert werden, auf die Server-API zugreifen können.
    • Wird diese Domain kompromittiert oder existiert dort eine XSS-Schwachstelle, können alle Nutzer mit aktiviertem Server angegriffen werden.

Angriffsvektoren

  • Vor v1.0.216: Beliebige Websites konnten auf der lokalen Maschine von Nutzern mit laufendem OpenCode Code ausführen.
  • Vor v1.1.10: Lokale Prozesse oder localhost-Seiten konnten ohne Authentifizierung Code ausführen.
  • In allen Versionen bei aktiviertem Server:
    • Lokale Prozesse und localhost-Seiten können ohne Authentifizierung Code ausführen.
    • Mit dem Flag --mdns können alle Geräte im lokalen Netzwerk zugreifen.
    • Es gibt keine Anzeige dafür, ob der Server läuft, sodass Nutzer ihre Exponierung nicht erkennen.
    • Über die Domain opencode.ai oder deren Subdomains kann Code ausgeführt werden.

Angriffsbeispiele (Proof of Concept)

  • Lokaler Angriff: Wenn der Server läuft, kann ein lokaler Prozess per curl eine Sitzung erstellen und anschließend den Befehl id > /tmp/pwned.txt ausführen.
  • Browserbasierter Angriff (vor v1.0.216): Eine Webseite kann per fetch Anweisungen an den lokalen Server senden und Remote-Skripte herunterladen und ausführen.
    • Das Verhalten wurde unter Firefox bestätigt; Chrome kann wegen des Schutzes vor Zugriffen auf das lokale Netzwerk einen Bestätigungsdialog anzeigen.

Maßnahmen für Nutzer

  • Mit opencode --version die Version prüfen und auf v1.1.10 oder höher aktualisieren.
  • In der Konfigurationsdatei prüfen, ob server.port oder server.hostname aktiviert ist.
  • Das Flag --mdns nicht verwenden (bindet an 0.0.0.0 und legt den Dienst im gesamten Netzwerk offen).
  • Wenn der Server zwingend benötigt wird, opencode.ai und dessen Subdomains nicht aufrufen.
  • Nutzer sollten sich bewusst sein, dass lokale Prozesse bei aktiviertem Server ohne Authentifizierung zugreifen können.

Zeitplan der Offenlegung

  • 2025-11-17: Erstmeldung per E-Mail, keine Antwort
  • 2025-12-27: GitHub Security Advisory eingereicht, keine Antwort
  • 2025-12-29: Öffentliche Meldung durch einen anderen Nutzer
  • 2025-12-30: CORS-Beschränkung in v1.0.216 eingeführt
  • 2026-01-09: Server standardmäßig deaktiviert in v1.1.10
  • 2026-01-11: Vollständige Offenlegung

Empfohlene Maßnahmen

  • CORS auf ein Minimum an Domains beschränken (umgesetzt in v1.0.216)
  • Server standardmäßig deaktivieren (umgesetzt in v1.1.10)
  • Authentifizierung für alle Serveranfragen hinzufügen
  • Nutzern beim Start des Servers eine klare Anzeige geben
  • In der Dokumentation klar angeben, dass die Option --mdns an 0.0.0.0 bindet
  • TLS für Netzwerkkommunikation einsetzen
  • GitHub Security Advisory und CVE-2026-22812 offiziell veröffentlichen
  • Monitoring für Sicherheitsmeldungen per E-Mail und GHSA-Benachrichtigungen verbessern
  • Die Vertrauensbeziehung zwischen OpenCode-Maintainern, opencode.ai und Nutzern klarstellen

Referenz

  • CVE: CVE-2026-22812
  • Betroffenes Paket: npm opencode-ai
  • Aktuelle Informationen und Kontakt: cy.md

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-13
Hacker-News-Kommentare

  • Als Maintainer räumt er ein, auf diesen Sicherheitsbericht nicht angemessen reagiert zu haben
    Mit dem sprunghaften Anstieg der Nutzung seien die Issues explodiert, und man plane, sich diese Woche mit Experten zu treffen, um ein Bug-Bounty-Programm und ein Sicherheitsaudit voranzutreiben

    • Statt Geld für Bug Bounties oder Audits auszugeben, sollte man eher in organisatorische Neuaufstellung und Mitarbeiterschulung investieren
      Wichtiger sei, dass alle Teammitglieder den OWASP Insecure Design Guide verstehen und in die Praxis umsetzen
    • Zunächst wirkte das positiv, aber besorgniserregend ist, dass die Melder der Schwachstelle mehrfach Kontakt aufgenommen hatten und dennoch keine Antwort erhielten
      Da OpenCode ein bekanntes Open-Source-Coding-Agent-Tool ist, könnte die Lücke bereits ausgenutzt worden sein
      Selbst jetzt sei es nötig, das Modell in einer Sandbox-Umgebung wie gVisor laufen zu lassen
      Wenn nicht schnell reagiert werde, könnten noch mehr Angreifer auf RCE-Schwachstellen zielen
    • Das Projekt sei so schnell gewachsen, dass Organisationsmanagement inzwischen wichtiger wirke als die reine Code-Entwicklung
      Es werde gefragt, ob man sich dabei vielleicht auch an anarchistischen Organisationsprinzipien orientiere
    • Kann man nicht einfach Claude bitten, das Sicherheitsproblem zu beheben?
    • Es sei gut zu sehen, dass die Situation offen geteilt und Verantwortung übernommen werde. Das sei nicht einfach, daher verdiene es Anerkennung

  • Viele Leute führen Tools wie OpenCode lokal ohne Rechte-Trennung aus
    Auch Plugins seien standardmäßig auf unbegrenzten Zugriff ausgelegt, und der Ressourcenverbrauch sei hoch
    Mindestens in einem dev-container oder einer VM sollte man es ausführen und nur die nötigen Dateien per SSHFS oder Samba einbinden
    Wer es bequemer wolle, könne auch einen VPS für 5 Dollar im Monat nutzen

    • Es wird gefragt, ob jemand konkret erklären kann, wie man einen dev-container oder eine VM dafür einrichtet
    • Claude fordert bei jedem Ausführen Berechtigungen an, was in diesem Punkt etwas sicherer sei
    • Als AI-Sandbox sei sprites.dev von fly.io ziemlich gut
      Wenn man Server mit qemu betreibt, werde quickemu empfohlen
      Auch die SSH-Remote-Funktion von Zed sei nützlich, sodass man Claude Code oder OpenCode damit verwenden könne

  • Der CORS-Fix verhindert zwar den Missbrauch durch externe Websites, aber das eigentliche Problem ist die Struktur, bei der Code-Ausführung auf localhost möglich ist
    Neovim verwendet standardmäßig Domain Sockets, und der SSH-Daemon von VS Code hat ein Authentifizierungsverfahren
    Ein lokaler Server, der Client-Eingaben ohne Authentifizierung ausführt, ist eine LCE-Schwachstelle (Local Code Execution),
    und wenn darauf über Browser-Anfragen zugegriffen werden kann, wird daraus RCE (Remote Code Execution)

  • Es sei schockierend, dass man in ein CLI-Tool einen HTTP-Endpunkt eingebaut habe, der ohne Authentifizierung RCE erlaubt, und dazu noch einen CORS-Bypass hinzugefügt habe

    • AI-Labore sollten wohl aufhören, Modelle mit Tutorial-Code zu trainieren
    • Bei einem derart offenen Server sei es fast überraschend, dass die CORS-Policy nicht einfach "*" war
    • Manche reagieren auch damit, dass es nach „einfach aus dem Bauchgefühl heraus gebautem Code“ aussehe

  • Der Zeitplan der Offenlegung ist problematisch
    Der Bericht wurde am 2025-11-17 eingereicht, doch trotz mehrerer Kontaktversuche kam keine Antwort

    • Inzwischen scheinen die Entwickler ernsthaft reagieren zu wollen
      Siehe den GitHub-Issue-Kommentar
    • Es gibt auch scherzhafte Reaktionen wie: „Heutzutage machen alle nur noch Vibe Coding, daher sind Security-Issues bad vibes“

  • Selbst wenn der Server standardmäßig deaktiviert ist, bleibt es ernst, sobald er eingeschaltet wird
    Von localhost aus könne jede Webseite Code ausführen, und auch lokale Prozesse ließen sich ohne Authentifizierung starten
    Es gebe nicht einmal eine Anzeige für Nutzer, ob der Server läuft
    TUI-Apps genießen normalerweise Vertrauen, gerade weil sie so etwas nicht tun, doch dieser Vorfall habe dieses Vertrauen massiv beschädigt

    • Es wurde auch gefragt, warum ausgerechnet TUI-Apps hier problematisch sein sollen
    • Als Alternative wird Droid von Factory genannt

  • Es sei überraschend, dass OpenCode von YC (Y Combinator) unterstützt wird
    Von YC hätte man erwartet, eine bessere Sicherheitskultur zu fördern

    • Es gibt auch die zynische Reaktion, dass es bei YC letztlich nur ums Geld gehe
    • Früher gab es bereits den Fall, dass das YC-Unternehmen Flock Passwörter 53-mal hartkodiert hatte
      Mehr dazu in diesem Kommentar
    • Zudem sei es ironisch, dass OpenCode auch noch ein Auth-Provider-Produkt baut

  • Man habe OpenCode zunächst für ein Freiwilligenprojekt gehalten, dann aber festgestellt, dass es sich um ein unternehmensartiges Projekt mit Unterstützung großer Investoren handelt

    • Neben dem offiziellen GitHub-Repository habe es auch ein konkurrierendes Projekt vom Team hinter charm.sh gegeben
    • Vermutlich waren damit Projekte wie crush, roocode oder kilo gemeint. Diese haben bislang noch keine großen Sponsoren

  • Die Nutzung sei eingestellt worden, weil ständig neue Funktionen hinzugefügt, aber die grundlegende Wartung vernachlässigt worden sei
    Das Ziel, mehrere Modelle gleichzeitig zu verwenden, sei interessant gewesen, doch das Teilen des Kontexts war ineffizient, weshalb der praktische Nutzen begrenzt blieb
    Jetzt würden stattdessen Claude Code und Codex parallel genutzt
    Trotzdem sei der Bedarf an einer offenen Plattform zur Integration mehrerer Modelle weiterhin groß

    • Empfohlen wird die Kombination aus ampcode(Link) und Crush(Link) + z.ai GLM
      Mit ampcode könne man kostenlos einfache Skripte erstellen, und Crush+GLM folge den Plänen von Claude oder Codex gut
    • Es wird auch angemerkt, dass es schwieriger sei, Disziplin bei Reviews und Qualitätskontrolle einzuhalten, als einfach neue Funktionen hinzuzufügen

  • Anfangs mochte man Aider, hatte dann aber häufig Probleme, weil es kaum gepflegt wurde
    Man wollte OpenCode installieren, zögert nach diesem Vorfall nun aber
    Es sei erstaunlich, wie wenige modellunabhängige Open-Source-CLI-LLM-Assistenten es gibt