OpenCode und der MCP-Login: eine Lücke, die kein Scanner meldet, weil es keine CVE gibt

/01Was Pillar Security offengelegt hat

OpenCode, ein quelloffener Coding-Agent für das Terminal vom Hersteller Anomaly, hatte einen Fehler im Anmeldeablauf für Remote-MCP-Server. Das Sicherheitsunternehmen Pillar Security hat ihn in einem Bericht mit Datum 19. Oktober 2026 beschrieben, The Hacker News hat am 22. Oktober nachgezogen. Die Eckdaten aus dem Bericht:

Die Zeittafel im Bericht: Am 7. Dezember 2025 kam der fehlerhafte Code ins Projekt. Am 29. August 2026 meldete Pillar den Fund vertraulich über die Advisory-Funktion von GitHub. Am 25. September antwortete Anomaly, bösartige MCP-Server lägen außerhalb des eigenen Bedrohungsmodells; am selben Tag wurde die Korrektur (Pull Request #51414) übernommen. Am 28. September erschien 1.18.33. Für die eigene Veröffentlichung nennt die Zeittafel den 4. Oktober, die Kopfzeile des Berichts und The Hacker News nennen den 19. Oktober — der Bericht löst den Widerspruch nicht auf. Für Ihre Planung zählt ohnehin nur ein Datum: der 28. September, seit dem die Korrektur verfügbar ist.

Die Übertragung auf den Mittelstand: OpenCode läuft dort, wo Entwickler arbeiten — auf Windows-Notebooks, häufig in WSL. Auf diesen Rechnern liegen Quellcode, SSH-Schlüssel, Zugangsdaten zu Git-Servern und oft ein VPN-Zugang ins Firmennetz. Die Lücke hängt nicht am Sprachmodell: Laut Pillar braucht der Angriff weder eine Prompt Injection noch eine Manipulation des Modells. Auch wer OpenCode ausschließlich gegen einen eigenen Inferenz-Endpunkt mit Ollama oder vLLM betreibt, ist betroffen, sobald ein Remote-MCP-Server eingetragen ist.

/02Warum ein Login-Fenster zur Befehlszeile wurde

Das Model Context Protocol verbindet einen Agenten mit Werkzeugen. Bei einem Remote-Server geschieht das über HTTP, und wenn der Server eine Anmeldung verlangt, über OAuth. Die OpenCode-Dokumentation beschreibt das so: OAuth ist für Remote-Server aktiv, solange oauth nicht auf false steht; der Client ermittelt den Autorisierungsserver selbst, meldet sich an und erneuert die Zugangstoken. Wer den Ablauf von Hand starten will, ruft opencode mcp auth <name> auf.

Genau diese Bequemlichkeit war die Stelle. Der Client liest bei der Erkennung Dokumente, die der MCP-Server liefert, und öffnet am Ende eine Adresse im Browser. Pillar formuliert es so: „The whole handshake is automatic, because the entire point is to send you to a login page.“ Ein Wert aus diesen Dokumenten gelangte ohne ausreichende Prüfung in den Browser-Start. Unter macOS und Linux bleibt das folgenlos, weil die Adresse dort nicht durch eine Shell läuft. Unter Windows und WSL lief der Browser-Start über eine Shell — und damit konnte der Server mitbestimmen, was auf dem Rechner ausgeführt wird. Mehr Detail braucht es für die Verteidigung nicht, und mehr geben wir hier nicht wieder.

Zwei Eigenschaften machen den Fall unangenehm. Der Anwender muss nichts Ungewöhnliches tun; ein Login-Fenster, das sich öffnet, ist bei Remote-Servern der Normalfall. Und der Server muss nicht von Anfang an bösartig gewesen sein. Pillar nennt drei Wege, auf denen ein ehemals vertrauenswürdiger Eintrag kippt: Übernahme des Servers, Tippfehler-Domains und abgelaufene Domains. Wie Anmeldung und Identität bei Agenten grundsätzlich zusammenhängen, steht in Agenten-Identität: NHI, OAuth 2.1 und Agent Passports.

/03Kein CVE, kein Advisory: warum der Scanner schweigt

Anomaly hat laut Pillar keine CVE beantragt und kein Advisory veröffentlicht; die Bitte um Neubewertung wurde abgelehnt. The Hacker News zitiert dazu die Sicherheitsrichtlinie des Projekts, nach der vom Nutzer konfigurierte MCP-Server „outside our trust boundary“ liegen. Die Release Notes zu 1.18.33 nennen an der passenden Stelle nur einen Satz: „MCP browser launch failures are now reported when the launcher exits immediately.“ Ein Hinweis auf ein Sicherheitsproblem fehlt.

Wir haben die Advisory-Seite des Repositorys am 11. November 2026 geöffnet. Dort stehen drei Einträge — zwei vom 12. Januar 2026, einer vom 24. September 2026 —, und keiner trägt MCP oder OAuth im Titel. Der jüngste betrifft einen anderen Weg (eine seitenübergreifende Upgrade-Anfrage an den OpenCode-Server).

Für den Betrieb ist das der eigentliche Befund. Schwachstellen-Scanner, Abhängigkeits-Warnungen und die Meldungen der Softwareverteilung arbeiten mit Kennungen. Ohne CVE und ohne Advisory gibt es keine Kennung, also keinen Treffer und kein Ticket. Ein Rechner mit OpenCode 1.15 sieht im Bericht des Scanners genauso grün aus wie einer mit der aktuellen Fassung. Pillar empfiehlt deshalb ausdrücklich, Installationen im Unternehmen von Hand zu inventarisieren.

Zur Zahl 9,8: Sie stammt von den Findern und ist ein Vorschlag nach CVSS 3.1, kein offizieller Wert. Der Vektor setzt weder Rechte noch Nutzerinteraktion an. Darüber lässt sich streiten, denn der Server muss vorher in der Konfiguration stehen. Für die Priorisierung im eigenen Haus ist die Zahl weniger wichtig als die Frage, ob auf Ihren Windows-Rechnern überhaupt Remote-MCP-Server eingetragen sind.

/04Bestandsaufnahme: Version und Plattform von Hand prüfen

Gesucht sind drei Angaben je Entwicklerrechner: ob OpenCode installiert ist, in welcher Version, und ob Remote-Server konfiguriert sind. Unter Windows kommt eine Falle dazu: Jede WSL-Distribution hat ihre eigene Installation. Ein aktualisiertes OpenCode unter Windows sagt nichts über die Fassung in Ubuntu unter WSL.

# PowerShell: Installation und Version unter Windows
Get-Command opencode -All | Select-Object Source
opencode --version
npm ls -g --depth=0 | Select-String opencode

# WSL: Distributionen auflisten, dann je Distribution prüfen
wsl -l -v
wsl -d Ubuntu -- bash -lc "command -v opencode && opencode --version"

# Welche MCP-Server sind eingetragen, und wo liegt die Konfiguration?
opencode mcp list
opencode debug paths

Jede Version von 1.0.137 bis 1.18.32 auf Windows oder in WSL ist ein Befund. Aktuell ist Stand 11. November 2026 die Version 1.19.5, die GitHub als jüngstes Release mit Datum 28. Oktober führt. Aktualisiert wird auf dem Weg, auf dem installiert wurde — über npm, einen Paketmanager oder das Installationsskript —, und danach wird die Version erneut abgefragt, in Windows und in jeder WSL-Distribution.

In der Praxis: Bei fünf Entwicklern ist das eine Rundfrage mit Bildschirmfoto. Ab zwanzig Rechnern gehört die Abfrage in die Softwareverteilung oder in ein Anmeldeskript, das Version und Rechnername in eine Liste schreibt. Die Liste hat einen zweiten Nutzen: Sie zeigt, wer überhaupt Coding-Agenten einsetzt — eine Angabe, die viele IT-Leitungen heute nicht haben.

/05Remote-MCP-Server prüfen, ausdünnen, absichern

Das Update ist der erste Schritt, die Durchsicht der Serverliste der zweite. Pillar nennt für Rechner, die nicht sofort aktualisiert werden können, eine klare Ausweichmaßnahme: nicht vertrauenswürdige Remote-MCP-Server aus der Konfiguration entfernen oder das Risiko bewusst tragen. Die OpenCode-Dokumentation führt MCP-Server unter dem Schlüssel mcp.servers; die Konfiguration kann global oder als opencode.jsonc im Projekt liegen.

// opencode.jsonc — Remote-Server stilllegen, ohne den Eintrag zu löschen
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servers": {
      "tickets": {
        "type": "remote",
        "url": "https://mcp.example.com/mcp",
        "disabled": true
      }
    }
  }
}

Die Dokumentation sieht dafür ausdrücklich disabled vor, kein Feld enabled. Für Server, die ausschließlich mit einem API-Schlüssel im Header arbeiten, kennt sie außerdem "oauth": false; der OAuth-Ablauf wird für diesen Eintrag dann nicht angestoßen. Pillar führt diese Einstellung nicht als Gegenmaßnahme, und sie ersetzt das Update nicht. Sie ist aber die sauberere Konfiguration für Server, die gar kein OAuth sprechen.

Um Konfigurationen mit Remote-Einträgen zu finden, genügt eine Dateisuche — auf dem Rechner und in den Repositories, denn eine Projektkonfiguration reist mit dem Code:

# Linux, macOS, WSL
grep -rIl --include='opencode.json' --include='opencode.jsonc' '"remote"' ~ 2>/dev/null

# PowerShell
Get-ChildItem $env:USERPROFILE -Recurse -Include opencode.json,opencode.jsonc -ErrorAction SilentlyContinue |
  Select-String -Pattern '"remote"' -List | Select-Object Path

Für jeden Treffer stellen Sie vier Fragen. Wem gehört die Domain, und wer betreibt den Server? Wird der Dienst noch gebraucht? Steht die Adresse exakt so in einer freigegebenen Liste des Hauses? Und wer hat den Eintrag hinzugefügt — ein Kollege oder ein Projekt, das jemand aus dem Netz geklont hat? Einträge unter mcp.servers gehören in die Code-Durchsicht wie jede andere Abhängigkeit.

Drei Maßnahmen wirken über diesen einen Fehler hinaus:

• Freigabeliste statt Einzelfall. Das Haus führt eine kurze Liste erlaubter MCP-Server mit vollständiger Adresse und Verantwortlichem. Alles andere wird nicht eingetragen.
• Ausgehenden Verkehr begrenzen. Entwicklerrechner erreichen MCP-Gegenstellen nur über einen Proxy, der die Freigabeliste durchsetzt. Eine abgelaufene oder vertippte Domain läuft dann ins Leere.
• Geheimnisse vom Agenten trennen. Der Coding-Agent läuft in einer Umgebung, in der keine SSH-Schlüssel für Produktivsysteme und keine Cloud-Zugangsdaten liegen. Das gleiche Prinzip haben wir bei GitSpawn und der Git-Konfiguration beschrieben.

/06Grenzen: was das Update nicht löst

Version 1.18.33 behebt einen Weg, auf dem Daten eines Servers in einen lokalen Aufruf gelangten. Die Haltung des Herstellers bleibt: Ein bösartiger MCP-Server liegt außerhalb seines Bedrohungsmodells. Das ist eine vertretbare Position — und sie hat eine Folge. Der nächste Fehler dieser Art wird voraussichtlich wieder ohne Advisory behoben, und Sie erfahren davon aus einem Forscherbericht oder gar nicht.

Weitere Grenzen:

• Ein eingetragener Server bleibt mächtig. Auch ohne diesen Fehler liefert er Werkzeugbeschreibungen und Ergebnisse, die das Modell als Kontext liest. Was sich darüber anrichten lässt, steht in MCP-Sicherheit: Tool Poisoning.
• Lokale Server sind keine sichere Ausweichroute. Ein MCP-Server, der als lokaler Prozess startet, führt bestimmungsgemäß Code auf dem Rechner aus. Er verschiebt die Vertrauensfrage auf das Paket, aus dem er stammt.
• Es gibt keine Erkennungsmerkmale. Laut The Hacker News hat Pillar keine Hinweise auf eine Ausnutzung gefunden und keine Kompromittierungs-Indikatoren veröffentlicht. Ob ein Rechner zwischen Dezember 2025 und dem Update angegriffen wurde, lässt sich deshalb nicht gezielt prüfen.
• Die Handprüfung altert. Eine Versionsliste vom November sagt nichts über den Rechner, der im Januar neu aufgesetzt wird. Ohne Inventar in der Softwareverteilung wiederholt sich die Arbeit.

Ehrlich: Für ein Haus, dessen Entwickler ausschließlich unter macOS oder Linux arbeiten, ist diese Lücke nach Angabe der Finder kein Befund. Und für ein Haus ohne Coding-Agenten ist der ganze Artikel eine Randnotiz. Die Frage, welche Remote-MCP-Server in den Konfigurationen stehen, bleibt in jedem Fall sinnvoll — sie gilt für jeden MCP-Client, nicht nur für diesen.

/07Entscheidung: wer handeln muss und wer nicht

Die zweite Zeile wird gern übersehen. Ein Rechner ohne Remote-Server ist heute nicht angreifbar, trägt aber eine Fassung, in der ein einziger neuer Konfigurationseintrag genügt. Das Update kostet Minuten, die Erklärung nach einem Vorfall deutlich mehr.

Ob ein Haus Coding-Agenten mit Remote-MCP-Servern überhaupt zulassen sollte, hängt an der Größe der Entwicklung. Bei zwei bis fünf Entwicklern genügen eine Freigabeliste, eine Versionsabfrage im Quartal und die Regel, dass Projektkonfigurationen durchgesehen werden. Ab etwa zwanzig Entwicklern trägt das nicht mehr: Dann braucht es ein Inventar in der Softwareverteilung, einen Proxy für ausgehende MCP-Verbindungen und eine benannte Stelle, die neue Server freigibt. Wer weder das eine noch das andere leisten will, fährt mit einem Verbot von Remote-Servern auf Entwicklerrechnern besser als mit einer Duldung ohne Überblick.

/08Was der Fall über MCP-Clients lehrt

Der Fehler ist klassisch: Daten einer Gegenstelle landen in einem Aufruf des Betriebssystems. Neu ist die Umgebung. Ein MCP-Client führt Erkennung, Anmeldung und Verbindungsaufbau selbsttätig aus, und er tut das mit den Rechten des Entwicklers. Die Werkzeugnutzung des Modells kommt erst danach. Schutzmaßnahmen, die am Modell ansetzen — Guardrails, Bestätigungsdialoge, ein Mensch in der Schleife —, greifen an dieser Stelle nicht, weil kein Modell beteiligt ist.

Für Häuser, die eigene MCP-Clients oder eigene Agenten bauen, nennt Pillar drei Regeln für Entwickler: Adressen als Argumentliste an den Browser-Start übergeben statt als Shell-Befehl; die Erkennung an den konfigurierten Server binden; und Schema-Prüfungen nicht als alleinige Maßnahme verstehen. Das Anheben der Bibliothek open auf 11.0.0 oder neuer helfe, sei aber nur eine zusätzliche Absicherung. Diese Regeln gehören in die Durchsicht jedes Werkzeugs, das im Namen eines Agenten Programme startet — gleich ob es um Function Calling gegen eine interne API oder um einen zugekauften Client geht.

Für alle anderen bleibt eine Einkaufsfrage. Wer einen KI-Assistenten für die Entwicklung auswählt, sollte nachlesen, was der Hersteller als eigenes Bedrohungsmodell beschreibt und wie er Sicherheitskorrekturen meldet. Ein Projekt, das Fehler stillschweigend behebt, ist nicht unsicherer als eines mit Advisory — aber es verlangt von Ihnen, Versionen aktiv nachzuhalten. Das gilt auch dort, wo Agentic AI vollständig on-premise läuft: Der Server im eigenen Rack schützt die Daten im Modell, nicht den Entwicklerrechner davor, einer fremden Gegenstelle zu vertrauen. Wer die eigene Umgebung dagegen prüfen will, nimmt „Remote-MCP-Server liefert präparierte Antworten“ als festen Fall in das nächste Red-Teaming auf.