El inicio de sesión MCP de OpenCode entregó la URL de un servidor a PowerShell — y no existe ningún CVE que lo señale

El 19 de octubre de 2026 Pillar Security reveló una vulnerabilidad de ejecución remota de código en OpenCode, el agente de programación de código abierto mantenido por Anomaly: un servidor remoto Model Context Protocol que un desarrollador había configurado podía ejecutar código arbitrario en la propia máquina de ese desarrollador durante el inicio de sesión OAuth de MCP, sin ningún aviso de consentimiento de por medio. El error se limitaba a Windows y al Windows Subsystem for Linux, donde OpenCode entregaba la URL de inicio de sesión proporcionada por el servidor a un comando de PowerShell sin escaparla. Pillar sitúa el rango afectado entre 1.0.137 y 1.18.32. Anomaly lo corrigió en 1.18.33, que se publicó en npm el 28 de septiembre de 2026, y no solicitó ningún CVE ni publicó ningún aviso — así que nada en un feed normal de vulnerabilidades indicará a un equipo afectado que debe actualizar. Pillar no reportó ninguna evidencia de que la falla se haya usado alguna vez en un ataque. Este es un registro en el archivo de incidentes de IA, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.

Cuál era realmente el fallo

Cuando un cliente MCP se conecta a un servidor remoto que requiere autorización, ejecuta un protocolo de descubrimiento OAuth. El servidor responde con un 401 y un desafío que apunta a sus documentos de descubrimiento, y uno de los campos de esos documentos — authorization_endpoint — indica al cliente dónde enviar al usuario para iniciar sesión. Es una cadena de formato libre, y la parte que se autentica es la que la elige.

En OpenCode 1.18.32, esa cadena pasó de la red a un shell. Pillar siguió la ruta desde el documento de descubrimiento del servidor a través del SDK de MCP hasta oauth-provider.ts, mcp/index.ts y browser.ts, terminando en open, el pequeño paquete que OpenCode usa para lanzar un navegador. Nada en esa ruta comprobó el esquema de la URL, y nada lo comparó con el origen del servidor que el desarrollador había configurado. El handshake es automático por diseño —el objetivo es enviarte a una página de inicio de sesión sin hacerte copiar una URL—, así que ningún paso de aprobación se interponía entre la respuesta del servidor y el lanzador.

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.

Dos propiedades hicieron que fuera fácil pasarlo por alto. La carga útil no contiene espacios, por lo que la normalización de URL la deja intacta, y es una dirección de tipo https sintácticamente normal. Y el servidor no tenía por qué ser hostil en el momento de configurarse: Pillar señala que un compromiso posterior, una entrada de registro secuestrada, un typosquat o un dominio caducado convertirían cada uno una entrada de configuración confiable en un mecanismo de entrega.

¿Quién estuvo expuesto?

La población expuesta son los usuarios de Windows y WSL que ejecutan OpenCode con un servidor MCP remoto configurado. Pillar describe que OpenCode tiene aproximadamente 3 millones de descargas semanales en npm y 211.000 estrellas en GitHub; el informe de Infosecurity Magazine sitúa el número de estrellas en más de 218.000. Ninguna de las cifras es un recuento de instalaciones afectadas, y nadie ha publicado ninguno.

El desencadenante es el único punto en el que las dos versiones principales divergen, y es importante tanto para el riesgo como para la gravedad. Pillar describe la explotación como algo que no requiere interacción ni consentimiento adicionales por parte del usuario. The Hacker News, en su informe del 22 de octubre, afirma que el paso del navegador solo se ejecuta cuando un desarrollador inicia el inicio de sesión —ejecutando opencode mcp auth o realizando la solicitud correspondiente— y que el mero hecho de tener el servidor configurado, o abrir una sesión, no llega a ese paso. En cualquier caso, el desarrollador no hace nada inusual; iniciar la autenticación contra un servidor que ya está en la configuración es rutinario. Pero «ninguna interacción» y «una interacción rutinaria» son afirmaciones distintas, y la diferencia influye directamente en la puntuación.

La corrección llegó descrita como una refactorización.

Pillar reportó la falla de forma privada a través de un Aviso de Seguridad de GitHub el 29 de agosto de 2026, con material de reproducción completo. El 25 de septiembre, hizo seguimiento fuera del hilo del aviso; Anomaly confirmó que el informe había llegado a su equipo y respondió que los servidores MCP maliciosos quedaban fuera de su modelo de amenaza. Ese mismo día, se integró la solicitud de extracción #51414 —fusionada como el commit 29f07e0c—. Se describe como la consolidación de ocho puntos de llamada de lanzamiento del navegador en un único helper. La versión 1.18.33 llegó a npm tres días después, el 28 de septiembre.

El parche tiene tres capas. La dependencia open pasó a 11.0.4, que envuelve el objetivo entre comillas simples, y PowerShell no expande nada dentro de comillas simples. Un nuevo openUrl() auxiliar rechaza esquemas que no sean HTTP(S). Se añadió una comprobación de esquema en el propio redirectToAuthorization, en el límite que Pillar había nombrado en su informe. Ni la solicitud de extracción ni las notas de la versión mencionan una falla de seguridad, y Anomaly no solicitó ningún CVE.

The Hacker News informa que la política de seguridad publicada por Anomaly establece que los servidores MCP que configura un usuario están "fuera de nuestro límite de confianza", y que la empresa ha emitido avisos por otras fallas de ejecución de código de OpenCode este año, incluida una corregida en agosto. La versión de Pillar sobre la respuesta que recibió es más directa: "hemos actualizado la dependencia, pero, por lo general, tratar con un servidor MCP malicioso está fuera de nuestro modelo de amenazas".

Leída como una secuencia, la línea de tiempo sitúa el bug de OpenCode al final de un rastro de cinco años en lugar del comienzo de uno. El defecto que lo produjo ya era público, y su corrección ya se había lanzado, antes de que se escribiera la línea que lo usaba.

Por qué la validación del esquema no lo habría detenido

El remedio acordado para esta clase de error es la validación del esquema de URL: bloquear los esquemas extraños, permitir http y https, y listo. Es lo que incluye el MCP TypeScript SDK, y es lo que OpenCode añadió en 1.18.33. La carga útil de Pillar pasa todas y cada una de esas comprobaciones, porque es https. La lista de denegación del SDK bloquea javascript:, data: y vbscript:; una lista de permitidos http/https más estricta se propuso en la pull request #841 del SDK en agosto de 2025 y se cerró sin fusionarse, mientras que la pull request #877 publicó la lista de denegación de tres esquemas en v1.17.4 — y Pillar dice que esa seguía siendo la política en SDK 1.32.0 cuando se publicó. Lo que realmente cerró el agujero en OpenCode fue la actualización de dependencia, no las comprobaciones que parecen la corrección de seguridad.

La historia sostiene que no se debe tratar esto como un desliz de un solo proyecto. El paquete open lleva desde 2021 una advertencia en el README de que no ofrece garantías de seguridad y de que sanear la entrada es responsabilidad de quien lo llama. En octubre de 2020, un usuario presentó el issue #202 informando de que una URL que contenía un signo de dólar perdía parte de sí misma en WSL 2 —la expansión de la cadena, registrada como una molestia por enlace roto. En octubre de 2023, un ingeniero de Adobe presentó el issue #323, «inyección de comandos del sistema operativo en Windows al abrir URL», con una prueba de concepto de una línea: open('https://$(calc.exe)'). El mantenedor citó el README y dijo que serían bienvenidas las pull requests que mejoraran el escape; el issue se cerró como no planificado tres días antes de que open 11.0.0 distribuyera el escape de todos modos, el 15 de noviembre de 2025. OpenCode escribió su llamada de lanzamiento del navegador el 7 de diciembre de 2025, tres semanas después de que existiera la versión corregida de open, contra una versión fijada que ya tenía meses de antigüedad.

En los meses previos a que se escribiera esa llamada, el ecosistema MCP registró tres CVE sobre el mismo sumidero o el mismo campo: CVE-2025-6514 en mcp-remote (CVSS 9.6, divulgado por JFrog el 9 de julio de 2025), CVE-2025-58062 en openmcp-client, y CVE-2025-10619 en sequa-mcp. El contraste que plantea Pillar es con los clientes que nunca construyen un comando de shell a partir de una cadena remota: menciona gemini-cli, Claude Code, github-mcp-server y mcp-gateway de Docker como casos que pasan la URL como un vector de argumentos, lo que hace que la cuestión de qué contiene la cadena deje de ser determinante.

Qué está establecido, y qué no

El registro está calificado con confianza A por el archivo, y la cobertura periodística que lo respalda se sostiene. Infosecurity Magazine publicó el 20 de octubre su propia entrevista con Eilon Cohen, de Pillar; The Hacker News publicó su propio relato el 22 de octubre; DKCERT, el CERT nacional de Dinamarca, resumió el hallazgo el 21 de octubre citando a Infosecurity; y el laboratorio de investigación de Cloud Security Alliance publicó un análisis que añade la única salvedad sustantiva que figura abajo. Ninguno de ellos es la parte informante, y coinciden en el mecanismo, las versiones y la corrección silenciosa. Anomaly no ha publicado nada sobre la vulnerabilidad.

Establecido, que conste en acta:

• El defecto, su mecanismo y su alcance en las plataformas. Pillar identifica líneas de código fuente concretas y la corrección es visible en el diff público de 1.18.32 a 1.18.33; los dos reportajes periodísticos independientes describen el mismo flujo de datos.

• El rango afectado, de 1.0.137 a 1.18.32, y la versión corregida, 1.18.33, publicada el 28 de septiembre de 2026.

• Que no existe ninguna CVE ni ningún aviso. Esto es verificable, y es el hecho fundamental para los defensores.

• Que no se ha informado de ninguna explotación. Pillar afirma que no vio indicios de uso en ataques, y The Hacker News señala que no se publicaron indicadores de compromiso. La ausencia de indicadores publicados no es prueba de ausencia, y sin telemetría del proveedor no se puede confirmar ninguna de las dos lecturas.

No establecido, o en tensión:

• La puntuación 9.8. Ese número es la puntuación CVSS v3.1 propuesta por Pillar, no una oficial: al no haber CVE, no existe puntuación del NVD ni puntuación del proveedor. La nota de investigación de Cloud Security Alliance señala que 9.8 supone que no hay interacción del usuario y que, si la versión de The Hacker News sobre el desencadenante es correcta, encajaría mejor una calificación que requiera interacción del usuario —aproximadamente 8.8—. Este artículo no resuelve eso; la propia etiqueta de alta severidad del archivo es una clasificación, no una puntuación.

• La fecha de publicación. El informe de Pillar está fechado el 19 de octubre de 2026 en su encabezado, y ambas crónicas periodísticas usan esa fecha; la cronología de divulgación al pie del propio informe de Pillar indica como publicación el 4 de octubre. El archivo registra el 19 de octubre con precisión de día.

• El tamaño de la población expuesta. No se ha publicado ningún recuento. Las cifras de descargas y estrellas mencionadas anteriormente son métricas del repositorio, no instalaciones.

• Si realmente se comprometió alguna máquina. Nada de lo publicado lo respalda, y el registro no conlleva ningún daño real.

Qué cambió y qué hacer

La remediación consiste en una verificación de versión, porque ninguna otra cosa te lo dirá. OpenCode 1.18.33 o posterior está corregido. Las instalaciones afectadas deben localizarse inventariando el paquete directamente: la recomendación de Pillar es inventariar OpenCode en sí mismo en lugar de esperar un feed, y la nota de Cloud Security Alliance sugiere consultar la versión del paquete opencode-ai, ya que no hay ningún identificador que un feed pueda comparar. Los equipos que no puedan actualizar y que ejecuten Windows o el Subsistema de Windows para Linux deben eliminar de su configuración de OpenCode los servidores MCP remotos que no hayan validado; opencode mcp list muestra qué servidores están presentes.

Para cualquiera que mantenga un cliente MCP, la orientación de Pillar es más acotada que el consejo habitual: pasar las URL como un vector de argumentos y no construir nunca una línea de comandos a partir de una cadena remota, vincular el descubrimiento de OAuth al origen del servidor que configuró el usuario, y tratar los documentos de descubrimiento, los metadatos del servidor y los descriptores de herramientas como entrada no confiable en lugar de como configuración. La nota de Cloud Security Alliance añade heurísticas de caza —un proceso de OpenCode que inicia powershell.exe con -EncodedCommand, por ejemplo — mientras subraya que son sugerencias para la ingeniería de detección, no indicadores de compromiso publicados.

No es la brecha de Console

La revelación de Pillar se produjo días después de que Anomaly confirmara una brecha separada en la Console alojada de OpenCode, que podría haber expuesto claves de proveedores de API almacenadas. Los dos eventos no están relacionados, y Eilon Cohen, de Pillar, fue explícito sobre la diferencia en su entrevista con Infosecurity Magazine. «La brecha afectó a un sistema heredado detrás de un proxy de claves alojado y expuso claves de proveedores que los usuarios habían almacenado allí», dijo. «La vulnerabilidad que reportamos va en la dirección opuesta: un servidor MCP remoto malicioso que ejecuta código en la propia máquina de un desarrollador durante el handshake de OAuth. Un objetivo y una posición del atacante diferentes». La brecha de Console es un registro separado en el archivo, y ambos deben leerse como entradas separadas.

Lo que los vincula, en el planteamiento de Cohen, es la pregunta que subyace a ambos: «¿A quién dejas entregar credenciales y entradas a una herramienta de programación con IA, y qué hace esa herramienta con ellas?».

La brecha de divulgación es la parte que sobrevive al fallo. Un defecto que quienes lo descubrieron califican de crítico, corregido dentro de una actualización de dependencia y ausente de todas las señales automatizadas en las que normalmente se basa un defensor deja el inventario directo como el único método de detección — y el proveedor no publicó ningún aviso que indicara a nadie que realizara uno.