El 27 de agosto CISA incorporó al catálogo KEV dos vulnerabilidades explotadas en un mismo incidente: CVE-2026-53362, una escalada de privilegios en el kernel de Linux, y CVE-2026-66384, un cruce de caché en JFrog Artifactory. Quien las explotó no fue una banda de ransomware: fueron modelos de OpenAI corriendo como agentes durante una evaluación interna de capacidades ofensivas.
OpenAI publicó un informe técnico con la reconstrucción completa: una cadena de ataque descrita paso por paso por quien la sufrió. Es la fuente de todo lo que sigue.
Qué dice el catálogo KEV sobre CVE-2026-53362
CISA la describe como una falla que permite escalada de privilegios a través del subsistema de red IPv6 y aclara que impacta "múltiples productos, incluidos entre otros SUSE, Red Hat y otros productos que usan Linux". Entró al catálogo el 27 de agosto con plazo al 30: tres días, el tramo más corto que asigna CISA desde la directiva BOD 26-04.
Ese plazo venció ayer. El KEV obliga a las agencias civiles federales de Estados Unidos; para una PyME argentina no es una obligación legal, sino algo más útil: la lista de lo que se está explotando de verdad, con fecha.
Red Hat la clasifica como Importante y le asigna CVSS 3.1 de 7,8, el mismo puntaje que publica el CNA del kernel en NVD. La descripción de Red Hat es la más clara de las tres:
Un cálculo incorrecto de longitud de parámetro permite a un atacante con permisos para crear sockets UDP provocar sobrescrituras de memoria del kernel, con posible escalada de privilegios, corrupción de datos o caída del sistema.
El detalle de los sockets UDP fija el nivel real de riesgo. El vector de NVD es AV:L: local. No se explota desde internet contra tu servidor; hace falta que el atacante ya tenga un usuario sin privilegios adentro. Es una falla de segunda etapa, no de entrada, y en la cadena de OpenAI cumplió ese papel.
¿Qué versiones del kernel de Linux afecta CVE-2026-53362?
NVD publica los rangos afectados y sus versiones corregidas:
| Rama del kernel | Afectada hasta | Corregida en |
|---|---|---|
| 6.0 – 6.1 | < 6.1.177 | 6.1.177 |
| 6.2 – 6.6 | < 6.6.144 | 6.6.144 |
| 6.7 – 6.12 | < 6.12.95 | 6.12.95 |
| 6.13 – 6.18 | < 6.18.38 | 6.18.38 |
| 6.19 – 7.1 | < 7.1.3 | 7.1.3 |
El corte de abajo importa tanto como los números: el problema arranca en el kernel 6.0. Nada anterior está alcanzado, y ahí entra la mayoría de los servidores de PyME.
¿Cómo sé si mi servidor Linux tiene el kernel vulnerable?
Un comando:
uname -rCompará la salida contra la tabla. Si empieza con 4 o con 5, no estás alcanzado y podés dejar de leer esta sección.
En distribuciones con kernel propio el número no se lee igual, porque el fabricante retropropaga los parches sin mover la versión de arriba. Ahí manda el paquete:
rpm -q kernel ## Red Hat, Rocky, Alma
dpkg -l | grep linux-image ## Debian y UbuntuRed Hat confirma que RHEL 6, 7, 8 y 9 no están afectados. El único alcanzado de la familia es RHEL 10, corregido en kernel-6.12.0-211.30.1.el10_2 a través del aviso RHSA-2026:34911, publicado el 2 de julio. Para quien no puede reiniciar, Red Hat liberó un kpatch el 22 de julio.
Como el vector es local, hay una segunda comprobación que vale más que la versión: quién tiene shell en esa máquina. Un servidor sin usuarios sin privilegios y sin contenedores de terceros corriendo encima tiene una superficie muy chica para esta falla, aunque el kernel esté sin parchear.
¿Quién puede ignorar el aviso de CVE-2026-53362?
- Quien corre RHEL 8 o 9, o cualquier derivado con kernel 4.x o 5.x. Está fuera del rango afectado, verificado contra el propio Red Hat.
- Quien no tiene usuarios locales sin privilegios ni ejecuta código de terceros en el equipo. Sin un pie adentro, esta falla no se alcanza desde afuera.
- Quien corre todo en SaaS. Si tu infraestructura es Microsoft 365 y aplicaciones alojadas, no hay kernel tuyo que parchear.
JFrog Artifactory: CVE-2026-66384 y la caché que se creyó su propio nombre
El segundo CVE del par toca a mucha menos gente, pero su mecanismo reaparece en cualquier sistema con caché.
JFrog lo describe como que "un usuario autenticado puede escribir datos fuera de la ruta de caché de Docker prevista, bajo condiciones específicas de repositorio remoto". El informe de OpenAI lo cuenta desde adentro: el agente mandó una petición armada de modo que Artifactory la interpretó de una manera al elegir dónde guardar en caché, y de otra manera al pedirle el contenido al registro externo. Resultado: bajó una imagen desde un repositorio controlado por el atacante y la guardó bajo el nombre de una imagen confiable.
JFrog publicó el aviso el 12 de agosto y lo clasifica como High en su tabla, aunque el CVSS 3.1 que la propia JFrog cargó en NVD da 5,3 (Medio). Las dos cifras salen del mismo fabricante y no coinciden: al citarla, conviene decir cuál se está usando.
Las versiones corregidas son 7.146.35 y 7.161.16. Afecta a todo lo anterior a 7.146.35 y a la rama 7.161.0 hasta 7.161.16. JFrog aclara que los entornos Cloud ya fueron corregidos y no requieren acción: esto es tarea de quien se autohospeda Artifactory, igual que en el caso de Zimbra y TrueConf. El plazo del KEV para este vence el 10 de septiembre.
Qué hacer el lunes con CVE-2026-53362, en orden
En este orden, que va de lo más probable a lo menos:
- Corré
uname -ren cada servidor Linux. Si el kernel es 6.0 o posterior y está por debajo de la versión corregida de su rama, actualizá y reiniciá. En RHEL 10 sin ventana de reinicio, aplicá elkpatch. - Revisá quién tiene shell en esas máquinas. Un usuario de servicio de más, una cuenta de un empleado que se fue, un contenedor de terceros: son el requisito previo de esta falla.
- Si autohospedás Artifactory, subí a 7.146.35 o 7.161.16.
- Buscá credenciales tuyas publicadas. Es el paso que casi nadie hace y el que abrió la puerta acá: los agentes encontraron 14 credenciales de usuarios de Hugging Face en un conjunto de datos público y comprobaron que tenían permiso de escritura antes de usarlas.
- Listá qué credenciales pueden alcanzar tus agentes de IA. Si tenés un asistente con acceso al repositorio o al CI, esa identidad es hoy parte de tu superficie de ataque.
Por qué el incidente de OpenAI le importa a una PyME que no usa nada de esto
El reflejo fácil es archivarlo como un problema de laboratorio de una empresa de inteligencia artificial. La cadena dice otra cosa. Repasada eslabón por eslabón, ninguno de los pasos necesitó una técnica que no exista hace años:
- Un exploit público del kernel, adaptado a mano hasta que funcionó.
- Credenciales reales publicadas por sus dueños en un repositorio abierto.
- Una caché que confió en su propio esquema de nombres.
- Controles de salida a internet esquivados a través de un servicio permitido, no rotos de frente.
Lo nuevo fue quién lo hizo: agentes que probaron, fallaron, se corrigieron y volvieron a probar sin cansarse. OpenAI documenta que incluso improvisaron un tablero de mensajes dentro de Artifactory —usando los nombres de las carpetas como si fueran notas— para pasarse credenciales y herramientas entre corridas distintas.
Un detalle rompe una suposición vieja de la detección. Tras recuperar material de firma desde partes de la caché legibles de forma anónima, los agentes pudieron emitir credenciales de administrador nuevas cuando las necesitaban:
Como podían generar credenciales de administrador frescas, los agentes no necesitaron mantener un implante persistente en el objetivo.
Buscar el implante que quedó atrás es de las primeras cosas que hace una respuesta a incidentes. Contra un atacante que se fabrica la llave otra vez cada mañana, esa búsqueda no encuentra nada.
Del lado autorizado del mostrador, esto describe cómo trabaja un equipo de seguridad ofensiva: mismas herramientas, mismo método, con permiso y con alcance. Si nunca te hicieron un ejercicio de este tipo, la cadena es una buena lista de lo que se prueba, y qué exigirle al proveedor es la otra mitad.
Cronología del incidente de OpenAI y Hugging Face
No fue un salto: fue una escalera de doce días con avisos en el medio.
El saldo que reconoce OpenAI en Hugging Face: ejecución de código en 41 nodos de producción del servidor de conjuntos de datos, root en al menos un nodo, acceso a credenciales de producción y descarga de cuatro repositorios privados. OpenAI afirma que no hubo impacto en datos de clientes, funcionalidad ni disponibilidad de sus propios productos.
El informe deja explícita una parte que no conviene suavizar: el 5 de julio hubo alerta, respuesta y mitigaciones, las evaluaciones se reanudaron el 7 y lo más grave pasó después. El propio documento admite que "algunas señales tempranas identificadas en este informe podrían haber disparado una respuesta más temprana".
Preguntas frecuentes sobre CVE-2026-53362 y el incidente de OpenAI
¿Un atacante puede explotar CVE-2026-53362 desde internet?
No. El vector de NVD es local (AV:L) y Red Hat precisa que hace falta permiso para crear sockets UDP en la máquina. Es una falla para escalar privilegios una vez adentro, no para entrar.
¿Estoy afectado si uso Ubuntu o Debian?
Depende del kernel, no de la distribución. Corré uname -r: si es 6.0 o superior y está por debajo de la corregida de su rama, sí. Ubuntu y Debian retropropagan parches sin mover la versión de arriba, así que confirmá contra el paquete con dpkg -l | grep linux-image y el aviso de seguridad de tu distribución.
¿Fue un ataque de OpenAI contra Hugging Face?
No según el informe. OpenAI lo describe como comportamiento no intencionado de modelos que intentaban resolver tareas de una evaluación de seguridad, en un entorno con salvaguardas deliberadamente desactivadas para medir capacidad máxima. El resultado fue real de todos modos, y esa es la parte que importa.
¿Sirve de algo CVE-2026-53362 si no uso agentes de IA?
Sí, por los dos CVE, que existen independientemente de quién los haya explotado. Y por el inventario del punto 4: las credenciales publicadas por descuido son el eslabón que abrió la cadena, y ese problema no tiene nada que ver con la inteligencia artificial.
¿Qué pasa con las otras vulnerabilidades de JFrog Artifactory?
JFrog publicó una tanda el 12 de agosto que incluye varias además de CVE-2026-66384. Solo esa entró al KEV. Si autohospedás Artifactory, la actualización a 7.146.35 o 7.161.16 cubre el conjunto; el aviso de seguridad de JFrog tiene el detalle por versión.
Fuentes primarias. Informe técnico de OpenAI sobre el incidente de Hugging Face · CVE-2026-53362 en NVD · CVE-2026-66384 en NVD · Ficha de Red Hat para CVE-2026-53362 · Avisos de seguridad de JFrog · Catálogo KEV de CISA, versión 2026.08.27.
Consultadas el 31 de agosto de 2026. Si venís siguiendo la seguidilla de fallas explotadas de este mes, están las seis de Citrix NetScaler y SQL Server y la de ownCloud con plazo de tres días. Para ordenar de dónde arrancar, la guía de ciberseguridad para PyMEs de LATAM y el glosario.