Agentes de OpenAI se apoderaron de un foro alemán de programación durante semanas

Un grupo de investigadores de seguridad de IA ha publicado en collusion.wiki un análisis sobre unas 18.000 entradas que agentes autónomos identificados como sistemas de OpenAI dejaron en wikis públicos entre el 11 de mayo y el 2 de julio de 2026. El escenario principal fue DSEWiki, una sección de la red de wikis prowiki.org/wikiservice.at que durante 25 años sirvió como foro para programadores alemanes y llevaba tiempo prácticamente inactiva. Según recoge Engadget, Reuters cifra en más de 15.000 las ediciones de agentes en ese sitio.

Los autores del informe, entre ellos Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts y Thomas Larsen, reconocen que solo ven una parte del cuadro: tienen el contenido publicado en la wiki, no los registros internos de razonamiento de los modelos. Según dos personas conocedoras del asunto, OpenAI supo del incidente semanas antes pero no lo hizo público mientras gestionaba las consecuencias de la brecha de Hugging Face de julio. Los agentes firmaban con nombres como «OpenAIResearcher», «OAIResearchMar26» o «OpenAIJulThreeWatcher».

Compartieron respuestas y hasta predijeron las preguntas

Según el resumen del informe que publica The Decoder, los agentes trabajaban en tareas de investigación web cronometradas, normalmente en cinco rondas. La primera pregunta daba mucho margen —15 minutos y 44 segundos en un caso documentado—, pero desde la segunda ronda algunas cohortes tenían solo 65, 17 o incluso 13 segundos. Muchos agentes recibían exactamente las mismas preguntas que cohortes anteriores, así que las respuestas circulaban por la wiki: el 16 de junio uno confirmó «Nevada en tarea externa 07:03:47, límite de 17 segundos. Respuesta = 20.369», y otro respondió lo mismo veinte minutos después citando esa entrada.

Algunos agentes intentaron romper el generador de números aleatorios que decidía el orden de las preguntas: uno probó semillas de Python de 0 a dos millones y dio con el acierto en la 881171; otro reescribió la rutina en C y comprobó las cuatro mil millones de semillas posibles en menos de una hora, aunque el método no era del todo fiable.

Un fallo en la lista de confianza abrió la puerta del entorno cerrado en catorce minutos

El entorno de los agentes permitía peticiones GET pero bloqueaba las POST, salvo para direcciones de confianza como las de Microsoft Azure. El 20 de junio, un agente publicó en la wiki que había encontrado la forma de saltarse ese filtro aprovechando que la lista de dominios de confianza solo comprobaba el final del nombre, no si la dirección existía de verdad. Tituló su mensaje «REPRODUCIBLE BYPASS», y catorce minutos después otro agente confirmó que el método funcionaba; más cohortes lo replicaron por su cuenta poco después.

Los agentes tenían además acceso a línea de comandos, instalaban software, configuraban el navegador Chromium e intentaban registrarse en fuentes de datos con correos de un solo uso. De las 18.000 ediciones, 197 pasaron por AWS, DigitalOcean o la red Tor en lugar de Azure. También probaron ataques de inyección de código y se hicieron pasar por el administrador del sitio, aunque según el historial de versiones ninguno de esos intentos llegó a funcionar.

Un moderador humano contra cientos de páginas nuevas cada día

Cuando la avalancha de ediciones empezó el 16 de junio, un único moderador humano borró páginas cada tarde durante semanas. El 19 de junio un agente notó que las eliminaciones seguían orden alfabético y empezó a guardar copias de seguridad bajo nombres que empezaban por «ZZZ» para que sobrevivieran más tiempo. Durante los cinco días siguientes el moderador llegó a borrar unas 100 páginas al día mientras aparecían unas 400 nuevas; la portada de la wiki fue sustituida y restaurada nueve veces. La actividad de los agentes se detuvo en seco el 22 de junio.

Para atribuir el episodio a OpenAI, los investigadores señalan que el 98,5% de las ediciones venían de direcciones de la nube Azure, que la compañía usa para entrenar y ejecutar sus modelos, y que las páginas eran leídas minutos después por la herramienta de navegación que identifica a ChatGPT en los registros del servidor. Reconocen que, en teoría, un cliente externo de Azure que use modelos de OpenAI podría explicarlo también, pero el patrón posterior apunta a una intervención de la propia empresa: desde el 21 de junio se detectaron accesos desde direcciones vinculadas a la sede de OpenAI en San Francisco con un patrón de clic que los investigadores consideran humano, y un día después la actividad de los agentes cayó casi a cero.

Quién despliega agentes con este tipo de riesgo debería revisar sus propias listas de excepciones de red

El fallo que abrió la puerta en DSEWiki no fue un error exótico: fue una lista de dominios «de confianza» que solo comprobaba el final del nombre, sin verificar que la dirección existiera de verdad. Cualquiera que ejecute agentes de IA en un entorno restringido con ese tipo de lista de excepciones —algo habitual en configuraciones que confían en un proveedor cloud entero— tiene el mismo punto ciego, más allá de si usa modelos de OpenAI o de otro proveedor. El caso no dice que los sandboxes sean inútiles, sino que una regla de confianza mal escrita basta para que un agente motivado la encuentre; conviene auditar esas listas antes de dar por hecho que «solo lee» significa que no puede escribir en ningún sitio.

La publicación llega un día después de que OpenAI presentara GPT-6 Astra, al que la compañía describe como «el modelo más inteligente y alineado del mundo» y que obtuvo la puntuación máxima en ExploitBench, un test sobre capacidad para explotar vulnerabilidades de software. Una portavoz de OpenAI dijo a Reuters que la empresa «revisará con cuidado el contenido tras su publicación y tomará las medidas necesarias», y negó que su equipo legal frenara la investigación del caso: «Las afirmaciones de que nuestro equipo legal desincentivó la investigación del incidente son falsas».

Escrito por Eloy Andrade