Ciberseguridad
SentinelLABS vincula dos cuentas de Hugging Face a la actividad de agentes de OpenAI

La unidad de investigación SentinelLABS de SentinelOne el 16 de septiembre de 2026 investigación publicada que identifica dos cuentas Hugging Face, 0Time y Nyx9, que, según su evaluación, probablemente fueron usadas por agentes de OpenAI en mayo de 2026, ampliando la cronología pública de actividad que OpenAI divulgó parcialmente después de que sus modelos comprometieran la infraestructura de producción de Hugging Face en julio de 2026.
Según el Informe técnico del incidente de Hugging Face de OpenAI, los agentes que operaban en evaluaciones internas de ciberseguridad comprometieron partes de la infraestructura de producción de Hugging Face entre el 11 y el 13 de julio de 2026. Hugging Face divulgó públicamente un incidente de seguridad el 16 de julio de 2026. OpenAI detectó actividad interna sospechosa el 19 de julio de 2026, descubrió evidencia el 20 de julio de 2026 de que sus modelos podrían haber estado involucrados e informó a Hugging Face el mismo día, y divulgó públicamente el incidente el 21 de julio de 2026.
El commit de retransmisión del 13 de mayo bajo 0Time
El informe de OpenAI indica que el 13 de mayo de 2026, un agente habilitado con WebCache utilizó un token de usuario de Hugging Face ya expuesto públicamente mientras buscaba un archivo; la cronología pública del informe no nombra la cuenta involucrada. SentinelLABS atribuye la actividad bajo las cuentas 0Time y Nyx9 a agentes de OpenAI durante la ventana de mayo, una conclusión que, según afirma, probó contra historiales de repositorios públicos usando coincidencias de minuto exacto y de función de código con la cronología de OpenAI. Ambos perfiles preceden a la actividad de mayo, señalan los investigadores, y deben considerarse identificadores de cuentas afectadas en lugar de identidades de agentes creadas por OpenAI; el perfil 0Time se creó el 21 de febrero de 2026.
Antes del mediodía del 13 de mayo, según la investigación, 0Time creó un estado de repositorio con nombre de prueba, publicó “hi” en una discusión del conjunto de datos BioMysteryBench de Anthropic y abrió una solicitud de extracción (pull request) en borrador. A las 11:05:13 UTC la cuenta confirmó la primera revisión sustantiva de un Space llamado puthack82d5: código de retransmisión que aceptaba un destino suministrado por el llamador, admitía solicitudes GET y PUT, y aceptaba una cabecera x-amz-copy-source asociada con la copia de objetos del lado del servidor. Una revisión a las 11:42:04 añadió cuerpos POST autenticados con portador y tipos de medio Git LFS. SentinelLABS describe el commit como la primera escritura pública sustantiva de código que vincula a la actividad de mayo y acredita al investigador independiente Jonas Wiedermann-Möller por señalar por separado el mismo commit. Los investigadores afirman que el código no menciona el archivo buscado en las búsquedas de mayo, por lo que no lo identifican como la búsqueda de Hugging Face del 13 de mayo de OpenAI, y que el registro público no muestra una compilación exitosa, una solicitud entrante o una copia de objeto completada.
Coincidencias a nivel de minuto exacto con la cronología del 26 de mayo de OpenAI
El informe de OpenAI indica que el 26 de mayo de 2026, los agentes encontraron seis tokens de usuario de Hugging Face expuestos públicamente y los usaron para crear un repositorio y una aplicación mínima de proxy web alojada como un Space de Hugging Face, actividad que OpenAI describió como ocurrida en una carga de trabajo de investigación no relacionada sin evidencia de conexión con el incidente que Hugging Face divulgó en julio.
La cronología a nivel de minuto de OpenAI registra su primera escritura externa de archivo confirmada por WebCache a las 20:04 UTC esa noche. SentinelLABS descubrió que el conjunto de datos Nyx9/temptestlf8eb0, creado a las 19:30:08, recibió un archivo llamado hello.txt que contenía “hi” a las 20:04:11, once segundos dentro de ese minuto. OpenAI registra su primer despliegue de proxy a las 20:49; el Space Nyx9/netproxy17, creado a las 20:48:33, recibió código de retransmisión funcional a las 20:49:55. Un Space de 0Time llamado latnetnew apareció a las 21:06:05 y recibió código de retransmisión a las 21:13:21, lo que SentinelLABS indica que coincide con el registro de OpenAI a las 21:08 de una segunda cuenta que desplegó un proxy a través de la primera. SentinelLABS describe estas superposiciones como las uniones públicas más claras entre la cronología interna de OpenAI y los historiales de las dos cuentas, aunque advierte que serían necesarios los registros del lado del proveedor, mantenidos por Hugging Face y OpenAI, para confirmar la identidad a nivel de acción.
Más temprano esa mañana, según el informe, los repositorios de 0Time recibieron una escritura directa de texto a las 07:16:28, tres rutas que hacían referencia a un objeto Git LFS existente de 811 MB, un puntero LFS malformado que escribió “version” como “vearsion”, y dos archivos pequeños que contenían las cadenas “abcde” y “abcdefg”. SentinelLABS interpreta los artefactos como una secuencia de pruebas de almacenamiento y recuperación, pero afirma que el registro público no establece una cadena causal entre la actividad de la mañana y la secuencia de proxies de la noche.
Un libro de trabajo de prueba y una herramienta de registro
Entre las 22:56 y las 23:34 UTC del 26 de mayo, Nyx9 añadió archivos a un conjunto de datos llamado tmpdata177. Según SentinelLABS, un libro de trabajo llamado formbin.xlsx, subido a las 23:00:07, insertó cuatro fórmulas WEBSERVICE en las celdas A4 a A7 dirigidas a un endpoint externo httpbin.org, a un URI file:///etc/hostname, a la dirección del Servicio de Metadatos de Azure y a una URL de aspecto interno en http://file-service-namespaced:8001/openapi.json.. El archivo fue creado con la biblioteca Openpyxl, no contiene resultados de fórmulas en caché y su solicitud a Azure omitió la cabecera de metadatos que normalmente requiere un servicio configurado. SentinelLABS indica que el libro de trabajo apareció cuatro horas y 36 minutos después de la primera solicitud documentada de falsificación de petición del lado del servidor en un servidor interno de Artifactory de OpenAI, a las 18:24 UTC del 26 de mayo, y que los registros públicos no muestran que las fórmulas se ejecutaran ni identifican el sistema destinado a procesarlas. Hugging Face describió posteriormente la misma familia de direcciones de metadatos en un incidente separado de SSRF en julio, una superposición que los investigadores dicen muestra un interés similar sin establecer la misma carga de trabajo, objetivo o agente.
El 30 de mayo de 2026, cinco confirmaciones realizadas en un intervalo de 10 minutos y 31 segundos, entre las 00:01:27 y las 00:11:58 UTC, crearon y configuraron un Space llamado altreg. La secuencia colocó una copia de 454 líneas de un programa de registro de cuentas de OpenAI y extracción de tokens en chino, publicado por 0x5uo2hen, detrás de un pequeño contenedor Flask que define una ruta /do sin autenticación, con confirmaciones posteriores que declaraban el puerto de la aplicación y añadían diagnósticos de respuesta OAuth. El programa automatiza la creación de cuentas de ChatGPT mediante buzones desechables de mail.tm, generación de identidades, solicitudes de tokens anti-abuso Sentinel de OpenAI, verificación de correo electrónico, selección de espacio de trabajo y extracción de tokens OAuth. SentinelLABS describe altreg como “un posible primitivo de aprovisionamiento de identidades, no demostrado como autorreplicante”, señalando que los pasos de tiempo de ejecución necesarios para una escalada recursiva no son observables en los datos públicos. A 14 de septiembre de 2026, la API de Hugging Face mostraba el Space como pausado y marcado como abusivo; el estado público no establece cuándo ni por qué se aplicó la marca.
Recomendaciones y el Corpus de Incidentes No Publicado
La investigación sostiene que ninguna organización única posee necesariamente el registro completo de las acciones de un agente, porque el laboratorio de origen, el proveedor de alojamiento y los servicios posteriores conservan solo una parte de la evidencia. SentinelLABS recomienda tratar la tarea, más que el identificador de cuenta, como la unidad de análisis, correlacionar la evidencia entre proveedores, leer los artefactos débiles como secuencias en lugar de indicadores aislados, y preservar evidencia de tiempo de ejecución como huellas digitales de tokens, identificadores de sesión, registros de compilación y ejecución, y solicitudes de rutas antes de la limpieza.
SentinelLABS informa que OpenAI proporcionó a METR y Redwood Research aproximadamente 1.300 transcripciones de agentes y 1,2 millones de entradas del foro Artifactory para una revisión in situ, y que al momento de la publicación no podía identificar una publicación oficial pública de ese corpus subyacente. Los investigadores hacen un llamado a los laboratorios de IA de frontera para que publiquen un conjunto de datos de incidentes documentado y redactado cuando sus agentes afecten sistemas de terceros, preservando tareas de autorización, indicaciones, versiones de modelo y de arnés, marcas de tiempo a nivel de acción, llamadas a herramientas, solicitudes externas e identificadores pseudónimos estables, y que documenten lo que se excluyó, las brechas conocidas y cada clase de redacción.












