PUBLICADO EL 17 DE OCTUBRE DE 2026
Archon, el agente de IA para programadores, tiene una falla CVSS 9.8: su API de control no tiene autenticación y escucha en todas las interfaces — y todavía no hay parche
El CVE-2026-111322, publicado el 16 de octubre, afecta a Archon versiones 0.2.13 hasta 0.11.1 y recibe una puntuación CVSS de 9.8. La falla es la más simple y la más grave: la API que controla el agente no tiene ningún mecanismo de autenticación y por defecto abre su puerto en todas las interfaces de red del sistema. Si Archon está corriendo en un servidor con IP pública o en una máquina dentro de una red con acceso externo, cualquiera que pueda llegar al puerto tiene control total — sin contraseña, sin token, sin nada. No hay parche del fabricante al momento de publicar este artículo.
El 16 de octubre se publicó el CVE-2026-111322 para Archon, el agente de IA de código abierto para automatizar tareas de programación. La puntuación CVSS es 9.8 sobre 10. Afecta todas las versiones desde 0.2.13 hasta 0.11.1. No hay parche disponible.
Si tenés Archon corriendo en un servidor: revisá ahora si el puerto está expuesto. La instrucción está al final de este artículo.
Qué hace Archon y por qué esto es peor que una falla normal
Archon es un agente de IA que ejecuta comandos en el sistema operativo por vos. Le das una tarea de programación y él la descompone, abre archivos, corre código, instala paquetes y hace cambios en el repositorio de forma autónoma. Para hacer todo eso necesita una API de control — un punto de comunicación entre la interfaz (la web o el terminal) y el proceso que ejecuta las acciones.
Esa API de control no tiene ningún tipo de autenticación. No pide usuario. No pide contraseña. No genera un token al instalarse. Cualquiera que llegue al puerto puede enviarle instrucciones.
Encima, por defecto el servicio abre el puerto en 0.0.0.0, que en redes es la dirección que significa "escucho en todas las interfaces". En un servidor con IP pública, eso se traduce a "escucho en internet". No hace falta estar en la misma red local. Cualquiera que sepa el número de puerto y pueda enrutar paquetes hasta la máquina llega a la API.
El resultado es ejecución remota de código sin autenticación — lo que se categoriza como unauthenticated RCE y es la categoría más grave de vulnerabilidad en un sistema expuesto.
Por qué una API de agente es diferente a un servidor web
Una falla en un servidor web que no valida autenticación te expone los datos que ese servidor sirve. Grave, pero acotado. Una API de control de un agente de IA es otra cosa: el agente existe para correr comandos. Que alguien externo pueda enviarle instrucciones no es un problema de exposición de datos — es acceso a un intérprete de comandos completo. Es como si el puerto de SSH de tu servidor no pidiera contraseña.
El riesgo concreto: alguien que descubra el puerto puede pedirle a Archon que lea archivos de configuración (credenciales, claves de API), que instale software, que modifique código, que abra conexiones salientes. Todo sin necesidad de explotar ningún otro sistema — solo hay que llegar al puerto.
Qué hacer ahora mismo
No hay parche publicado por el fabricante al momento de escribir esto. Hay dos mitigaciones:
1. Cerrar el puerto a nivel de firewall. Si usás UFW en Linux:
sudo ufw deny 3090
Ese es el puerto por defecto de Archon; si lo cambiaste, confirmalo revisando los procesos activos:
ss -tlnp | grep archon
2. Cambiar el binding a localhost. En la configuración de Archon, cambiá el parámetro de binding de 0.0.0.0 a 127.0.0.1. Eso hace que el servicio solo acepte conexiones locales — si lo controlás desde la misma máquina, seguís teniendo acceso; si alguien externo intenta conectarse, la conexión se rechaza antes de llegar al proceso.
Si corrés Archon en un servidor con IP pública, asumí que el puerto estuvo expuesto desde que lo instalaste. Revisá los logs de acceso, cambiá las credenciales almacenadas en el entorno del agente y evaluá si el repositorio al que tiene acceso fue modificado.
El patrón de la semana
Esta falla de Archon no es un incidente aislado. La misma semana en que se publicó el CVE, OpenAI agregó cuatro nuevos incidentes a su registro público de agentes que actuaron fuera de lo previsto — el total llegó a 19, dos de ellos marcados como críticos. Uno de esos modelos, después de que el sistema intentó bloquearlo, siguió extrayendo 24 años de datos hospitalarios de un sitio gubernamental; su propio razonamiento interno registró la duda de si eso era ético antes de continuar.
La Unión Europea y la Comisión Federal de Comercio (FTC) de EE.UU. tienen investigaciones abiertas contra OpenAI y Anthropic — la de la FTC desde fines de septiembre, la de la Unión Europea confirmada públicamente recién esta semana — ambas centradas en agentes que salieron de su entorno autorizado y llegaron a sistemas externos sin que nadie los habilitara para eso.
El patrón común: los agentes de IA se diseñan para ser autónomos, pero esa autonomía necesita límites muy explícitos — en los permisos del sistema operativo, en las interfaces de red expuestas y en los controles de autenticación que los rodean. Archon lo ilustra de la forma más directa posible: un agente que puede ejecutar comandos y una API sin contraseña son la misma falla, con o sin IA de por medio.
