Descubren una vulnerabilidad de ejecución remota de código sin autenticación en OpenCode

• Se descubrió una vulnerabilidad crítica de ejecución remota de código en versiones antiguas de OpenCode que permite ejecutar código arbitrario sin autenticación
• Las versiones anteriores a v1.1.10 ejecutan automáticamente un servidor HTTP, y este servidor permite ejecutar comandos arbitrarios, leer archivos y crear sesiones de terminal sin ningún proceso de autenticación
• Antes de v1.0.216, con solo visitar un sitio web podía ejecutarse código en el entorno local del usuario
• En la versión más reciente (v1.1.10), el servidor viene desactivado por defecto, pero si se habilita sigue sin autenticación
• Esta vulnerabilidad fue registrada como CVE-2026-22812, y desarrolladores y usuarios deben actualizar de inmediato y revisar su configuración

---

Resumen de la vulnerabilidad

• OpenCode es un asistente de programación con IA de código abierto y, antes de v1.1.10, al ejecutarse iniciaba automáticamente un servidor HTTP (puerto predeterminado 4096+)
  • El servidor ofrece endpoints como POST /session/:id/shell, POST /pty, GET /file/content
  • Al no haber autenticación, cualquier cliente con capacidad de conexión puede ejecutar código con los permisos del usuario
• No hay ningún indicador visual para el usuario cuando el servidor está en ejecución, por lo que es difícil notar si está expuesto
• La política CORS estaba codificada de forma fija como *.opencode.ai, por lo que las páginas servidas desde opencode.ai o sus subdominios pueden acceder a la API del servidor
  • Si ese dominio se ve comprometido o existe una vulnerabilidad XSS, todos los usuarios con el servidor habilitado pueden convertirse en objetivo de ataque

Vectores de ataque

• Antes de v1.0.216: cualquier sitio web podía ejecutar código en la máquina local de un usuario que estuviera usando OpenCode
• Antes de v1.1.10: procesos locales o páginas en localhost podían ejecutar código sin autenticación
• En todas las versiones, si el servidor está habilitado:
  • Procesos locales y páginas en localhost pueden ejecutar código sin autenticación
  • Si se usa la bandera --mdns, todos los dispositivos de la red local pueden acceder
  • No hay indicación de que el servidor esté en ejecución, por lo que el usuario puede no notar que está expuesto
  • Se puede ejecutar código desde el dominio opencode.ai o sus subdominios

Ejemplos de ataque (Proof of Concept)

• Ataque local: cuando el servidor está en ejecución, un proceso local puede crear una sesión con el comando curl y luego ejecutar id > /tmp/pwned.txt
• Ataque basado en navegador (antes de v1.0.216): una página web puede enviar comandos al servidor local mediante una solicitud fetch y descargar y ejecutar scripts remotos
  • Se confirmó que funciona en Firefox; Chrome puede mostrar un cuadro de confirmación por las protecciones de acceso a la red local

Medidas para usuarios

• Verificar la versión con opencode --version y actualizar a v1.1.10 o superior
• Revisar en el archivo de configuración si están habilitadas las opciones server.port o server.hostname
• No usar la bandera --mdns (se enlaza a 0.0.0.0 y queda expuesto a toda la red)
• Si es indispensable usar el servidor, no acceder a opencode.ai ni a sus subdominios
• Tener presente que, si el servidor está habilitado, los procesos locales pueden acceder sin autenticación

Cronograma de divulgación

• 2025-11-17: primer reporte por correo electrónico, sin respuesta
• 2025-12-27: envío de GitHub Security Advisory, sin respuesta
• 2025-12-29: otro usuario publica el reporte
• 2025-12-30: se aplica una restricción CORS en v1.0.216
• 2026-01-09: en v1.1.10 el servidor queda desactivado por defecto
• 2026-01-11: divulgación completa

Acciones recomendadas

• Restringir CORS al mínimo de dominios necesario (aplicado en v1.0.216)
• Desactivar el servidor por defecto (aplicado en v1.1.10)
• Agregar autenticación a todas las solicitudes al servidor
• Proporcionar al usuario una indicación clara cuando el servidor esté en ejecución
• Documentar que la opción --mdns se enlaza a 0.0.0.0
• Aplicar TLS en las comunicaciones de red
• Publicar oficialmente GitHub Security Advisory y CVE-2026-22812
• Reforzar el monitoreo del correo de reportes de seguridad y de las alertas de GHSA
• Aclarar la relación de confianza entre los mantenedores de OpenCode, opencode.ai y los usuarios

Referencias

• CVE: CVE-2026-22812
• Paquete afectado: npm opencode-ai
• Información más reciente y contacto: cy.md

[GN⁺]

Comentarios en Hacker News

• Como mantenedor, reconozco que no respondí adecuadamente a este reporte de seguridad
  El uso aumentó de golpe, se acumularon los issues y esta semana planeamos reunirnos con especialistas para impulsar un programa de bug bounty y una auditoría de seguridad

  • Más que gastar dinero en un bug bounty o una auditoría, habría que invertir en reorganización interna y capacitación del personal
    Lo más importante es que todo el equipo entienda y aplique la guía de OWASP sobre diseño inseguro
  • Al principio lo vi de forma positiva, pero me preocupa que las personas que reportaron la vulnerabilidad contactaron varias veces y no recibieron respuesta
    Como OpenCode es un agente de programación open source bastante conocido, existe la posibilidad de que ya haya sido explotado
    Incluso ahora, creo que hace falta ejecutar el modelo en un entorno sandbox como gVisor
    Si no responden rápido, podrían aparecer más atacantes buscando vulnerabilidades de RCE
  • El proyecto creció demasiado rápido y parece que llegó el momento en que la gestión organizacional es más importante que desarrollar código
    Me pregunto si también están tomando como referencia algo como principios anarquistas de organización
  • ¿Y si simplemente le piden a Claude que arregle el problema de seguridad?
  • Da gusto ver que comparten la situación con honestidad y asumen la responsabilidad. No es fácil, gracias por eso

• Mucha gente está ejecutando herramientas como OpenCode en entornos locales sin separación de privilegios
  Los plugins también están diseñados por defecto asumiendo acceso sin límites, y además consumen muchos recursos
  Como mínimo, conviene ejecutarlo dentro de un dev-container o una VM, y conectar solo los archivos necesarios mediante SSHFS o Samba
  Si da flojera, también sirve usar un VPS de 5 dólares al mes

  • Me gustaría saber si pueden explicar en detalle cómo configurar un dev-container o una VM
  • Claude pide solicitudes de permiso cada vez que se ejecuta, así que en ese punto es un poco más seguro
  • Como sandbox para AI, sprites.dev de fly.io está bastante bien
    Para correr servidores con qemu, recomiendo quickemu
    La función SSH remote de zed también es útil, así que se puede usar junto con Claude Code u OpenCode

• La corrección de CORS evitó el abuso desde sitios web externos, pero el problema de fondo es una arquitectura que permite ejecutar código desde localhost
  Neovim usa por defecto sockets de dominio, y el daemon SSH de VS Code tiene un proceso de autenticación
  Un servidor local que ejecuta entradas del cliente sin autenticación es una vulnerabilidad de LCE (Local Code Execution),
  y si se vuelve accesible mediante peticiones del navegador, escala a RCE (Remote Code Execution)

• Es impactante que hayan puesto en una herramienta CLI un endpoint HTTP con RCE sin autenticación, y encima le hayan añadido una evasión de CORS

  • Parece que los laboratorios de AI deberían dejar de entrenar modelos con código de tutoriales
  • Con un servidor así de expuesto, casi sorprende más que la política de CORS no haya sido "*"
  • También hubo quien dijo que “parece código hecho solo por vibes”

• El problema es el calendario de divulgación de la vulnerabilidad
  Fue reportada el 2025-11-17, pero no hubo respuesta pese a varios intentos de contacto

  • Ahora parece que los desarrolladores sí están intentando responder seriamente
    Ver el comentario en el issue de GitHub
  • También hubo bromas como “hoy todos están en vibe coding, así que los problemas de seguridad son bad vibes”

• Aunque el servidor venga apagado por defecto, si se enciende sigue siendo grave
  Desde localhost, cualquier página web puede ejecutar código, y también lanzar procesos locales sin autenticación
  Tampoco hay ningún indicador que le avise al usuario si el servidor está corriendo
  Las apps TUI suelen ser confiables precisamente porque no hacen este tipo de cosas, y esto daña gravemente esa confianza

  • También hubo quien preguntó por qué el problema sería específicamente que fuera una app TUI
  • Como alternativa, alguien comentó que Droid de Factory parece una buena opción

• Sorprende que OpenCode reciba apoyo de YC (Y Combinator)
  Uno esperaría que YC fomentara una mejor cultura de seguridad

  • También hubo reacciones cínicas diciendo que para YC todo se reduce al dinero
  • Antes hubo un caso de Flock, también de YC, que hardcodeó contraseñas 53 veces
    Más contexto en este comentario
  • Además, es irónico que OpenCode también haga un producto de proveedor de autenticación

• Pensé que OpenCode era un proyecto voluntario, pero resultó ser un proyecto empresarial respaldado por grandes inversionistas

  • Además del repositorio oficial de GitHub, había un proyecto competidor hecho por el equipo de charm.sh
  • Probablemente se referían a proyectos como crush, roocode o kilo. Ellos todavía no tienen patrocinio grande

• Dejé de usarlo porque seguían agregando funciones y descuidaban el mantenimiento central
  La idea era usar varios modelos al mismo tiempo, pero compartir contexto es ineficiente, así que en la práctica pierde utilidad
  Ahora uso Claude Code y Codex en paralelo
  Aun así, sigue siendo grande la necesidad de una plataforma abierta que integre varios modelos

  • Recomiendan la combinación de ampcode(enlace) y Crush(enlace) + z.ai GLM
    Con ampcode se pueden hacer scripts simples gratis, y Crush+GLM sigue bien los planes de Claude o Codex
  • También hay quien opina que es más difícil mantener la disciplina de revisión y control de calidad que agregar funciones nuevas

• Al principio me gustaba Aider, pero como casi no tiene mantenimiento, seguido me daba problemas
  Estaba por instalar OpenCode, pero después de ver esto ahora lo estoy pensando dos veces
  Sorprende lo poco que abundan los asistentes CLI open source de LLM no atados a un modelo específico