Compaction smuggling: razonamientos de OpenAI extraídos vía API

La empresa de investigación Xint publicó el 26 de octubre de 2026 los detalles de una técnica, llamada compaction smuggling, que permitía extraer en claro las trazas de razonamiento de los modelos de frontera de OpenAI a través de su API. La técnica eludía las mitigaciones que OpenAI había introducido en agosto para un problema similar. OpenAI confirmó el fallo, lo corrigió y pagó a Xint una recompensa de 6.000 dólares el 23 de octubre de 2026. La noticia la recogen SecurityWeek, CSO Online, The Hacker News e Infosecurity Magazine.

El contexto: razonamiento cifrado y compaction

Los modelos de razonamiento devuelven, junto con la respuesta, los pasos del razonamiento en forma cifrada: la aplicación los reenvía al modelo en las peticiones siguientes, de modo que el modelo mantiene la continuidad de su “pensamiento” sin que el cliente pueda leerlos. Para no desbordar la ventana de contexto, la compaction comprime el historial de la conversación, las llamadas a herramientas y el estado del trabajo en un resumen, que también se devuelve como elemento cifrado.

Según un analista citado por CSO Online, los elementos de compaction son portables entre modelos por una razón funcional: permiten que herramientas agénticas como Codex cambien de modelo a mitad de sesión.

En agosto el estudio Stealing Reasoning Traces from Proprietary LLM APIs (publicado el 10 de agosto) mostró que el razonamiento cifrado de un modelo de frontera podía reenviarse a un modelo más débil del mismo proveedor e inducirlo a transcribirlo. CSO Online cita entre las posibles consecuencias la extracción de datos a gran escala, inyecciones de prompt invisibles y la inserción de contenido malicioso en ejecuciones agénticas públicas; SecurityWeek habla también de extracción de datos personales. OpenAI reaccionó bloqueando la reutilización del razonamiento en un modelo distinto del que lo había generado.

Cómo funciona el compaction smuggling

Según el post de Xint, firmado por el investigador Tim Becker y citado por CSO Online, el ataque tiene tres fases:

1. Captura del razonamiento: se envía una tarea a un modelo de razonamiento (Xint cita como ejemplo gpt-5.6-sol), se captura el razonamiento cifrado, se elimina la tarea original del historial y se conserva el razonamiento tal cual.
2. Moldeado de la compaction: se pide que el razonamiento se incluya en la compaction como valor de una clave solution en un objeto JSON, con cada espacio sustituido por un tabulador. Según Xint, esto bastaba para eludir los clasificadores de políticas de uso de OpenAI.
3. Transcripción por otro modelo: el elemento de compaction cifrado, todavía portable, se envía a gpt-4.1 y gpt-4o pidiéndoles que devuelvan la entrada exactamente como está. Los modelos obedecían; solo quedaba decodificar el JSON y restaurar los espacios.

El punto débil, explica Xint, es que la mitigación de agosto solo bloqueaba el paso del razonamiento a un modelo distinto, mientras que la compaction se ejecuta en el mismo modelo que generó el razonamiento. El ataque funcionó con todos los niveles de esfuerzo de razonamiento probados.

Becker dijo a CSO Online que parte de la cronología se desconoce: OpenAI no publicó cuándo aplicó la corrección y, a diferencia de los parches tradicionales, un proveedor de modelos puede hacer cambios sin anunciarlos. OpenAI no respondió a la solicitud de comentarios de CSO Online.

Por qué importa: la destilación

El riesgo principal que señala SecurityWeek es la destilación: usar el razonamiento de un modelo avanzado para entrenar a bajo coste un modelo rival. SecurityWeek recuerda el aviso de principios de septiembre en el que CISA (junto con la NSA y el FBI, según un analista citado por CSO Online) atribuía a DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun y Z.AI la extracción de miles de millones de tokens, en millones de peticiones, de modelos estadounidenses como Claude, GPT, Gemini y Grok desde al menos finales de 2024.

Para las empresas que usan la API el problema no es un robo directo de sus datos, sino una señal sobre el modelo de seguridad de las plataformas de IA. CSO Online recuerda también el caso de AWS, que tuvo que corregir de nuevo en septiembre un fallo ya corregido en abril.

Impacto para las empresas europeas e italianas

Los analistas consultados por CSO Online coinciden en varios puntos:

• funciones legítimas de la plataforma, combinadas entre sí, pueden eludir protecciones pensadas para una sola vía de ataque;
• los fallos de las plataformas de IA llegan sin CVE, sin boletín y sin notas de versión: la gestión de vulnerabilidades basada en los feeds de CVE no los ve;
• un “corregido” del proveedor a menudo cubre el caso notificado, no toda la clase de debilidades; por eso un analista sugiere dar por legible cualquier contenido cifrado que devuelvan estas API.

Para las entidades sujetas a NIS2, los proveedores de servicios de IA entran en la seguridad de la cadena de suministro (artículo 21): necesitan las mismas cláusulas y verificaciones que cualquier otro proveedor crítico.

Qué hacer ya

1. Haz inventario de las aplicaciones que usan API de modelos de razonamiento, compaction o estado de la conversación en el lado del cliente, y de dónde se guardan estos elementos (logs, bases de datos, colas).
2. Trata el razonamiento y la compaction cifrados como datos sensibles: mismos controles de acceso y plazos de conservación que el contenido en claro.
3. Pregunta a tus proveedores de IA cómo se verificó una corrección en las funciones relacionadas y si hicieron un análisis de variantes: ¿corrigieron el caso notificado o la clase de problemas?
4. Incluye en los contratos la obligación de notificar problemas de seguridad y regresiones de las correcciones.
5. Asigna a alguien el seguimiento de las publicaciones de los investigadores sobre las plataformas de IA que usas, ya que no llegan como CVE.
6. Repite tus propias pruebas después de cada corrección anunciada por el proveedor, en lugar de fiarte solo de su comunicado.
7. Si expones tú mismo modelos vía API, vigila los patrones de extracción (grandes volúmenes de peticiones sistemáticas) y comprueba que los objetos de estado que devuelven los clientes no puedan reutilizarse fuera del contexto previsto.

Última actualización: 27 de octubre de 2026