OpenCodes MCP-Anmeldung übergab eine Server-URL an PowerShell – und es gibt keine CVE, die das kennzeichnet.

Am 19. Oktober 2026 hat Pillar Security eine Remote-Code-Execution-Schwachstelle in OpenCode offengelegt, dem von Anomaly gepflegten Open-Source-Coding-Agenten: Ein entfernter Model Context Protocol-Server, den ein Entwickler konfiguriert hatte, konnte während der MCP-OAuth-Anmeldung beliebigen Code auf der eigenen Maschine dieses Entwicklers ausführen, ohne dass dazwischen eine Einwilligungsabfrage erfolgte. Der Fehler war auf Windows und das Windows-Subsystem für Linux beschränkt, wo OpenCode die vom Server bereitgestellte Login-URL ohne Escaping an einen PowerShell-Befehl übergab. Pillar gibt den betroffenen Bereich mit 1.0.137 bis 1.18.32 an. Anomaly behob ihn in 1.18.33, veröffentlichte die Version auf npm am 28. September 2026, und beantragte keine CVE und veröffentlichte keine Sicherheitsmeldung – daher wird nichts in einem normalen Schwachstellen-Feed ein betroffenes Team zum Upgrade auffordern. Pillar meldete keine Hinweise darauf, dass die Schwachstelle jemals in einem Angriff ausgenutzt wurde. Dies ist ein Eintrag in dem KI-Vorfallarchiv, in dem jeder Eintrag seine eigenen Quellen, Schweregrad, Vertrauensstufe und Kennzeichnung als umstritten enthält.

Worin der Fehler tatsächlich bestand

Wenn ein MCP-Client eine Verbindung zu einem Remote-Server herstellt, der eine Autorisierung verlangt, führt er einen OAuth-Discovery-Handshake aus. Der Server antwortet mit einem 401 und einer Challenge, die auf seine Discovery-Dokumente verweist, und ein Feld in diesen Dokumenten – authorization_endpoint – teilt dem Client mit, wohin der Benutzer zur Anmeldung geschickt werden soll. Es ist eine Zeichenkette ohne festes Format, und die zu authentifizierende Partei ist diejenige, die sie auswählt.

In OpenCode 1.18.32 gelangte diese Zeichenkette vom Netz bis in eine Shell. Pillar verfolgte den Pfad vom Discovery-Dokument des Servers durch das MCP-SDK in oauth-provider.ts, mcp/index.ts und browser.ts, endend bei open, dem kleinen Paket, das OpenCode zum Starten eines Browsers verwendet. Nichts auf diesem Pfad prüfte das Schema der URL, und nichts verglich sie mit dem Origin des Servers, den der Entwickler konfiguriert hatte. Der Handshake ist konstruktionsbedingt automatisch – der ganze Sinn besteht darin, dich zu einer Anmeldeseite zu schicken, ohne dass du eine URL kopieren musst –, sodass kein Genehmigungsschritt zwischen der Antwort des Servers und dem Launcher stand.

The launcher is where it broke. On macOS and Linux, open passes the address as an argument vector and no shell is involved. On Windows, version 10.1.2 of open — the version every affected OpenCode release pinned — builds a PowerShell command, base64-encodes it and runs it with powershell -EncodedCommand. Pillar quotes the source: the application name is escaped on one line, and the target URL is not. PowerShell evaluates $(...) subexpressions inside double-quoted strings, so an address of the form https://evil.test/$([IO.File]::WriteAllText('C:\Users\Public\pwned.txt','RCE')) runs before the browser launch fails. OpenCode discards that failure.

Zwei Eigenschaften sorgten dafür, dass es leicht zu übersehen war. Die Nutzlast enthält keine Leerzeichen, daher bleibt sie bei der URL-Normalisierung intakt, und es handelt sich um eine syntaktisch gewöhnliche https-Adresse. Und der Server musste bei seiner Konfiguration nicht feindselig sein: Pillar merkt an, dass eine spätere Kompromittierung, ein gekaperter Registry-Eintrag, eine Typosquat-Domain oder eine abgelaufene Domain jeweils einen vertrauenswürdigen Konfigurationseintrag in einen Auslieferungsmechanismus verwandeln würde.

Wer wurde exponiert?

Die betroffene Population sind Windows- und WSL-Nutzer, die OpenCode mit einem konfigurierten Remote-MCP-Server ausführen. Pillar beschreibt OpenCode mit etwa 3 Millionen wöchentlichen npm-Downloads und 211.000 GitHub-Sternen; der Bericht von Infosecurity Magazine beziffert die Sternanzahl auf über 218.000. Keine der beiden Zahlen ist eine Zählung betroffener Installationen, und niemand hat eine veröffentlicht.

Der Auslöser ist der eine Punkt, an dem die beiden primären Darstellungen voneinander abweichen, und er ist sowohl für das Risiko als auch für den Schweregrad von Bedeutung. Pillar beschreibt die Ausnutzung so, dass keine zusätzliche Benutzerinteraktion oder Zustimmung erforderlich ist. The Hacker News sagt in seinem Bericht vom 22. Oktober, der Browserschritt laufe nur, wenn ein Entwickler die Anmeldung startet – indem er opencode mcp auth ausführt oder die entsprechende Anfrage stellt –, und dass allein das Konfiguriertsein des Servers oder das Öffnen einer Sitzung nicht dazu führt, dass dieser Schritt erreicht wird. So oder so tut der Entwickler nichts Ungewöhnliches; die Authentifizierung gegenüber einem bereits in der Konfiguration vorhandenen Server zu starten, ist Routine. Aber „keine Interaktion“ und „eine Routineinteraktion“ sind unterschiedliche Aussagen, und der Unterschied fließt direkt in die Bewertung ein.

Der Fix kam an, beschrieben als Refactoring

Pillar meldete die Schwachstelle am 29. August 2026 privat über ein GitHub Security Advisory, mit vollständigem Reproduktionsmaterial. Am 25. September hakte Pillar außerhalb des Advisory-Threads nach; Anomaly bestätigte, dass der Bericht das Team erreicht hatte, und antwortete, dass bösartige MCP-Server außerhalb des Bedrohungsmodells von Anomaly lägen. Am selben Tag wurde Pull Request #51414 – zusammengeführt als Commit 29f07e0c – übernommen. Er wird dahingehend beschrieben, dass er acht Aufrufstellen zum Starten des Browsers in einer einzigen Hilfsfunktion zusammenfasst. Version 1.18.33 erreichte npm drei Tage später, am 28. September.

Der Patch hat drei Ebenen. Die offene Abhängigkeit wurde auf 11.0.4 aktualisiert, die das Ziel in einfache Anführungszeichen einschließt, und PowerShell expandiert nichts innerhalb einfacher Anführungszeichen. Ein neuer openUrl() Helfer lehnt Nicht-HTTP(S)-Schemata ab. Eine Schema-Prüfung floss in redirectToAuthorization selbst ein, an der Grenze, die Pillar in seinem Bericht genannt hatte. Weder der Pull Request noch die Versionshinweise erwähnen eine Sicherheitslücke, und Anomaly forderte kein CVE an.

The Hacker News berichtet, dass in der veröffentlichten Sicherheitsrichtlinie von Anomaly steht, dass MCP-Server, die ein Nutzer konfiguriert, „außerhalb unserer Vertrauensgrenze“ liegen, und dass das Unternehmen in diesem Jahr Sicherheitshinweise zu weiteren OpenCode-Schwachstellen bei der Codeausführung herausgegeben hat, darunter eine, die im August behoben wurde. Pillars Schilderung der erhaltenen Antwort fällt unverblümter aus: „Wir haben die Abhängigkeit aktualisiert, aber im Allgemeinen liegt der Umgang mit einem bösartigen MCP-Server außerhalb unseres Bedrohungsmodells.“

Als Abfolge gelesen, setzt die Zeitlinie den OpenCode-Bug an das Ende einer fünfjährigen Spur statt an deren Anfang. Der Defekt, der ihn hervorbrachte, war bereits öffentlich, und seine Behebung war bereits ausgeliefert, bevor die Zeile, die ihn nutzte, geschrieben wurde.

Warum die Schema-Validierung es nicht verhindert hätte

Die vereinbarte Abhilfe für diese Fehlerklasse ist die Validierung des URL-Schemas: die seltsamen Schemata blockieren, http und https zulassen, fertig. Genau das liefert das MCP TypeScript SDK aus, und genau das hat OpenCode in 1.18.33 hinzugefügt. Pillars Payload besteht jede einzelne dieser Prüfungen, weil er https ist. Die Denylist des SDK blockiert javascript:, data: und vbscript:; eine strengere http/https-Allowlist wurde im August 2025 in SDK-Pull-Request #841 vorgeschlagen und ohne Merge geschlossen, während Pull-Request #877 die Denylist mit drei Schemata in v1.17.4 auslieferte — und Pillar sagt, dass dies in SDK 1.32.0 zum Zeitpunkt der Veröffentlichung noch die Richtlinie war. Was die Lücke in OpenCode tatsächlich geschlossen hat, war das Aktualisieren der Abhängigkeit, nicht die Prüfungen, die wie die Sicherheitskorrektur aussehen.

Die Vorgeschichte spricht dagegen, dies als Ausrutscher eines einzelnen Projekts zu behandeln. Das open-Paket trägt seit 2021 eine README-Warnung, dass es keine Sicherheitsgarantien bietet und das Bereinigen von Eingaben Sache des Aufrufers ist. Im Oktober 2020 reichte ein Nutzer Issue #202 ein und berichtete, dass eine URL mit Dollarzeichen unter WSL 2 teilweise verloren ging — die String-Expansion, gemeldet als Ärgernis mit defekten Links. Im Oktober 2023 reichte ein Adobe-Ingenieur Issue #323 ein, „OS command injection on windows when opening urls“, mit einem einzeiligen Proof of Concept: open('https://$(calc.exe)')Der Maintainer zitierte die README und sagte, Pull Requests zur Verbesserung des Escapings seien willkommen; das Issue wurde als „not planned“ geschlossen, drei Tage bevor open 11.0.0 das Escaping trotzdem auslieferte, am 15. November 2025. OpenCode schrieb seinen Aufruf zum Starten des Browsers am 7. Dezember 2025, drei Wochen nachdem die korrigierte Version von open existierte, gegen einen Versions-Pin, der bereits mehrere Monate alt war.

In den Monaten, bevor dieser Aufruf verfasst wurde, verzeichnete das MCP-Ökosystem drei CVEs zur selben Senke bzw. zum selben Feld: CVE-2025-6514 in mcp-remote (CVSS 9.6, offengelegt von JFrog am 9. Juli 2025), CVE-2025-58062 in openmcp-client und CVE-2025-10619 in sequa-mcp. Pillar stellt dem Clients gegenüber, die aus einem entfernten String überhaupt keinen Shell-Befehl bauen: Als Beispiele nennt es gemini-cli, Claude Code, github-mcp-server und Dockers mcp-gateway, die die URL als Argumentvektor übergeben, wodurch die Frage, was der String enthält, nicht mehr ausschlaggebend ist.

Was gesichert ist und was nicht

Der Datensatz wird vom Archiv mit der Vertrauensstufe A bewertet, und die dahinterstehende Berichterstattung ist stichhaltig. Infosecurity Magazine veröffentlichte am 20. Oktober ein eigenes Interview mit Eilon Cohen von Pillar; The Hacker News veröffentlichte am 22. Oktober einen eigenen Bericht; DKCERT, Dänemarks nationales CERT, fasste den Befund am 21. Oktober unter Verweis auf Infosecurity zusammen; und das Forschungszentrum der Cloud Security Alliance veröffentlichte eine Analyse, die den einen wesentlichen Vorbehalt unten ergänzt. Keine dieser Quellen ist die berichtende Stelle, und sie stimmen in Bezug auf Mechanismus, Versionen und die stille Korrektur überein. Anomaly selbst hat nichts über die Schwachstelle veröffentlicht.

Festgestellt, zu Protokoll:

• Der Defekt, sein Mechanismus und sein Plattformumfang. Pillar identifiziert konkrete Quellzeilen, und die Korrektur ist im öffentlichen Diff von 1.18.32 auf 1.18.33 sichtbar; die beiden unabhängigen Nachrichtenberichte beschreiben denselben Datenfluss.

• Der betroffene Bereich, 1.0.137 bis 1.18.32, und die korrigierte Version, 1.18.33, veröffentlicht am 28. September 2026.

• Dass weder eine CVE noch ein Advisory existiert. Das lässt sich überprüfen, und es ist die tragende Tatsache für Verteidiger.

• Dass keine Ausnutzung gemeldet wurde. Pillar gibt an, keine Anzeichen für eine Nutzung in Angriffen gesehen zu haben, und The Hacker News merkt an, dass keine Indicators of Compromise veröffentlicht wurden. Das Fehlen veröffentlichter Indikatoren ist kein Beweis für deren Nichtvorhandensein, und ohne Telemetrie vom Anbieter lässt sich keine der beiden Deutungen bestätigen.

Nicht etabliert oder im Spannungsverhältnis:

• Die 9,8. Diese Zahl ist der von Pillar vorgeschlagene CVSS-v3.1-Score, kein offizieller: Ohne CVE gibt es keinen NVD-Score und keinen Vendor-Score. Die Forschungsnotiz der Cloud Security Alliance weist darauf hin, dass 9,8 keine Benutzerinteraktion voraussetzt und dass, wenn die Darstellung des Auslösers durch The Hacker News zutrifft, eine Bewertung mit erforderlicher Benutzerinteraktion – etwa 8,8 – besser passen würde. Dieser Beitrag klärt das nicht; das High-Severity-Tag des Archivs ist eine Klassifizierung, kein Score.

• Das Veröffentlichungsdatum. Pillars Bericht ist in seiner Kopfzeile auf den 19. Oktober 2026 datiert, und beide Nachrichtenberichte verwenden dieses Datum; die Offenlegungszeitleiste am Fuß von Pillars eigenem Bericht nennt als Veröffentlichungsdatum den 4. Oktober. Das Archiv verzeichnet den 19. Oktober mit Tagesgenauigkeit.

• Die Größe der exponierten Population. Es wurde keine Anzahl veröffentlicht. Die oben genannten Download- und Star-Zahlen sind Repository-Metriken, keine Installationen.

• Ob eine Maschine tatsächlich kompromittiert wurde. Nichts Veröffentlichtes stützt dies, und der Vorgang weist keinen tatsächlichen Schaden auf.

Was hat sich geändert, und was ist zu tun

Die Behebung besteht in einer Versionsprüfung, denn es gibt keinen anderen Weg, das festzustellen. OpenCode ist ab Version 1.18.33 korrigiert. Betroffene Installationen müssen durch direkte Inventarisierung des Pakets ermittelt werden: Pillar empfiehlt, OpenCode selbst zu inventarisieren, statt auf einen Feed zu warten, und die Notiz der Cloud Security Alliance legt nahe, die Version des Pakets opencode-ai abzufragen, da es keine Kennung gibt, mit der ein Feed abgeglichen werden könnte. Teams, die nicht aktualisieren können und Windows oder das Windows-Subsystem für Linux ausführen, sollten nicht geprüfte Remote-MCP-Server aus ihrer OpenCode-Konfiguration entfernen; opencode mcp list zeigt, welche Server vorhanden sind.

Für alle, die einen MCP-Client warten, ist Pillars Empfehlung enger gefasst als der übliche Rat: URLs als Argumentvektor übergeben und niemals eine Befehlszeile aus einer Remote-Zeichenkette erzeugen, die OAuth-Discovery an den Ursprung des Servers binden, den der Nutzer konfiguriert hat, und Discovery-Dokumente, Server-Metadaten und Tool-Deskriptoren als nicht vertrauenswürdige Eingaben statt als Einstellungen behandeln. Die Notiz der Cloud Security Alliance ergänzt Hunting-Heuristiken – etwa einen OpenCode-Prozess, der powershell.exe mit -EncodedCommand startet – und betont dabei, dass es sich um Vorschläge für das Detection Engineering handelt, nicht um veröffentlichte Indicators of Compromise.

Nicht der Console-Breach

Pillars Offenlegung erfolgte Tage, nachdem Anomaly einen separaten Sicherheitsvorfall bei OpenCodes gehosteter Console bestätigt hatte, bei dem möglicherweise gespeicherte API-Provider-Schlüssel offengelegt wurden. Die beiden Ereignisse hängen nicht zusammen, und Pillars Eilon Cohen war in seinem Interview mit Infosecurity Magazine eindeutig bezüglich des Unterschieds. „Der Vorfall traf ein Legacy-System hinter einem gehosteten Schlüssel-Proxy und legte Provider-Schlüssel offen, die Nutzer dort gespeichert hatten“, sagte er. „Die von uns gemeldete Schwachstelle läuft in die entgegengesetzte Richtung: ein bösartiger Remote-MCP-Server, der während des OAuth-Handshakes Code auf dem eigenen Rechner eines Entwicklers ausführt. Anderes Ziel und andere Angreiferposition.“ Der Console-Vorfall ist ein separater Datensatz im Archiv, und die beiden sollten als getrennte Einträge gelesen werden.

Was sie verbindet, ist in Cohens Rahmung die Frage, die beiden zugrunde liegt: „Wem man Zugangsdaten und Eingaben an ein KI-Codierungswerkzeug übergibt und was dieses Werkzeug damit macht.“

Die Offenlegungslücke ist der Teil, der den Fehler überdauert. Eine Schwachstelle, die ihre Entdecker als kritisch einstufen, die im Rahmen eines Dependency-Bumps behoben wurde und in keinem der automatisierten Signale auftaucht, auf die sich ein Defender normalerweise verlässt, lässt eine direkte Bestandsaufnahme als einzige Erkennungsmethode übrig – und der Anbieter veröffentlichte keinen Sicherheitshinweis, der jemanden anweist, eine durchzuführen.