De OpenCode MCP-kwetsbaarheid draait om één scenario dat ontwikkelaars mogelijk direct willen uitsluiten: tijdens het aanmelden kan een (kwaadaardige of overgenomen) MCP-server code laten uitvoeren op iemands Windows– of WSL-machine. Het gaat om een fout in hoe OpenCode een adres (OAuth authorization endpoint) doorgeeft aan een browser-launcher.
De leverancier heeft de oplossing uitgerold in versie 1.18.33, maar omdat er geen CVE of publiek security-advisory is gepubliceerd, blijven veel scanners en dependency-alerts stil. Dat maakt snelle upgrade en lokale controle extra belangrijk.
Wat is er precies mis bij OpenCode MCP-kwetsbaarheid?
OpenCode gebruikt MCP (Model Context Protocol)-servers om extra tools van buiten het project te kunnen gebruiken. In het beschreven incident kan een MCP-server tijdens het authenticatieproces een webadres teruggeven dat de gebruiker moet openen via de OAuth-stroom.
Op Windows en WSL geeft OpenCode dat adres door aan een helper die het vervolgens in een browser opent. In plaats van het adres veilig te verwerken, bouwt die helper een PowerShell-opdracht op zonder de inhoud afdoende te ontsnappen. Hierdoor kan een adres dat “code” draagt, die code laten uitvoeren.
Wanneer vindt de aanval plaats?
De code wordt niet “automatisch” uitgevoerd als je een MCP-server hebt geconfigureerd. Het browser-stappenplan komt pas in beeld wanneer een ontwikkelaar daadwerkelijk een aanmeldactie start, bijvoorbeeld door opencode mcp auth te draaien of door de bijbehorende authenticatie-aanroep te doen.
Met andere woorden: wie alleen een MCP-server heeft toegevoegd, maar nooit de specifieke auth-flow activeert, ziet de fout niet triggeren. Maar in een ontwikkelomgeving is dat proces vaak precies de handeling die je doet—waardoor het risico reëel wordt zodra een MCP-server onbetrouwbaar is.
Waarom een overgenomen server ook gevaarlijk kan zijn
De essentie van deze OpenCode MCP-kwetsbaarheid is dat de aanvaller controle nodig heeft over een remote MCP-server die jij als gebruiker hebt toegevoegd. Het serveradres hoeft niet vanaf dag één kwaadaardig te zijn.
Een server kan bijvoorbeeld later worden overgenomen, of een domein dat door zo’n server wordt gebruikt kan van eigenaar wisselen. In beide gevallen kan dezelfde route alsnog een schadelijk adres teruggeven zodra iemand opnieuw inlogt via OpenCode.
Windows en WSL, niet macOS en niet Linux
De impact beperkt zich tot OpenCode op Windows en OpenCode op WSL. Voor macOS en Linux meldt de bron dat OpenCode daar een andere aanpak gebruikt: de browser wordt geopend zonder de URL via een shell-achtige route te laten lopen. Daardoor wordt het specifieke command-injection pad niet geactiveerd.
Dat is goed nieuws voor teams die macOS/Linux gebruiken, maar het neemt niet weg dat Windows/WSL-werkplekken prioriteit moeten krijgen in je herstelplan.
Welke versie moet je draaien?
De fix is beschikbaar gesteld in OpenCode 1.18.33 (geleverd op 28 september). De kwetsbare versies lopen volgens de bron van 1.0.137 tot en met 1.18.32.
Omdat er geen CVE en geen publieke security advisory is, zullen veel automatische tools de kwetsbaarheid niet herkennen. Je moet daarom zelf checken welke versie je draait.
Waarom scanners het laten liggen
Een belangrijk frustrerend punt: zonder CVE verschijnen er geen reguliere signalen in vulnerability scanners of dependency alerts. De bron geeft aan dat het vinden van getroffen installs neerkomt op het versienummer handmatig controleren.
Dit sluit aan bij een breder patroon in beveiligingsnieuws: je kunt als organisatie niet blind varen op tooling als publicatie ontbreekt. Wil je nog zo’n casus zien rond patch- en herkenningsproblemen? Lees dan ook PHP2Shell: dagen vóór patches al misbruikpogingen.
Wat kun je nu doen (praktisch stappenplan)
Als je OpenCode gebruikt op Windows of WSL, pak dan de volgende stappen op. Ze zijn in lijn met het advies uit de bron en richten zich op directe risicoreductie.
- Upgrade naar OpenCode 1.18.33 of later. Dit is de kernmaatregel om de fout te dichten.
- Verwijder of blokkeer remote MCP-servers die je niet vertrouwt. Als je niet zeker weet wat een MCP-server doet of hoe die beheerd wordt, haal hem weg totdat je hem hebt geverifieerd.
- Inventariseer welke MCP-servers zijn geconfigureerd. Gebruik hiervoor opencode mcp list om te zien wat er onder jouw instellingen hangt.
Hoewel Pillar Security meldt dat er geen tekenen zijn gevonden dat de fout al is misbruikt, is dat geen reden om te wachten. De impact is namelijk door de onderzoekers als kritiek beoordeeld, met een voorgestelde ernstscore van 9,8 op 10.
Extra context: relatie met andere issues
De bron legt uit dat de kwetsbaarheid losstaat van een ander gemeld incident rond de OpenCode hosted Console, waarbij sommige gebruikers mogelijk opgeslagen API-sleutels voor diensten als OpenAI, Anthropic en Google blootgesteld kregen. Toch zijn beide gebeurtenissen relevant voor IT-teams: het ene gaat over runtime code execution tijdens auth, het andere over potentiële exposure van opgeslagen credentials.
Daarnaast wordt genoemd dat dit type fout eerder opduikt. In juli 2025 was er een vergelijkbare bug in de mcp-remote proxy, waarbij een authorization endpoint uiteindelijk op de command line terechtkwam en leidde tot een CVE (CVE-2025-6514).
Waarom “alleen HTTPS” hier niet helpt
Een veelgebruikte veronderstelling bij URL-gedreven aanvallen is dat “als het HTTPS is, zit je veilig”. In dit geval werkt die redenering niet: de aanval maakt gebruik van een normale HTTPS-URL. Het probleem zit niet in het protocol, maar in de manier waarop OpenCode en de browser-launcher het adres verwerken (het gebrek aan veilige ontsnapping in de helper).
OpenCode voerde wel checks in om het gebruik van bepaalde URL-eigenschappen te controleren, maar de bron geeft aan dat de echte remedie uiteindelijk kwam door de fix in 1.18.33.
Beveiligingsfocus: vertrouw je MCP-servers echt?
Een terugkerend punt in de bron is de trust boundary. De leverancier hanteert een standpunt dat MCP-servers die gebruikers configureren buiten hun directe vertrouwensgrens vallen. Met andere woorden: als jij zelf een MCP-server toevoegt, beschouwt de leverancier die als jouw verantwoordelijkheid qua betrouwbaarheid.
Dat schuift het risico deels naar ontwikkelteams en platformbeheerders. In de praktijk betekent dat: duidelijke policy voor welke MCP-servers je toelaat, hoe je ze beoordeelt en hoe je omgaat met mogelijke overnames of domeinwijzigingen.
Conclusie
De OpenCode MCP-kwetsbaarheid is een ernstig risico voor teams die OpenCode gebruiken op Windows en WSL. Tijdens het aanmelden kan een kwaadaardige of overgenomen MCP-server via de OAuth authorization endpoint leiden tot code-uitvoering, omdat OpenCode de URL onveilig verwerkt in een PowerShell-stap.
De oplossing is helder: upgrade naar OpenCode 1.18.33, controleer welke MCP-servers je hebt toegevoegd met opencode mcp list en verwijder servers die je niet kunt verifiëren. Omdat er geen CVE en geen publieke advisory is, moet je dit vooral zelf actief oppakken—wachten op scanner-detectie helpt nu niet.
Bron: https://thehackernews.com/2026/10/opencode-flaw-lets-malicious-mcp.html
