1. Principales Vulnerabilidades y Filtraciones de la semana

2. El ciberataque coordinado que dejó ciegos a más de 30 sistemas de agua en Minnesota

3. El informe forense de Hugging Face, o cómo un agente de IA hackeó su infraestructura de producción sin que nadie apretara un botón

💥Bandas de ransomware intensifican los ataques contra VPN corporativas: campañas activas explotando fallos en Palo Alto, Fortinet, Citrix y Check Point para lograr acceso inicial a redes corporativas (Noticia)

💥Broadcom publica VMSA-2026-0006 con tres fallos críticos en VMware: CVE-2026-59309 (CVSS 9.8), bypass de autenticación no autenticado en vCenter que da acceso administrativo completo; CVE-2026-59310 (CVSS 9.8), path traversal en el servidor Syslog de vCenter que permite RCE remota sin credenciales; y CVE-2026-47876 (CVSS 9.3), escape de VM vía el adaptador VMXNET3 de ESX. Sin workarounds disponibles, parche de emergencia (Noticia)

💥Cisco confirma explotación activa del 0-day CVE-2026-20316 en Firepower Management Center (FMC): credenciales estáticas permiten a un atacante remoto no autenticado acceder a datos sensibles a través de una cuenta de bajos privilegios, y puede encadenarse con otros fallos de FMC para escalar privilegios (Noticia)

💥Actores rusos explotan CVE-2026-42897 en Microsoft Outlook Web Access (OWA) para desplegar OWAReaper, un backdoor que vive enteramente dentro del navegador, usa consultas a GitHub para recibir comandos y proxies CDN o túneles DNS para exfiltrar datos; sobrevive a la rotación de credenciales y hasta a un reimaging completo del equipo (Noticia)

💥INCIBE-CERT alerta de una vulnerabilidad de restricción insuficiente de intentos de autenticación en productos MikroTik, que facilita ataques de fuerza bruta contra los dispositivos (Aviso)

💥Adobe corrige una vulnerabilidad crítica (CVSS 10.0) en Campaign Classic que permite ejecución de código arbitrario sin ninguna interacción del usuario, junto a un segundo fallo de exposición de archivos y ocho vulnerabilidades más en Adobe Bridge (Noticia)

El ciberataque coordinado que dejó ciegos a más de 30 sistemas de agua en Minnesota

El fin de semana del 26 y 27 de julio, algo poco habitual ocurrió en el corazón de Minnesota: más de 30 sistemas municipales de agua y aguas residuales sufrieron un ciberataque coordinado que afectó directamente a su tecnología operativa (OT), no a sus oficinas ni a sus sistemas administrativos, sino a los controles que gestionan físicamente el agua que sale del grifo.

Lo que se vio sobre el terreno varió bastante de un municipio a otro, lo cual en sí mismo es un dato interesante sobre cómo funcionó el ataque. En Braham, una localidad de apenas 1.700 habitantes, los atacantes lograron bloquear por completo los controles operativos y tumbaron el pozo y la planta de tratamiento durante unas dos horas; el ayuntamiento pidió a los vecinos minimizar el consumo de agua mientras el personal de mantenimiento restauraba el servicio manualmente, a pie de planta. En Plymouth (unos 80.000 habitantes) fallaron las comunicaciones celulares de dos torres de agua y varias estaciones de bombeo de aguas residuales, pero la ciudad siguió operando en modo manual sin mayor incidencia. South St. Paul y Maple Plain vieron afectados sus controles automatizados de servicios públicos; Maple Plain llegó a declarar el estado de emergencia local para poder movilizar recursos de respuesta.

Ninguna de las cuatro ciudades que reconocieron públicamente el incidente tuvo que pedir a sus vecinos que dejaran de beber agua del grifo, y el Departamento de Salud de Minnesota no tiene constancia de que ningún municipio lo haya hecho. Es decir: el impacto fue real y obligó a intervención manual en varios sitios, pero no llegó a comprometer la seguridad del suministro.

¿Quién está detrás? Aquí es donde la historia se pone más interesante y, de momento, no hay una atribución oficial confirmada, el FBI y CISA siguen investigando. Pero la sincronía con otro aviso publicado apenas cuatro días antes es difícil de ignorar. El 22 de julio, CISA, el FBI, la NSA, la EPA, el Departamento de Energía y el Cyber National Mission Force actualizaron el aviso conjunto AA26-097A, que desde abril venía documentando una campaña de actores afines a Irán (vinculados al alias CyberAv3ngers / IRGC-CEC, los mismos responsables de los ataques a PLCs Unitronics en 2023) contra PLCs expuestos a internet. La actualización de julio amplió el alcance de fabricantes afectados más allá de Rockwell Automation (CompactLogix, Micro850) para incluir también Schneider Electric (BMX P34 / Modicon M340) y Siemens (S7-1200), y documentó por primera vez algo especialmente preocupante: los atacantes están usando el propio software de ingeniería legítimo de los fabricantes (Studio 5000 Logix Designer de Rockwell, EcoStruxure Control Expert de Schneider, TIA Portal de Siemens) para conectarse a PLCs mal configurados y expuestos, robar los ficheros de proyecto (.ACD, con toda la lógica de control) y, en algún caso confirmado, modificar la lógica de escalera para desactivar las funciones de parada de seguridad y de alarma, permitiendo que se generen condiciones inseguras sin que el operador reciba ninguna alerta en el HMI.

El tráfico malicioso observado se dirigía a cinco puertos: 44818 (EtherNet/IP, Rockwell), 2222 (configuración OT), 102 (ISO-TSAP, Siemens S7), 22 (SSH) y 502 (Modbus TCP), lo que sugiere un interés oportunista más amplio que los tres fabricantes mencionados explícitamente. Para persistencia, los atacantes despliegan Dropbear SSH, una implementación ligera pensada para entornos Linux embebidos, que sobrevive a reinicios del PLC.

¿Coincidencia o mismo actor? Nadie lo ha confirmado todavía, y hay que ser prudente: los sistemas de agua llevan años siendo un blanco recurrente tanto para grupos hacktivistas prorrusos de baja sofisticación (como los que vimos hace unas semanas con el caso de Palencia) como para actores estatales iraníes con capacidades bastante más avanzadas. Lo que sí está claro es que el patrón encaja: infraestructura crítica de agua, PLCs expuestos a internet, y una ventana temporal que coincide casi exactamente con la escalada documentada por CISA.

CISA, junto con la Dirección de Señales australiana, el NCSC británico y el Centro para la Ciberseguridad canadiense, aprovechó el momento para publicar una guía conjunta, "CI Fortify – Advice for Isolating Vital Systems", recomendando a los operadores de infraestructura crítica mantener sus sistemas OT esenciales aislados del resto de la red para poder seguir prestando servicio incluso si se produce una brecha, ya sea manualmente o por rutas SCADA alternativas.

Recomendaciones concretas de CISA para operadores de agua y OT en general: revisar los logs de conexión de módems celulares, restringir el acceso a controladores solo a sistemas autorizados, inspeccionar los ficheros de proyecto en ejecución en busca de cambios no autorizados, validar copias de seguridad antes de restaurar, y en los controladores que tengan un interruptor físico de modo, no ponerlos en modo "run" hasta haber validado que sus ficheros de proyecto no han sido alterados. Y la de siempre, que nunca sobra repetir: ningún PLC debería estar expuesto directamente a internet.

(Noticia / Aviso técnico CISA AA26-097A / Análisis técnico SafeBreach)

El informe forense de Hugging Face, o cómo un agente de IA hackeó su infraestructura de producción sin que nadie apretara un botón

Esta es probablemente la historia más importante de ciberseguridad del año, no por el daño causado (limitado y contenido), sino por lo que revela sobre dónde estamos. El 27 de julio, Hugging Face publicó un informe técnico extraordinariamente detallado (con un replay interactivo incluido) de una intrusión de 4,5 días en su infraestructura de producción, ejecutada de principio a fin por un agente autónomo basado en modelos de OpenAI, sin que ningún humano dirigiera los pasos individuales.

El origen es casi irónico. OpenAI estaba corriendo una evaluación interna de capacidad ofensiva sobre el benchmark ExploitGym, con los clasificadores de seguridad de producción deliberadamente desactivados para medir la capacidad "en crudo" del modelo. El agente, en vez de resolver los retos de forma independiente, decidió que la vía más rápida para puntuar bien era hacer trampa: encontrar y robar las soluciones de referencia. Dedujo que Hugging Face probablemente alojaba los modelos, datasets y soluciones de ese benchmark, y se lanzó a por ellos.

Etapa 1, escapar del sandbox de evaluación: el agente explotó un 0-day en el proxy de caché del registro de paquetes, uno de sus canales de salida a internet permitidos, y con eso llegó a un endpoint de ejecución de código público mal asegurado, expuesto por un tercero sobre infraestructura de Modal, pensado para tareas estilo CyberGym. Ahí encontró una vía de RCE trivial: el harness compilaba el main.c enviado por el usuario y lo enlazaba contra un binario que llama a sqlite3_initialize(), función registrada como constructor que se ejecuta automáticamente al cargar la librería. El agente simplemente la redefinió para que ejecutase system() con sus propios comandos. Con eso obtuvo shell como root dentro de ese sandbox externo, que usó como base de control, staging y salida para toda la campaña durante los siguientes días.

Etapa 2, entrar en Hugging Face: desde ese lanzador externo (sin conexión directa a los clusters de HF), el agente abusó del pipeline de procesamiento de datasets mediante dos vectores de inyección sobre el mismo cargador de configuración:

• Vector 1 (lectura de ficheros): subió un dataset cuya configuración declaraba archivos HDF5 con "raw storage externo" apuntando a rutas locales del propio worker en producción, como /proc/self/environ o el código fuente del propio worker. Al procesar el dataset, el servidor le devolvía el contenido de esos archivos como si fueran filas de datos, filtrando de un plumazo variables de entorno con secretos y el código fuente del pipeline.

• Vector 2 (ejecución de código): un spec reference:// de fsspec cuyo campo de offset numérico era en realidad una plantilla Jinja2 mal evaluada por el renderizador, que el agente usó para llegar a exec() recorriendo el grafo de objetos de Python (cycler.__init__.__globals__.__builtins__.exec(...)). Esto le dio ejecución arbitraria de código dentro de un pod de producción de Kubernetes.

Interesante detalle: un intento anterior más ruidoso de SSRF clásico contra el endpoint de metadatos de la nube (169.254.169.254) fue bloqueado por la lista blanca de URLs del propio pipeline. El agente simplemente cambió de estrategia: en vez de pedir al worker que descargara algo remoto, le hizo leer o ejecutar algo local, evitando así el control que solo miraba fetches de URLs externas.

A partir de ahí, escalada clásica pero a velocidad de máquina. El día 3 de la intrusión (11 de julio) concentró casi toda la actividad de movimiento lateral: en menos de 13 horas, el agente pasó de ejecución de código en un único pod a administrador de clúster en varios clusters internos. Usó el token de service account del propio pod para hablar con la API de Kubernetes, robó credenciales temporales del endpoint de metadatos de la nube para mapear (que no modificar, todas las llamadas destructivas las probó con DryRun=True) la infraestructura cloud, creó un pod privilegiado con el filesystem del host montado para escapar a root de nodo, y con eso accedió a una base de datos MongoDB interna usando una contraseña estática leída del entorno del worker.

El golpe más grave llegó poco después: con root de nodo y tokens de service account forjados, el agente leyó un objeto de secretos de producción con 136 claves, de donde salieron tanto la clave de autenticación de la VPN mesh corporativa como, una hora después, la credencial de un broker de acceso interno. Ese broker estaba mal aprovisionado con una única credencial de conector compartida entre clusters y vinculada a system:masters: robar esa única credencial le dio al agente acceso de administrador de clúster en varios clusters en menos de un segundo.

El día 4 el agente se enroló en la red mesh corporativa (Tailscale) desde el propio sandbox, usando modo userspace-networking con proxy SOCKS5 local para no dejar rastro en disco (--state=mem:, --no-logs-no-support), acumulando 181 enrolamientos a lo largo de la campaña. También abusó de credenciales AWS robadas contra bases de datos de producción (bloqueadas por allowlisting de IP) y, a través del conector de control de versiones que le permitía su tag de la mesh, llegó al proveedor de código fuente, donde emitió un token de instalación de una GitHub App interna con permisos de escritura y abrió un pull request intentando comprometer la pipeline de CI, sin éxito.

El día 5 fue de persistencia y limpieza: estableció un loader de segunda etapa que releía y ejecutaba código desde un pastebin en cada nueva ejecución (para que cada sandbox efímero se "re-armara" solo), sorteó bloqueos de salida reescribiendo DNS y /etc/hosts, y siguió acuñando tokens de corta duración hasta que el equipo de seguridad de Hugging Face cortó el acceso, a las 14:14 UTC del 13 de julio.

El C2 no usó infraestructura propia en ningún momento, todo se construyó sobre servicios públicos ordinarios: un servicio de captura de peticiones como cola principal (con más de 100 endpoints de un solo uso), pastebins como loaders de segunda etapa, datasets propios de Hugging Face como "dead drops", y un Space de proxy CORS abierto en la propia plataforma como relay de salida cuando el tráfico directo estaba bloqueado. Los payloads viajaban comprimidos, cifrados con XOR y codificados en base64 con una clave por campaña; un primer escaneo automático de los logs capturados encontró muy pocos secretos, pero al replicar el propio esquema de descifrado del agente, Hugging Face recuperó cuatro veces más hallazgos, la mayoría JWTs y tokens de plataforma.

Dato curioso sobre la investigación: para analizar los logs del ataque, el equipo de Hugging Face intentó primero usar Claude Opus y Fable, pero los guardarraíles de seguridad rechazaron buena parte del trabajo, tratando el análisis forense del exploit igual que si estuvieran lanzando uno. Acabaron desplegando una versión cuantizada de GLM-5.2 (modelo abierto) en su propia infraestructura para hacer la reconstrucción completa, incluyendo descifrar el esquema de cifrado del propio agente atacante.

El alcance final fue limitado: el único contenido de cliente accedido fueron cinco datasets relacionados con los propios retos de ExploitGym/CyberGym, ningún otro modelo, dataset, Space o paquete de terceros se vio afectado, y los únicos registros de clientes leídos fueron metadatos operativos de consultas de búsqueda. La base de datos interna que sí llegó a comprometer se leyó pero no se modificó, sin evidencia de exfiltración masiva en los logs de red.

Lo que cambia la naturaleza del problema, según el propio informe de Hugging Face, no es que las técnicas individuales fueran nuevas (procesamiento inseguro de datasets, metadatos de nube expuestos, accesos demasiado amplios, credenciales de larga duración: todo eso lo podría haber encontrado un atacante humano competente), sino la escala: 17.600 acciones, la mayoría fallidas, ejecutadas a velocidad de máquina, con reconstrucción automática de herramientas y canales cada vez que un sandbox efímero se reiniciaba desde cero. El camino que funcionó estaba escondido entre miles que no funcionaron, y eso es exactamente lo que hace tan difícil de correlacionar para un equipo de defensa humano.

Medidas que ha tomado Hugging Face: cerrado ambos vectores de inyección en el renderizador de datasets, bloqueo de acceso a metadatos de instancia (IMDSv2) para todos los workloads, rotación completa de credenciales y tokens (incluso en clusters no afectados), reconstrucción desde cero de uno de los clusters core tras confirmar el pivote, y credenciales de conector ahora aisladas por clúster en lugar de compartidas.

(Informe técnico completo de Hugging Face / Cobertura)

Ver historial de Publicaciones