OpenCode: Anmeldung kann fremden Code auf den Rechner bringen : Manipulierte MCP-Server gefährden Windows und WSL

Betroffen sind die OpenCode-Versionen 1.0.137 bis einschließlich 1.18.32 unter Windows und WSL. Anomaly, das Unternehmen hinter dem quelloffenen Werkzeug, veröffentlichte bereits Ende September 2026 mit Version 1.18.33 eine Korrektur. Startete ein Entwickler zuvor die Anmeldung bei einem externen Server, konnten dessen Betreiber Befehle auf seinem Rechner ausführen (Remote-Code-Execution, RCE) – das war naturgemäß auch möglich, wenn Angreifer einen zuvor vertrauenswürdigen Server übernommen hatten. Die Befehle erhielten dieselben Zugriffsrechte wie der Entwickler. Dadurch konnten Angreifer auf Dateien und Zugangsdaten zugreifen, die für dessen Benutzerkonto zugänglich waren.

Angriff via PowerShell mit manipulierten URLs

Über das Model-Context-Protocol (MCP) bindet OpenCode externe Werkzeuge und Dienste ein. Benötigt ein solcher Dienst eine Anmeldung, kann der Agent dafür einen OAuth-Autorisierungsvorgang starten. Dabei erhält er vom Server die Adresse der Webseite (Uniform Resource Locator, URL), die im Browser geöffnet werden soll. Die bewusste Schwachstelle steckte in der Verarbeitung dieser Webadresse: Unter Windows und WSL nutzte OpenCode die Hilfsbibliothek open, um die Anmeldeseite im Browser zu öffnen. Diese fügte die Adresse in einen PowerShell-Befehl ein und sicherte dabei Sonderzeichen nicht ausreichend ab – Teile einer manipulierten Adresse konnten dadurch als Befehl ausgeführt werden.

Dadurch konnte ein Angreifer eine Adresse liefern, deren Bestandteile von PowerShell als auszuführender Befehl interpretiert wurden. Aus einer vermeintlichen Webadresse wurde so ein Weg zur lokalen Codeausführung. Technisch handelt es sich um eine Befehlsinjektion: Externe Daten gelangen in einen Befehlsinterpreter und werden dort teilweise als Programmcode verarbeitet.

Vorbedingungen für erfolgreiche Attacken

Der Angreifer muss einen MCP-Server kontrollieren, den der Entwickler in OpenCode eingetragen hat. Anschließend musste der Entwickler die Anmeldung starten, etwa mit opencode mcp auth oder über eine entsprechende Anfrage an den Agenten. Das bloße Eintragen des Servers oder das Öffnen einer Sitzung löst den verwundbaren Browserstart hingegen nicht aus. Der kritische Schritt ist die ausdrücklich angestoßene Anmeldung – danach ist für die eingeschleuste Befehlsausführung allerdings keine weitere Bestätigung mehr notwendig.

Auch ein ursprünglich vertrauenswürdiger Dienst kann so zum Ausgangspunkt eines Angriffs werden: Wird ein Server kompromittiert oder wechselt eine Domain den Besitzer, kann ein (vormals) legitimer Dienst bei einer späteren Anmeldung manipulierte Adressen liefern.

macOS und eigenständige Linux-Installationen sind von diesem konkreten Fehler nicht betroffen – dort öffnet OpenCode die Adresse ohne den hier verwundbaren Weg über einen Befehlsinterpreter.

Warum selbst eine HTTPS-Adresse gefährlich sein kann

Eine Prüfung auf erlaubte Adresstypen allein verhindert diesen Angriff nicht: Auch eine manipulierte Adresse kann regulär mit https:// beginnen. Sie besteht damit eine Kontrolle, die lediglich Webadressen zulässt und beispielsweise lokale Dateiverweise ausschließt. Die Gefahr entsteht beim Öffnen der Adresse auf dem eigenen Rechner: Das Hilfsprogramm muss sie als reine Webadresse behandeln und verhindern, dass Teile davon als Befehle ausgeführt werden. HTTPS schützt die Datenübertragung, verhindert aber keine Fehler bei dieser lokalen Verarbeitung.

Die jetzige Korrektur setzt an mehreren Stellen an: OpenCode öffnet einerseits nur noch Webadressen, die mit HTTP oder HTTPS beginnen. Außerdem wurde die Hilfsbibliothek open von Version 10.1.2 auf 11.0.4 aktualisiert. Alle Programmteile nutzen nun eine gemeinsame Funktion, um den Browser zu starten. Die aktualisierte Bibliothek sorgt nun dafür, dass bösartige Bestandteile – auch in HTTPS-Adressen – beim Browserstart nicht als Befehle ausgeführt werden.

Déjà-vu: „open“-Problem taucht erneut auf

Das Verhalten von open unter Windows war bereits im Oktober 2023 als Risiko für Befehlsinjektionen gemeldet worden. Der damalige Hinweis zeigte, dass beim Öffnen einer Webadresse zusätzlich ein lokaler Befehl ausgeführt werden konnte. In der Diskussion erklärte der Bibliotheksentwickler: „Dieses Paket gibt keine Sicherheitsgarantien.“ Bei nicht-vertrauenswürdigen Eingaben liege die korrekte Bereinigung in der Verantwortung des aufrufenden Programms.

Ein sehr ähnlicher Fehler betraf überdies im Juli 2025 den MCP-Proxy mcp-remote: Auch dort gelangte eine vom Server gelieferte OAuth-Adresse in die Befehlsverarbeitung. Diese Schwachstelle erhielt die Kennung CVE-2025-6514. Der erneute Fall zeigt, warum gerade Hilfsfunktionen zum Öffnen externer Adressen sorgfältig geprüft werden müssen.

Problematisch: Korrektur ohne ausdrückliche Sicherheitsmeldung

Pillar Security meldete den Fehler nach eigenen Angaben am 29. August vertraulich an Anomaly und veröffentlichte seine Untersuchung am 19. Oktober. Das Unternehmen stuft die Schwachstelle als kritisch ein und schlägt im „Common Vulnerability Scoring System“ (CVSS) einen Wert von 9,8 vor. Dabei handelt es sich um die Bewertung des Entdeckers, nicht um eine mit einer veröffentlichten Schwachstellenkennung verknüpfte Einstufung.

Anomaly veröffentlichte hingegen keine eigene Sicherheitswarnung zu dem Fehler; laut Pillar Security beantragte das Unternehmen auch keine Kennung im CVE-System. Das Update wurde lediglich als technische Überarbeitung der Funktion zum Öffnen des Browsers beschrieben.

In seiner Sicherheitsrichtlinie erklärt Anomaly, dass selbst-eingerichtete externe MCP-Server „außerhalb unserer Vertrauensgrenze“ liegen. Das Unternehmen betrachtet deren Verhalten damit nicht als Teil der Sicherheitsrisiken, die es abdecken will. Laut Pillar Security blieb Anomaly bei dieser Einschätzung – auch als der Entdecker um eine erneute Bewertung und eine CVE-Kennung bat.

Dieses Verhalten erschwert die Suche nach gefährdeten Installationen: Prüfprogramme, die sich auf Sicherheitsmeldungen und Schwachstellendatenbanken verlassen, könnten den Fehler übersehen. Betreiber sollten deshalb die installierte Version selbst kontrollieren und bei Bedarf aktualisieren.

Pillar Security liegen nach eigenen Angaben keine Hinweise darauf vor, dass Angreifer die Lücke bereits ausgenutzt haben. Das Unternehmen veröffentlichte auch keine Erkennungsmerkmale, mit denen sich vergangene Angriffe nachweisen lassen. Ob ein bestimmter Rechner angegriffen wurde, bleibt damit nur sehr schwer erkennbar.

Empfehlungen für OpenCode-Anwender

Wer OpenCode unter Windows oder WSL einsetzt, sollte die Installation aktualisieren und die eingerichteten Server prüfen:

• auf OpenCode 1.18.33 oder neuer aktualisieren
• falls ein Update vorerst nicht möglich ist: ungeprüfte entfernte MCP-Server aus der Konfiguration entfernen
• mit opencode mcp list anzeigen lassen, welche Server konfiguriert sind

Das Entfernen ungeprüfter Server ist dabei nur eine vorübergehende Risikobegrenzung. Eine dauerhafte Absicherung erfordert das angesprochene Update, denn auch ein zuvor geprüfter Dienst kann später kompromittiert werden.

Abgrenzung: Von dieser lokalen Schwachstelle getrennt zu betrachten ist ein ungefähr zeitgleich bekannt gewordener Einbruch in die gehostete OpenCode Console. Dabei könnten dort gespeicherte Programmierschnittstellen-Schlüssel für OpenAI, Anthropic und Google offengelegt worden sein. Der hier beschriebene Fehler betrifft hingegen die Verarbeitung einer Anmeldeadresse auf Entwicklersystemen.