Linux vuelve a enfrentarse a un fallo de alto impacto con una característica especialmente incómoda para operaciones, la combinación de una técnica fiable y un PoC público. Dirty Frag se describe como una escalada local de privilegios que termina en root y afecta a un conjunto amplio de distribuciones, entre ellas Ubuntu, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, openSUSE Tumbleweed y Fedora. Aunque el vector es local, el riesgo práctico es elevado en entornos con usuarios no plenamente confiables, acceso interactivo, bastiones, servidores multiusuario, sistemas con jobs de CI y máquinas de escritorio donde se ejecutan binarios de procedencia variada.

A nivel técnico, el problema se remonta a cambios introducidos hace años en el kernel de Linux, concretamente alrededor de la interfaz criptográfica algif_aead. La explotación encadena dos defectos relacionados con escritura en page cache, uno vinculado a la ruta de entrada de xfrm ESP y otro en RxRPC, lo que permite alterar contenido cacheado en memoria de ficheros que deberían estar protegidos. Es una familia de fallos que recuerda a Dirty Pipe y Copy Fail, y se presenta como un bug lógico determinista, sin depender de una race condition, lo que suele traducirse en exploits más consistentes.

En el escenario descrito para ESP, el comportamiento problemático aparece cuando se manejan paquetes construidos con páginas compartidas, por ejemplo páginas de pipe adjuntadas mediante splice, sendfile o MSG_SPLICE_PAGES, que acaban en un skb UDP sin marcar como fragmento compartido y se descifran ‘en sitio’. Ese detalle es clave porque abre la puerta a que el descifrado y las rutas de escritura afecten a memoria asociada a páginas que no deberían modificarse de esa manera. El arreglo propuesto en la rama de red marca los fragmentos creados por splice en IPv4 e IPv6 con el flag SKBFL_SHARED_FRAG y, cuando está presente, la ruta de entrada de ESP evita el descifrado en sitio y recurre a una ruta con copia previa. El cambio se centra en la entrada de ESP y no pretende alterar la salida.

El PoC que circula públicamente ejemplifica el impacto final de forma muy directa, ya que incluye una ruta para sobrescribir la page cache de /usr/bin/su con un ELF mínimo que lanza una shell con UID 0. Lo relevante aquí es que el efecto puede materializarse sin necesidad de ‘reescribir’ el fichero en disco en ese mismo instante, lo que complica la defensa basada únicamente en integridad de ficheros si no se contempla el estado de la caché. El código de prueba además crea un user namespace y un network namespace para operar con sockets de red dentro del netns y orquestar el caso de ESP encapsulado en UDP.

En el momento inicial se hablaba de ausencia de CVE, pero AlmaLinux ya ha indicado la asignación de CVE-2026-43284 y ha documentado kernels corregidos para AlmaLinux 8, 9 y 10, publicados en su repositorio almalinux-testing. Como referencia, se citan umbrales como kernel-4.18.0-553.123.2.el8_10 en AlmaLinux 8, kernel-5.14.0-611.54.3.el9_7 en AlmaLinux 9 y kernel-6.12.0-124.55.2.el10_1 en AlmaLinux 10. En paralelo, se han compartido fixes upstream, uno para ESP en el árbol de netdev y otro para RxRPC publicado en lore.kernel.org.

Mientras los parches llegan y se despliegan en todas las distribuciones, la mitigación operativa propuesta pasa por impedir la carga de los módulos del kernel esp4, esp6 y rxrpc, y descargarlos si están activos, asumiendo el impacto. Esto puede romper VPNs IPsec basadas en ESP y también componentes asociados a AFS en entornos que lo usen, así que conviene verificar dependencias reales antes de aplicarlo de forma masiva y, si esos servicios son imprescindibles, priorizar aún más la transición a un kernel corregido en lugar de sostener la mitigación durante mucho tiempo. En AlmaLinux, además, se advierte de que rxrpc.ko puede proceder del subpaquete kernel-modules-partner, distribuido en el repositorio Devel y no habilitado por defecto, por lo que merece la pena comprobar si está instalado y eliminarlo si no es necesario para reducir superficie.

Como medida adicional cuando no sea posible reiniciar de inmediato tras actualizar, se propone vaciar la caché de páginas con el comando echo 3 > /proc/sys/vm/drop_caches para forzar lecturas desde disco en lugar de reutilizar páginas cacheadas potencialmente alteradas. Aun así, si hay indicios de explotación, el enfoque prudente es tratarlo como un compromiso total, ya que la técnica permite afectar binarios y ficheros sensibles a través de la page cache. En ese caso, además de contener, conviene rotar credenciales y reinstalar desde un origen confiable.

Dado que se ha reportado explotación satisfactoria también en WSL2 y en kernels recientes de escritorio, el perímetro a vigilar va más allá de servidores tradicionales. La priorización debería centrarse en máquinas con acceso local no confiable, sistemas con cuentas compartidas, saltos de administración y entornos donde se ejecuta código de terceros, al mismo tiempo que se monitorizan los avisos de seguridad del proveedor y se planifican ventanas de reinicio para cargar el kernel actualizado en cuanto el backport esté disponible.

Más información

• BleepingComputer – New Linux ‘Dirty Frag’ zero-day gives root on all major distros : https://www.bleepingcomputer.com/news/security/new-linux-dirty-frag-zero-day-with-poc-exploit-gives-root-privileges/
• Openwall – oss-security mailing list (index) : https://www.openwall.com/lists/oss-security/
• Tom’s Hardware – Devastating ‘Dirty Frag’ exploit leaks out, gives immediate root access on most Linux machines since 2017, no patches available, no warning given — Copy Fail-like vulnerability had its embargo broken : https://www.tomshardware.com/tech-industry/cyber-security/dirty-frag-exploit-gets-root-on-most-linux-machines-since-2017-no-patches-available-no-warning-given-copy-fail-like-vulnerability-had-its-embargo-broken
• AlmaLinux OS Blog – Dirty Frag : https://almalinux.org/blog/2026-05-07-dirty-frag/
• Openwall oss-security – Dirty Frag: Universal Linux LPE : https://www.openwall.com/lists/oss-security/2026/05/07/8
• Openwall oss-security – Copy Fail 2 / Dirty Frag — n-day from public commit, not embargo break : https://www.openwall.com/lists/oss-security/2026/05/07/12
• netdev mailing list (spinics.net) – [PATCH 8/8] xfrm: esp: avoid in-place decrypt on shared skb frags : https://www.spinics.net/lists/netdev/msg1183448.html

La entrada Dirty Frag: la nueva vulnerabilidad zero-day en Linux con PoC público que permite escalar privilegios a root en múltiples distribuciones se publicó primero en Una Al Día.

En muchos productos modernos, desde plataformas de automatización hasta sistemas de plugins y entornos tipo REPL, es habitual permitir que usuarios o integraciones ejecuten pequeños fragmentos de JavaScript. Para intentar hacerlo de forma segura, numerosos equipos confían en vm2, una librería de Node.js diseñada para aislar ese código dentro de un sandbox. El problema es que se han divulgado múltiples fallos críticos que rompen precisamente esa promesa de aislamiento, permitiendo que un atacante atraviese la barrera y ejecute código con los permisos del proceso del host, un escenario de alto impacto cuando el servicio gestiona secretos, credenciales, tokens o tiene acceso a red interna.

La divulgación agrupa varios vectores de escape en distintas versiones de la rama 3.x. Entre ellos, CVE-2026-24118 describe un escape mediante lookupGetter con capacidad de llegar a ejecución arbitraria, afectando a 3.10.4 e inferiores y quedando corregido en 3.11.0. CVE-2026-24120 es especialmente sensible porque evita un parche anterior relacionado con CVE-2023-37466 aprovechando la propiedad species de las promesas, lo que vuelve a abrir la puerta a ejecutar comandos, afectando a 3.10.3 e inferiores y solucionándose en 3.10.5. También se han publicado escapes que explotan superficies aparentemente ‘auxiliares’, como inspect en CVE-2026-24781 o SuppressedError en CVE-2026-26332, ambos corregidos en 3.11.0 para versiones 3.10.4 e inferiores.

Uno de los casos más comentados es CVE-2026-26956, catalogado como un fallo del mecanismo de protección. Afecta a vm2 3.10.4 y se corrigió en 3.10.5, con confirmación del problema en Node.js 25.6.1 sobre Linux x64. Este vector depende de características concretas de WebAssembly, en particular el manejo de excepciones y el soporte de WebAssembly.JSTag. El ataque aprovecha la instrucción try_table para capturar excepciones de JavaScript por debajo del nivel de JavaScript, en la capa C++ de V8, y convertir un error en un retorno ‘normal’. De este modo se eluden dos defensas centrales de vm2, el transformador que intenta envolver y sanear errores del host, y los proxies puente que encapsulan objetos entre contextos.

En la práctica, el concepto de explotación descrito provoca un TypeError del host durante el formateo de la pila al forzar la coerción de Symbol a string. Ese error del host entra al sandbox sin el saneamiento esperado y, a partir de ahí, el atacante encadena accesos como hostError.constructor.constructor para obtener el Function del host, recuperar process y terminar ejecutando comandos mediante child_process. Esto encaja con el riesgo típico de los escapes de sandbox, no se trata solo de ‘leer algo’, sino de convertir el sandbox en una vía para ejecutar órdenes del sistema y pivotar hacia otros activos.

La lista incluye además fallos como CVE-2026-43997, una inyección de código que permite obtener el Object del host, y CVE-2026-43999, que permite saltarse la allowlist de NodeVM y cargar módulos built-in que el host pretendía bloquear, incluyendo child_process, ambos corregidos en 3.11.0. Otros defectos amplían la superficie con escapes y efectos secundarios como prototype pollution, caso de CVE-2026-44005, que afecta a 3.9.6 a 3.10.5 y queda corregido en 3.11.0, así como CVE-2026-44006, también corregido en 3.11.0.

Mención aparte merece CVE-2026-44007, que se materializa cuando se usa NodeVM con nesting: true. En esa configuración, el código dentro del sandbox puede llegar a ejecutar require(‘vm2’) incluso si el host configuró require: false o allowlists estrictas, y luego crear una NodeVM interna con una política de require distinta para alcanzar child_process. La corrección en 3.11.1 endurece el comportamiento haciendo que la combinación { nesting: true, require: false } falle en construcción, y deja claro un punto clave para defensores, nesting: true funciona como una vía de escape deliberada, porque una VM anidada no queda limitada por la política de módulos de la VM exterior. La cadena de parches se completa con CVE-2026-44008 y CVE-2026-44009, escapando por rutas como neutralizeArraySpeciesBatch() o una excepción con proto nulo, ambas corregidas en 3.11.2.

Dado el uso extendido de vm2, con más de 1,3 millones de descargas semanales en npm, la prioridad para equipos de seguridad es doble. Por un lado, actualizar cuanto antes a vm2 3.11.2, que reúne las correcciones más recientes. Si no es posible hacerlo de inmediato, conviene como mínimo saltar a las primeras versiones que corrigen cada familia de fallos, por ejemplo 3.10.5 para CVE-2026-26956 y CVE-2026-24120, 3.11.0 para varios escapes críticos, y 3.11.1 para el caso de CVE-2026-44007 si existe uso de anidamiento. Por otro lado, es esencial inventariar dónde se ejecuta JavaScript no confiable, incluyendo dependencias transitivas, y priorizar servicios que permitan scripts de usuarios o automatizaciones externas.

Además de parchear, conviene reducir la exposición estructural. Si se utiliza NodeVM, hay que revisar allowlists y bloquear rutas que puedan alcanzar child_process, pero sin asumir que require: false es un aislamiento suficiente si se habilita nesting: true. En general, el enfoque recomendado es defensa en profundidad, ejecutar código no confiable en un proceso o contenedor separado y efímero, con privilegios mínimos, sin secretos accesibles y con restricciones de red, asumiendo que un escape a nivel de proceso es viable. En paralelo, los despliegues sobre Node.js 25 merecen una mitigación prioritaria por su relación directa con el vector descrito para CVE-2026-26956. En entornos SaaS, estas medidas marcan la diferencia entre un incidente acotado y una intrusión con movimiento lateral dentro de la infraestructura.

Más información

• The Hacker News – vm2 Node.js Library Vulnerabilities Enable Sandbox Escape and Arbitrary Code Execution : https://thehackernews.com/2026/05/vm2-nodejs-library-vulnerabilities.html
• BleepingComputer – Critical vm2 sandbox bug lets attackers execute code on hosts : https://www.bleepingcomputer.com/news/security/critical-vm2-sandbox-bug-lets-attackers-execute-code-on-hosts/
• OSV.dev – VM2 Has a WASM Sandbox Escape (Node 25 only) (GHSA-ffh4-j6h5-pg66, CVE-2026-26956) : https://osv.dev/vulnerability/GHSA-ffh4-j6h5-pg66
• oss-sec (seclists.org) – oss-sec: vm2: sandbox escape in NodeVM with nesting:true (CVE-2026-44007) : https://seclists.org/oss-sec/2026/q2/412
• GitHub Security Advisory (patriksimek/vm2) – nesting: true bypasses require: false, allowing sandbox escape to arbitrary OS command execution (GHSA-8hg8-63c5-gwmx, CVE-2026-44007) : https://github.com/patriksimek/vm2/security/advisories/GHSA-8hg8-63c5-gwmx
• GitHub Releases (patriksimek/vm2) – Release v3.11.1 : https://github.com/patriksimek/vm2/releases/tag/v3.11.1

La entrada Múltiples fallos críticos en vm2 permiten ejecutar código en el host se publicó primero en Una Al Día.

La seguridad del kernel de Linux vuelve a estar en el foco por una escalada local de privilegios que, aun sin ser un fallo remoto por sí sola, se convierte en un multiplicador de impacto cuando un atacante ya ha conseguido ejecutar algo en el sistema. Esa es la situación con CVE-2026-31431, apodada Copy Fail, que se ha incorporado al catálogo Known Exploited Vulnerabilities (KEV) de CISA tras confirmarse su uso en ataques reales, con una fecha límite de mitigación marcada para el 15 de mayo de 2026 en organismos FCEB.

El defecto permite pasar de un usuario sin privilegios a root manipulando la page cache del kernel. El punto crítico es que el atacante puede forzar una escritura controlada de 4 bytes sobre páginas en caché asociadas a cualquier fichero que pueda leer, incluidos binarios setuid. En la práctica, se habilita la ejecución de código con privilegios elevados sin necesidad de modificar el archivo en disco, lo que complica algunas comprobaciones clásicas basadas en integridad de ficheros. Además, como el cambio reside en memoria, un reinicio puede borrar el rastro en la caché, sin que eso elimine la necesidad de investigar un posible compromiso.

A nivel técnico, el problema se relaciona con el subsistema criptográfico y la interfaz algif_aead, mediante el uso de AF_ALG combinado con splice(). La cadena de explotación publicada en código de prueba se apoya en crear un socket AF_ALG con una construcción del tipo authencesn(hmac(sha256),cbc(aes)), después ‘canalizar’ páginas de la page cache hacia una tubería criptográfica, y finalmente provocar una escritura en memoria a través de recvmsg(), controlando el valor de esos 4 bytes mediante datos AAD. La vulnerabilidad se introdujo en 2017 con un cambio que optimizaba el procesado AEAD sobre el propio buffer, lo que acabó permitiendo que páginas de caché terminasen en una scatterlist de destino escribible. La corrección upstream revierte esa optimización y se ha propagado a ramas estables mediante backports.

El alcance es amplio: se describe afectación en kernels publicados desde 2017, con rangos citados como 4.14 hasta 7.0 rc, además de 6.18.x anteriores a 6.18.22 y 6.19.x anteriores a 6.19.12. También se mencionan arreglos en ramas LTS adicionales, como 6.12.85, 6.6.137, 6.1.170, 5.15.204 y 5.10.254. En cuanto a distribuciones, se han mostrado ejemplos de impacto en Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 y SUSE 16, y se citan además Debian, Fedora, Arch Linux, Rocky Linux, AlmaLinux y Oracle Linux como entornos a vigilar, siempre condicionados a la versión concreta del kernel y a los parches del proveedor.

Aunque el vector es local y no requiere interacción del usuario, su peligrosidad crece cuando se combina con un acceso inicial, por ejemplo credenciales SSH expuestas, ejecución maliciosa en CI/CD o una primera intrusión dentro de un contenedor. En cloud, Docker, LXC y, sobre todo, Kubernetes, el riesgo aumenta porque los contenedores comparten el kernel del host. Un solo nodo vulnerable puede ampliar el radio de impacto del clúster, y un incidente que empiece como ejecución en contenedor puede escalar a compromiso del host si se dan las condiciones.

La mitigación principal es directa: actualizar el kernel a versiones corregidas, como 6.18.22, 6.19.12 o 7.0, o instalar los paquetes equivalentes publicados por cada distribución. En paralelo, conviene inventariar qué hosts siguen en versiones vulnerables, incluyendo imágenes cloud, plantillas de VMs y bases de imágenes de contenedor, porque una cadena de suministro interna con kernels antiguos puede reintroducir el riesgo al escalar entornos.

Si el parche no es inmediato, hay mitigaciones alternativas con matices importantes. En Ubuntu se ha desplegado una mitigación a nivel de paquete kmod para impedir la carga de algif_aead, y se considera que Ubuntu 26.04 no está afectada. Aun así, bloquear o descargar algif_aead puede causar regresiones de rendimiento o incompatibilidades en aplicaciones que dependan de esa ruta criptográfica, y puede requerir reinicio para garantizar que el sistema cae a cifrado en espacio de usuario. Antes de deshabilitar AF_ALG o algif_aead, es recomendable identificar dependencias reales, por ejemplo revisando procesos con lsof y filtrando uso de AF_ALG, para evitar romper servicios críticos.

En entornos Red Hat y derivados, puede ocurrir que el componente afectado esté integrado en el kernel y no sea bloqueable como módulo. En esos casos se plantea mitigación con parámetros de arranque como initcall_blacklist=algif_aead_init o initcall_blacklist=af_alg_init, planificando un reinicio controlado y validando después el arranque y el comportamiento de cargas que usen criptografía.

La detección tampoco es trivial, porque la explotación se apoya en llamadas al sistema legítimas y en manipulación en memoria. Aun así, pueden desplegarse controles en tiempo de ejecución centrados en patrones anómalos, como reglas de Falco que alerten sobre creación de sockets AF_ALG de tipo SEQPACKET por procesos inesperados. Esta aproximación requiere ajuste con una allowlist, ya que kTLS puede usar AF_ALG en escenarios legítimos.

En Kubernetes y plataformas de contenedores, además de parchear el host, es recomendable reducir el margen de encadenamiento denegando la creación de sockets AF_ALG mediante perfiles seccomp a nivel de runtime y de pods, reforzar controles de admisión como Pod Security Admission o políticas equivalentes, y limitar contenedores privilegiados. Operativamente, cualquier señal de ejecución no autorizada en un contenedor debería tratarse como posible compromiso del host, acelerando la recreación o rotación de nodos y la rotación de credenciales.

La disponibilidad de un PoC reutilizable entre distribuciones, junto con la publicación de un módulo de Metasploit el 29 de abril de 2026, reduce la barrera de entrada para actores oportunistas y eleva la urgencia de remediación. Con el fallo ya explotándose de forma activa y con impacto potencial sobre flotas en cloud, la respuesta más efectiva sigue siendo una combinación de parcheo rápido, endurecimiento de acceso, controles sobre ejecución de cargas y monitorización específica de actividad relacionada con AF_ALG, splice() y comportamientos inusuales en el kernel.

Más información

• BleepingComputer – CISA says ‘Copy Fail’ flaw now exploited to root Linux systems : https://www.bleepingcomputer.com/news/security/cisa-says-copy-fail-flaw-now-exploited-to-root-linux-systems/
• The Hacker News – CISA adds actively exploited Linux root flaw to KEV (Copy Fail) : https://thehackernews.com/2026/05/cisa-adds-actively-exploited-linux-root.html?utm_source=openai
• Microsoft Security Blog – CVE-2026-31431 ‘Copy Fail’ vulnerability enables Linux root privilege escalation : https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/?utm_source=openai
• Qualys ThreatPROTECT – Linux Kernel vulnerability exploited in the wild: Copy Fail (CVE-2026-31431) : https://threatprotect.qualys.com/2026/05/04/linux-kernel-vulnerability-exploited-in-the-wild-copy-fail-cve-2026-31431/?utm_source=openai
• Sysdig – CVE-2026-31431: ‘Copy Fail’ Linux kernel flaw lets local users gain root in seconds : https://www.sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds
• Canonical – Fixes available for CVE-2026-31431 (Copy Fail) Linux Kernel Local Privilege Escalation Vulnerability : https://canonical.com/blog/2026/04/30/copy-fail-vulnerability-fixes-available/
• SUSE – SUSE responds to the copy.fail vulnerability : https://www.suse.com/c/suse-responds-to-the-copy-fail-vulnerability/
• Red Hat – RHSB-2026-02 Cryptographic Subsystem Privilege Escalation- Linux Kernel – (CVE-2026-31431) : https://access.redhat.com/security/vulnerabilities/RHSB-2026-02
• Tenable – Copy Fail (CVE-2026-31431): Frequently asked questions about Linux kernel privilege escalation vulnerability : https://www.tenable.com/blog/copy-fail-cve-2026-31431-frequently-asked-questions-about-linux-kernel-privilege-escalation

La entrada CISA alerta de explotación activa de Copy Fail para obtener root en Linux se publicó primero en Una Al Día.

Las plataformas de Managed File Transfer (MFT) suelen concentrar flujos de información delicada entre empresas, partners y sistemas internos, por lo que se han convertido en un objetivo especialmente atractivo para atacantes. En este contexto, Progress ha desplegado correcciones para MOVEit Automation tras identificarse dos fallos que, combinados o por separado, pueden abrir la puerta a accesos no autorizados y a un control más profundo del entorno afectado.

La vulnerabilidad más grave es CVE-2026-4670, clasificada como crítica, que permite un bypass de autenticación en remoto antes de iniciar sesión. El defecto se describe como explotable sin privilegios previos, con baja complejidad y sin interacción del usuario, un perfil que suele acelerar la urgencia operativa porque reduce barreras para automatizar intentos de explotación. El alcance incluye versiones de MOVEit Automation anteriores a 2025.1.5, 2025.0.9 y 2024.1.8. Para evitar confusiones en inventarios y CMDB, también se han detallado equivalencias internas de numeración, por ejemplo 2025.1.4 equivale a 17.1.4, 2025.0.8 a 17.0.8 y 2024.1.7 a 16.1.7.

El segundo problema, CVE-2026-5174, tiene severidad alta y se asocia a una validación de entrada inadecuada que puede desembocar en escalado de privilegios. Se indica de forma explícita su impacto en la rama 2025.1.x, desde 2025.1.0 hasta 2025.1.4, lo que eleva la prioridad de parcheo para quienes estén en esa línea. Ambos fallos están vinculados a interfaces del puerto de comandos del backend del servicio de MOVEit Automation, una zona especialmente sensible porque conecta con operaciones internas de la plataforma.

Aunque en el momento de la publicación no se ha confirmado explotación activa en ataques reales, el riesgo no es teórico: se han observado más de 1.400 instancias de MOVEit Automation expuestas a Internet, y este tipo de exposición reduce el tiempo de reacción disponible. Un compromiso podría traducirse en acceso no autorizado, obtención de control administrativo y posible exposición de datos, incluyendo credenciales almacenadas en tareas automatizadas y ficheros empresariales que transitan o se gestionan desde la herramienta.

La remediación pasa por actualizar a las versiones parchadas 2025.1.5, 2025.0.9 o 2024.1.8 según la rama. Es relevante que la corrección de CVE-2026-4670 exige aplicar la actualización mediante el instalador completo, y no se describen medidas alternativas que mitiguen totalmente el problema, por lo que conviene asumir desde el inicio que no existe un workaround equivalente. Esto implica planificar una ventana de mantenimiento, ya que el proceso provoca una interrupción del servicio durante la instalación.

Además del parcheo, se recomienda reforzar la vigilancia operativa revisando registros de auditoría y eventos del producto para detectar accesos anómalos, intentos de escalado de privilegios o actividad inusual relacionada con la interfaz backend. Si no es posible actualizar de inmediato, la medida temporal más efectiva es restringir el acceso de red a MOVEit Automation, especialmente desde Internet, limitándolo a redes internas y a orígenes estrictamente necesarios, mientras se prepara el despliegue del instalador completo. La investigación se atribuye a Airbus SecLab y a los investigadores Anaïs Gantet, Delphine Gourdou, Quentin Liddell y Matteo Ricordeau.

Más información

• BleepingComputer – Progress warns of critical MOVEit Automation auth bypass flaw : https://www.bleepingcomputer.com/news/security/moveit-automation-customers-warned-to-patch-critical-auth-bypass-flaw/
• The Hacker News – Progress Patches Critical MOVEit Automation Bug Enabling Authentication Bypass : https://thehackernews.com/2026/05/progress-patches-critical-moveit.html
• Help Net Security – Critical MOVEit Automation auth bypass vulnerability fixed (CVE-2026-4670) : https://www.helpnetsecurity.com/2026/05/04/critical-moveit-automation-auth-bypass-vulnerability-fixed-cve-2026-4670/
• Canadian Centre for Cyber Security – Progress security advisory (AV26-410) : https://www.cyber.gc.ca/en/alerts-advisories/progress-security-advisory-av26-410
• Beazley Security – Critical Vulnerability in Progress MOVEit Automation (CVE-2026-4670) : https://beazley.security/alerts-advisories/critical-vulnerability-in-progress-moveit-automation-cve-2026-4670
• NIST NVD – CVE-2026-5174 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-5174

La entrada Progress corrige un bypass crítico de autenticación en MOVEit Automation (CVE-2026-4670) se publicó primero en Una Al Día.

Los paneles de hosting son un objetivo prioritario porque concentran credenciales, control de servicios y capacidad de ejecutar cambios con impacto inmediato en múltiples webs y cuentas. En este contexto, un fallo crítico en cPanel y WHM (WebHost Manager) está acelerando intrusiones automatizadas contra servidores expuestos a Internet, con una cadena de ataque que termina, en muchos casos, en cifrado de ficheros y extorsión.

La vulnerabilidad, identificada como CVE-2026-41940, permite un bypass de autenticación que abre la puerta a acceder al panel sin pasar por el proceso normal de login. Se ha distribuido una actualización de emergencia para corregir el problema, pero la actividad observada indica que se viene intentando explotar desde finales de febrero. Además, se han reportado picos que apuntan a decenas de miles de direcciones IP detectadas en sensores y honeypots con señales de compromiso o actividad maliciosa asociada. Esa cifra, en torno a 44.000 IP, refleja oleadas de escaneo, intentos de explotación y fuerza bruta, y no equivale necesariamente al número de servidores ya cifrados, pero sí describe una presión operativa muy alta.

A nivel técnico, el bypass se apoya en una inyección CRLF dentro del flujo de login y carga de sesión, lo que permite escribir atributos arbitrarios en ficheros de sesión en disco y reutilizarlos para forjar una sesión con privilegios de root. Un punto clave del vector combina una cabecera Authorization Basic manipulada con un valor de cookie whostmgrsession con formato anómalo, concretamente sin el segmento ob esperado. Al faltar esa parte, el tratamiento del campo de contraseña cambia y se facilita que caracteres de salto de línea acaben sin filtrar en el fichero de sesión, convirtiendo una única entrada en múltiples líneas de tipo key=value. En la práctica, se han visto inyecciones de atributos como successful_internal_auth_with_timestamp, hasroot, tfa_verified y user=root, orientados a superar comprobaciones posteriores.

La explotación completa no se limita a escribir el fichero raw, porque el sistema prioriza un fichero de caché en JSON. Por eso, la cadena incluye un paso adicional para forzar que se lea el fichero raw y se reescriba la caché, elevando las claves inyectadas al nivel adecuado. Se han descrito rutas que provocan eventos tipo token_denied, que terminan reserializando la sesión y consolidando los campos maliciosos como atributos válidos de autenticación.

Una vez dentro, los ataques observados culminan con el despliegue de un cifrador para Linux asociado al ransomware Sorry, implementado en Go. Los ficheros cifrados pasan a llevar la extensión .sorry y se deja una nota de rescate denominada README.md. En cuanto a la criptografía, el cifrado utiliza ChaCha20 y la clave de cifrado se protege con una RSA-2048 public key embebida, lo que hace que la recuperación sin la clave privada correspondiente no sea viable en términos prácticos. La negociación con las víctimas se canaliza mediante Tox, y se ha observado un identificador consistente en las muestras analizadas. También es importante no confundir esta campaña con un ransomware de 2018 que usaba la misma extensión, ya que se trata de una operación distinta.

La urgencia aumenta porque CISA incorporó CVE-2026-41940 al catálogo Known Exploited Vulnerabilities el 30 de abril de 2026, confirmando explotación activa y reforzando la necesidad de actuar con rapidez. La telemetría pública sitúa a Estados Unidos como el país con más sistemas afectados, con Francia y Países Bajos a continuación, un patrón coherente con la alta concentración de servicios de hosting y VPS.

La corrección aplicada introduce sanitización centralizada en la ruta de guardado de sesión y un tratamiento específico cuando falta el segmento ob, codificando en hexadecimal el valor de pass para impedir que se convierta en múltiples líneas en disco. Se ha publicado una lista amplia de versiones corregidas, que cubre múltiples ramas, incluyendo 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.124.0.35, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, 11.136.0.5 y WP Squared 136.1.7. Aun así, existen series intermedias en las que no hay parche in situ, lo que obliga a saltar de versión, migrar o, como mínimo, aislar la superficie expuesta mientras se completa el cambio.

En términos de respuesta, aplicar el parche es imprescindible, pero no suficiente si el servidor ya fue alcanzado antes. En instancias expuestas a Internet conviene priorizarlo como incidente, asumir posible compromiso y revisar indicadores operativos como la presencia de .sorry, el archivo README.md, procesos con alto volumen de I/O y la ejecución de binarios desconocidos, especialmente artefactos Go recientes. Tras contener, resulta prudente rotar credenciales del panel y de cuentas administrativas asociadas, y validar copias de seguridad offline y el plan de restauración antes de intentar volver a producción.

Mientras se completa el parcheado, una medida de contención efectiva es limitar o cerrar los puertos de cpsrvd mediante lista blanca hacia IPs de administración, en particular 2082, 2083, 2086, 2087, 2095 y 2096. También se recomienda situar cpsrvd detrás de un punto de inspección, por ejemplo Apache con ModSecurity, y exponer el acceso mediante proxy subdomains, dejando los puertos directos inaccesibles desde Internet. En paralelo, pueden añadirse reglas WAF para bloquear CR o LF tras decodificar Authorization Basic y para rechazar cookies whostmgrsession con formato anómalo.

Para confirmar o descartar manipulación, es útil ejecutar un escaneo forense de sesiones en /var/cpanel/sessions/raw y correlacionarlo con logs de acceso y login, buscando combinaciones sospechosas como token_denied junto con cp_security_token y origin_as_string con method=badpass. Tras actualizar, conviene purgar sesiones potencialmente manipuladas y reiniciar el servicio cpsrvd para reducir el riesgo de reutilización de artefactos antiguos. También se debe comprobar si las actualizaciones están deshabilitadas o fijadas a una versión, por ejemplo mediante /etc/cpupdate.conf, y corregirlo para permitir parches de emergencia.

Finalmente, se ha descrito un efecto colateral de integridad de logs: peticiones no autenticadas con Authorization WHM pueden contaminar el campo user en access logs aunque no lleguen a ejecutar acciones privilegiadas. Por ello, la respuesta debería incluir validaciones de integridad y no basarse solo en el nombre de usuario registrado en logs para concluir que una acción fue legítima. En conjunto, el mensaje operativo es claro: parchear rápido, reducir exposición de puertos, buscar señales de intrusión y no dar por resuelto el riesgo únicamente por estar en una versión corregida.

Más información

• BleepingComputer – Critrical cPanel flaw mass-exploited in «Sorry» ransomware attacks : https://www.bleepingcomputer.com/news/security/critrical-cpanel-flaw-mass-exploited-in-sorry-ransomware-attacks/
• BleepingComputer – Critrical cPanel flaw mass-exploited in «Sorry» ransomware attacks : https://www.bleepingcomputer.com/news/security/critrical-cpanel-flaw-mass-exploited-in-sorry-ransomware-attacks/amp/
• watchTowr Labs – The Internet Is Falling Down, Falling Down, Falling Down (cPanel & WHM Authentication Bypass CVE-2026-41940) : https://labs.watchtowr.com/the-internet-is-falling-down-falling-down-falling-down-cpanel-whm-authentication-bypass-cve-2026-41940/
• Rapid7 – CVE-2026-41940: cPanel & WHM Authentication Bypass : https://www.rapid7.com/blog/post/etr-cve-2026-41940-cpanel-whm-authentication-bypass/
• SecurityWeek – Over 40,000 Servers Compromised in Ongoing cPanel Exploitation : https://www.securityweek.com/over-40000-servers-compromised-in-ongoing-cpanel-exploitation/
• Canadian Centre for Cyber Security – cPanel security advisory (AV26-404) – Update 1 : https://www.cyber.gc.ca/en/alerts-advisories/cpanel-security-advisory-av26-404
• R-fx Networks – Reverse-Engineering CVE-2026-41940 (SessionScribe): cPanel/WHM Session Forgery : https://rfxn.com/research/cpanel-sessionscribe-cve-2026-41940

La entrada Explotación masiva de un bypass crítico en cPanel facilita el ransomware «Sorry» en servidores Linux se publicó primero en Una Al Día.

El auge de los AI gateways y proxies para centralizar el acceso a modelos ha convertido a piezas como LiteLLM Proxy en un punto único de alto valor: concentran tráfico, aplican políticas y, sobre todo, custodian secretos que abren la puerta a servicios externos. Por eso, cuando aparece un fallo crítico en la capa de autenticación, el impacto no se limita a una aplicación, puede extenderse a los proveedores conectados y a la nube.

El problema identificado como CVE-2026-42208, con severidad crítica (CVSS 9.3), es una inyección SQL que se activa antes de cualquier autenticación. El vector es especialmente delicado porque el atacante no necesita una cuenta ni una clave válida: basta con enviar una cabecera Authorization manipulada a rutas habituales de API de LLM, como POST /chat/completions, para forzar que el servidor construya consultas de base de datos con entrada no confiable. El origen del fallo está en la verificación de claves del proxy, donde el valor aportado por el cliente termina incrustado en el texto de la consulta en lugar de usarse una consulta parametrizada.

En términos prácticos, esto permite leer información de la base de datos del proxy y, dependiendo del contexto, modificarla. El riesgo inmediato es la exposición de tablas con material sensible, como litellm_credentials.credential_values y litellm_config, que pueden incluir configuración de ejecución y variables de entorno. Un detalle especialmente preocupante es que una sola fila en litellm_credentials puede agrupar a la vez claves de OpenAI, Anthropic y credenciales de AWS Bedrock, lo que eleva el impacto potencial desde un incidente en el proxy hasta un compromiso más amplio de cuentas y consumo en cloud.

La rapidez con la que se pasó de la divulgación a los intentos de explotación ha sido llamativa. Se observó actividad en un margen de unas 36 horas desde su publicación e indexación, con el primer intento registrado el 26 de abril de 2026, tras quedar el aviso accesible en la GitHub Advisory Database. Los patrones detectados apuntan a un operador con automatización, con solicitudes identificadas por el User Agent Python/3.12 aiohttp/3.9.1 y una cabecera Authorization que arrancaba con sk-litellm’, usando la comilla simple para cerrar la cadena e inyectar SQL. También se vieron tácticas típicas de enumeración, como cargas UNION y barridos para acertar el número de columnas variando NULL, seguidas de una segunda fase más afinada, ya orientada a nombres de tablas reales y a tokens como LiteLLM_VerificationToken. La actividad se asoció a las IP 65.111.27.132 y 65.111.25.67, con rotación de salida compatible con un mismo actor.

Aunque se detectó sondeo de endpoints de gestión como /key/generate y /key/info sin autenticación, no se confirmó una continuidad clara usando credenciales exfiltradas ni una generación exitosa de nuevas claves virtuales. Aun así, la conclusión operativa es clara: el intervalo entre divulgación y explotación es ya lo bastante corto como para asumir que cualquier instancia expuesta a Internet es objetivo inmediato.

Las versiones afectadas abarcan LiteLLM >= 1.81.16 y < 1.83.7. La corrección está disponible en LiteLLM 1.83.7 stable, publicada el 19 de abril de 2026. Si actualizar no es viable de forma inmediata, se propone como mitigación temporal activar disable_error_logs: true dentro de general_settings, para cortar la ruta por la que la entrada no confiable llega a la consulta vulnerable. Como contención adicional, puede colocarse el proxy detrás de un reverse proxy o WAF que aplique filtrado defensivo de la cabecera Authorization, bloqueando comillas simples y patrones característicos de SQLi como UNION, SELECT, FROM, OR y comentarios tipo —. Esta medida no sustituye al parche, pero puede reducir el riesgo mientras se planifica la actualización.

Dado que el valor real está en los secretos, la respuesta no debería terminar en el despliegue del fix. Es recomendable rotar todas las claves y secretos almacenados o gestionados por LiteLLM, especialmente credenciales de proveedores de LLM y cualquier credencial cloud asociada, además de revisar la exposición y la integridad de la base de datos del proxy. En paralelo, conviene buscar indicadores de explotación en logs HTTP y del perímetro, poniendo el foco en solicitudes a /chat/completions o /v1/chat/completions con Authorization que contenga sk-litellm’ o cadenas UNION SELECT, y tratar cualquier coincidencia como señal de alta confianza. También resulta prudente monitorizar consumo y facturación en OpenAI, Anthropic y AWS Bedrock para detectar uso anómalo a partir del 24 de abril de 2026, y correlacionarlo con IPs y claves virtuales.

Más allá de este CVE, se han mencionado otras debilidades en LiteLLM Proxy que podrían encadenarse, como una SSTI en /prompts/test y ejecución de comandos vinculada a endpoints de prueba de MCP, lo que refuerza la necesidad de revisar qué rutas están expuestas y aplicar endurecimiento de forma conjunta. Una práctica útil para equipos defensivos es inventariar instancias potencialmente publicadas buscando servicios HTTP cuyo título empiece por LiteLLM, y después verificar configuración, parches y exposición. Este contexto cobra más relevancia al recordarse un incidente reciente de cadena de suministro en PyPI relacionado con el proyecto, un recordatorio de que la higiene de dependencias y la rotación de credenciales no es opcional en entornos que manejan secretos.

En resumen, CVE-2026-42208 es un ejemplo de cómo un fallo en la verificación de claves en un proxy de LLM puede convertirse en un incidente de seguridad con impacto transversal. Parchear a 1.83.7, reducir superficie de exposición moviendo LiteLLM a red interna y publicándolo solo mediante un frontal con controles estrictos, revisar trazas de ataque y rotar secretos son pasos clave para limitar daños y evitar que un ataque al gateway termine comprometiendo proveedores y cuentas cloud.

Más información

• The Hacker News – LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure : https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html
• Sysdig – CVE-2026-42208: Targeted SQL injection against LiteLLM’s authentication path discovered 36 hours following vulnerability disclosure : https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
• GitHub Security Advisory (BerriAI LiteLLM) – LiteLLM has SQL Injection in Proxy API key verification (GHSA-r75f-5x8p-qvmc) : https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
• runZero – LiteLLM Proxy vulnerabilities: How to find impacted assets : https://www.runzero.com/blog/litellm/
• BleepingComputer – Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw : https://www.bleepingcomputer.com/news/security/hackers-are-exploiting-a-critical-litellm-pre-auth-sqli-flaw/

La entrada Explotación rápida de una inyección SQL crítica en LiteLLM pone en riesgo claves de proveedores de LLM se publicó primero en Una Al Día.

El uso de herramientas de trabajo diario como Microsoft Teams está consolidándose como vía de entrada para intrusiones dirigidas, porque permite a los atacantes interactuar con la víctima con un nivel de inmediatez y ‘apariencia de soporte’ que el correo tradicional no siempre consigue. En esta campaña, atribuida a UNC6692, el objetivo no es solo infectar un equipo, sino convertir un engaño puntual en un compromiso completo del entorno, con impacto directo sobre credenciales, sistemas internos y, en último término, el dominio.

La operación arranca con bombardeo de correos, una avalancha de mensajes que busca saturar al usuario y crear urgencia. En ese contexto, el atacante inicia un chat por Teams haciéndose pasar por personal de helpdesk y ofrece una solución rápida. El paso clave es inducir a la víctima a instalar un supuesto ‘parche’ para frenar el spam. Ese instalador actúa como dropper y ejecuta scripts de AutoHotkey que preparan el terreno para una cadena de herramientas a medida.

Una pieza central es SnowBelt, una extensión maliciosa orientada a Chrome, que se carga y opera en una instancia de Microsoft Edge sin interfaz visible, reduciendo la probabilidad de que el usuario detecte actividad extraña. Para mantenerse, los atacantes crean tareas programadas y un acceso directo en la carpeta de inicio, y además despliegan tareas adicionales para relanzar Edge en modo oculto con la extensión activa y para identificar y cerrar procesos de Edge ‘no deseados’ según módulos cargados.

A nivel funcional, SnowBelt sirve como persistencia y como relé de órdenes hacia SnowBasin, una puerta trasera en Python capaz de ejecutar comandos CMD y PowerShell, devolver resultados y habilitar acciones típicas de intrusión, como shell remota, descarga y exfiltración de ficheros, capturas de pantalla y operaciones básicas de gestión de archivos. Para camuflar y estabilizar las comunicaciones entra en juego SnowGlaze, que levanta un túnel WebSocket seguro contra infraestructura en la nube, se disfraza con un User Agent de Edge y utiliza credenciales embebidas. Este túnel puede habilitar funciones tipo SOCKS proxy para encaminar tráfico TCP arbitrario a través del equipo comprometido, y se han observado sesiones de PsExec y RDP circulando por ese canal.

La fase posterior se orienta al dominio. Se realiza reconocimiento interno y escaneo de servicios como SMB y RDP, incluyendo puertos 135, 445 y 3389, para localizar objetivos con valor. Para escalar, se han visto técnicas de acceso a credenciales mediante volcado de memoria de LSASS, incluso usando el Administrador de tareas de Windows, y después pass the hash para movimiento lateral. El objetivo final es llegar al controlador de dominio y extraer la base de datos NTDS de Active Directory, junto con los hives SYSTEM, SAM y SECURITY. En los casos documentados, se ha utilizado FTK Imager para la adquisición y LimeWire como canal de exfiltración. También se ha observado actividad de captura de pantalla en controladores de dominio, con foco en ventanas en primer plano como Microsoft Edge y FTK Imager, para apoyar operaciones guiadas por el operador.

El engaño inicial incorpora defensas contra análisis: un ‘gatekeeper’ limita la entrega de carga a objetivos concretos y dificulta que sandboxes capturen el flujo completo. La infraestructura de suplantación se apoya en inquilinos desechables onmicrosoft.com y, en parte de la actividad, se han vinculado orígenes a direcciones IP relacionadas con Rusia. La página de suplantación impone condiciones de ejecución, exige un parámetro email en la URL y redirige a about:blank si falta, y además empuja al usuario a abrir el enlace en Edge con el esquema microsoft-edge. Para el robo de credenciales se emplea una ‘doble validación’, rechazando la contraseña las dos primeras veces para que la víctima repita el secreto, y después se suben credenciales y metadatos a buckets de Amazon S3 controlados por el atacante. A nivel técnico, SNOWBELT incorpora generación de URLs de mando y control basada en franjas temporales, usa AES-GCM para artefactos, y abusa de push notifications del navegador con una clave VAPID embebida para activar ejecución con baja latencia. También puede interactuar con componentes locales mediante Native Messaging e intentar disparar URI schemes para interactuar con aplicaciones de escritorio.

La tendencia que subyace es clara: en telemetría reciente se aprecia una automatización elevada en la secuencia ‘bombardeo de correo, contacto por Teams’, con chats iniciados con diferencias de decenas de segundos entre múltiples objetivos. Entre el 1 de marzo y el 1 de abril de 2026, una parte muy significativa de los incidentes con este patrón se dirigió a perfiles de liderazgo, con mayor concentración en sectores como manufactura y servicios profesionales, científicos y técnicos. Además, se ha visto abuso de herramientas RMM legítimas, como Supremo Remote Desktop y Quick Assist, para convertir la interacción social en control remoto en cuestión de minutos, y en campañas de esta clase se han documentado también movimientos laterales con WinRM hacia activos de alto valor y exfiltración con herramientas de sincronización como Rclone.

Para reducir el riesgo, es prioritario endurecer controles donde el atacante se apoya en comportamientos ‘normales’. Conviene restringir o bloquear extensiones no autorizadas en Chrome y Edge con políticas de lista blanca, y detectar o limitar AutoHotkey en endpoints donde no sea imprescindible, idealmente con allowlisting. Deben monitorizarse tareas programadas y persistencia vía carpeta de inicio, y levantar alertas ante cambios no autorizados. En red, resulta clave inspeccionar túneles WebSocket anómalos y señales de SOCKS proxy desde estaciones de usuario.

En el plano de credenciales y movimiento lateral, es recomendable afinar detecciones de LSASS dumping y pass the hash, aplicar protecciones del sistema operativo cuando proceda, y vigilar el uso anómalo de WinRM, especialmente conexiones a TCP 5985 desde estaciones de usuario, limitándolo a estaciones de administración autorizadas. En servidores sensibles, especialmente controladores de dominio, hay que revisar cualquier uso no habitual de FTK Imager. También conviene bloquear o alertar sobre herramientas de exfiltración no autorizadas como LimeWire, y realizar hunts con IOCs y reglas YARA disponibles para el conjunto Snow, incluyendo búsquedas retrospectivas en telemetría.

Dado que el vector se apoya en comunicación directa, la configuración de Teams es un punto de control decisivo: limitar comunicaciones externas a dominios permitidos, o deshabilitar el chat con cuentas externas no gestionadas cuando sea viable, reduce la exposición a inquilinos desechables. A nivel de proceso, hay que imponer un flujo obligatorio de verificación fuera de banda para cualquier contacto de soporte, como llamada a un número interno publicado o validación por número de ticket, antes de ejecutar software o seguir enlaces. Y para cortar la ‘conversión’ a control interactivo, es eficaz restringir Quick Assist y otras herramientas de asistencia remota a roles autorizados con WDAC, AppLocker o políticas equivalentes, además de crear detecciones de correlación, chat externo en Teams seguido de ejecución de QuickAssist.exe, AnyDesk.exe o TeamViewer.exe en una ventana corta. Por último, reforzar Microsoft Defender for Office 365 para Teams, con Safe Links en el momento del clic y Zero hour Auto Purge, y formar específicamente a directivos y mandos intermedios con simulaciones centradas en este patrón, ayuda a reducir la efectividad de un ataque que explota urgencia, confianza y hábitos de trabajo.

Más información

• BleepingComputer – Threat actor uses Microsoft Teams to deploy new ‘Snow’ malware : https://www.bleepingcomputer.com/news/security/threat-actor-uses-microsoft-teams-to-deploy-new-snow-malware/
• Google Cloud Blog (Mandiant / Google Threat Intelligence Group) – Snow Flurries: How UNC6692 Employed Social Engineering to Deploy a Custom Malware Suite : https://cloud.google.com/blog/topics/threat-intelligence/unc6692-social-engineering-custom-malware
• ReliaQuest – Threat Spotlight: Are Former Black Basta Affiliates Automating Executive Targeting? : https://reliaquest.com/blog/threat-spotlight-are-former-black-basta-affiliates-automating-executive-targeting/
• Microsoft Security Blog – Cross-tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook : https://www.microsoft.com/en-us/security/blog/2026/04/18/crosstenant-helpdesk-impersonation-data-exfiltration-human-operated-intrusion-playbook/
• Rapid7 – Guidance on Observed Microsoft Teams Phishing Campaigns : https://www.rapid7.com/blog/post/dr-guidance-on-observed-microsoft-teams-phishing-campaigns
• The Hacker News – UNC6692 Impersonates IT Help Desk via Microsoft Teams to Deploy SNOW Malware : https://thehackernews.com/2026/04/unc6692-impersonates-it-helpdesk-via.html

La entrada UNC6692 usa Microsoft Teams y bombardeo de correo para colar el malware Snow y robar Active Directory se publicó primero en Una Al Día.

La superficie de ataque de muchas aplicaciones web modernas depende de un supuesto básico: que los datos ‘protegidos’ por el framework, como cookies, estados de sesión o tokens auxiliares, no puedan falsificarse ni manipularse sin ser detectados. En ASP.NET Core, esa función la centraliza Data Protection, que se utiliza de forma transversal para asegurar múltiples piezas del flujo de autenticación y de la interacción usuario aplicación.

En este contexto, CVE-2026-40372 se ha publicado como una vulnerabilidad crítica de elevación de privilegios que afecta a Microsoft.AspNetCore.DataProtection en versiones 10.0.0 a 10.0.6. El problema nace de una regresión introducida en la rama de .NET 10: la lógica que genera y comprueba la etiqueta HMAC puede calcularla incorrectamente y, en determinados casos, llegar a descartar el hash calculado. El resultado práctico es un fallo de validación de integridad que permite que ciertos payloads manipulados superen las comprobaciones de autenticidad, abriendo la puerta a falsificación de payloads protegidos.

Esa capacidad es especialmente delicada porque Data Protection se usa en elementos como cookies de autenticación, antiforgery tokens, TempData, y el estado OIDC en flujos de inicio de sesión. En un escenario adverso, un atacante podría construir cookies o tokens que la aplicación aceptase como válidos y, a partir de ahí, escalar permisos. Se ha descrito incluso la posibilidad de llegar a privilegios SYSTEM mediante la falsificación de cookies de autenticación en entornos afectados. Además del riesgo de toma de control, el impacto incluye divulgación de ficheros y modificación de datos, sin que el foco principal esté en la disponibilidad del servicio.

La corrección ha llegado en forma de actualización fuera de banda, .NET 10.0.7, tras detectarse el problema por reportes de errores de descifrado en aplicaciones que habían instalado .NET 10.0.6. Un indicador operativo que puede aparecer en entornos impactados es un aumento de cierres de sesión y mensajes repetidos del tipo ‘The payload was invalid’, junto con señales en el grafo de dependencias que confirmen la carga de una versión vulnerable.

El alcance no es homogéneo en todas las plataformas. El impacto principal se concentra en Linux, macOS y otros sistemas no Windows. En Windows tiende a limitarse a escenarios concretos, por ejemplo cuando se fuerza el uso de algoritmos gestionados con UseCustomCryptographicAlgorithms. También hay matices importantes en cómo se consume la librería: existe una configuración secundaria afectada cuando se usa el asset net462 o netstandard2.0 del paquete Microsoft.AspNetCore.DataProtection entre 10.0.0 y 10.0.6, algo relevante para aplicaciones .NET Framework, bibliotecas netstandard2.0 o proyectos que no ejecutan net10.0. A la vez, hay casos en los que no se llega a cargar el binario vulnerable si en ejecución se utiliza el del shared framework de ASP.NET Core, dependiendo de cómo se haya referenciado Microsoft.AspNetCore.App y de comportamientos como PrunePackageReference en .NET 10.

La acción prioritaria es actualizar a .NET 10.0.7 o subir el paquete Microsoft.AspNetCore.DataProtection a 10.0.7, y después recompilar y redeplegar. Esto es clave en Docker y despliegues basados en imágenes, porque actualizar el runtime del host no basta si la dependencia vulnerable quedó embebida al construir la aplicación durante la ventana afectada.

Actualizar corrige la rutina de validación y hace que los payloads falsificados dejen de aceptarse, pero no resuelve por sí solo un matiz operativo: los tokens emitidos legítimamente durante la ventana vulnerable podrían seguir siendo válidos tras el parche si no se actúa sobre las claves. Si existe posibilidad de abuso en ese periodo, conviene rotar el key ring de ASP.NET Core Data Protection y invalidar o reemitir tokens que puedan persistir, como sesiones, refresh tokens, API keys o enlaces de restablecimiento de contraseña. Para una rotación controlada, puede usarse IKeyManager con RevokeAllKeys, o RevokeKey si se puede acotar qué claves estuvieron activas.

En paralelo, es recomendable confirmar si la aplicación está realmente expuesta. Se puede revisar qué versión se ha resuelto con dotnet list package, comprobar el PackageReference en el .csproj, y validar qué binario se carga en tiempo de ejecución. Como apoyo a la detección, se ha señalado un criterio claro: los payloads forjados durante la ventana vulnerable requieren necesariamente una HMAC con bytes a cero, lo que permite diseñar verificaciones posteriores.

Por último, merece atención la monitorización de tráfico y logs. La guía técnica compara el tipo de capacidad con MS10-070, asociada a condiciones de estilo padding oracle, que en la práctica pueden requerir muchas peticiones. Por ello, es prudente revisar telemetría buscando volúmenes sostenidos y patrones de variación de cookies o parámetros contra endpoints que acepten datos protegidos. Si se han protegido secretos de larga duración con IDataProtector.Protect, como cadenas de conexión o claves de terceros, deben tratarse como potencialmente divulgados si hubo exposición y proceder a su rotación.

Más información

• BleepingComputer – Microsoft releases emergency patches for critical ASP.NET flaw : https://www.bleepingcomputer.com/news/microsoft/microsoft-releases-emergency-security-updates-for-critical-aspnet-flaw/
• Microsoft .NET Blog – : https://devblogs.microsoft.com/dotnet/
• The Hacker News – : https://www.thehackernews.com/
• Microsoft .NET Blog – .NET 10.0.7 Out-of-Band Security Update : https://devblogs.microsoft.com/dotnet/dotnet-10-0-7-oob-security-update/
• GitHub – Microsoft Security Advisory CVE-2026-40372 – ASP.NET Core Elevation of Privilege (dotnet/announcements #395) : https://github.com/dotnet/announcements/issues/395
• Ars Technica – Microsoft issues emergency update for macOS and Linux ASP.NET threat : https://arstechnica.com/security/2026/04/microsoft-issues-emergency-update-for-macos-and-linux-asp-net-threat/
• CSO Online – Microsoft issues out-of-band patch for critical security flaw in update to ASP.NET Core : https://www.csoonline.com/article/4162178/microsoft-issues-out-of-band-patch-for-critical-security-flaw-in-update-to-asp-net-core.html
• CERT-FR (ANSSI) – Vulnérabilité dans Microsoft .Net (CERTFR-2026-AVI-0478) : https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0478/

La entrada Microsoft corrige de urgencia un fallo crítico en ASP.NET Core Data Protection (CVE-2026-40372) se publicó primero en Una Al Día.

La superficie de ataque de muchas aplicaciones web modernas depende de un supuesto básico: que los datos ‘protegidos’ por el framework, como cookies, estados de sesión o tokens auxiliares, no puedan falsificarse ni manipularse sin ser detectados. En ASP.NET Core, esa función la centraliza Data Protection, que se utiliza de forma transversal para asegurar múltiples piezas del flujo de autenticación y de la interacción usuario aplicación.

En este contexto, CVE-2026-40372 se ha publicado como una vulnerabilidad crítica de elevación de privilegios que afecta a Microsoft.AspNetCore.DataProtection en versiones 10.0.0 a 10.0.6. El problema nace de una regresión introducida en la rama de .NET 10: la lógica que genera y comprueba la etiqueta HMAC puede calcularla incorrectamente y, en determinados casos, llegar a descartar el hash calculado. El resultado práctico es un fallo de validación de integridad que permite que ciertos payloads manipulados superen las comprobaciones de autenticidad, abriendo la puerta a falsificación de payloads protegidos.

Esa capacidad es especialmente delicada porque Data Protection se usa en elementos como cookies de autenticación, antiforgery tokens, TempData, y el estado OIDC en flujos de inicio de sesión. En un escenario adverso, un atacante podría construir cookies o tokens que la aplicación aceptase como válidos y, a partir de ahí, escalar permisos. Se ha descrito incluso la posibilidad de llegar a privilegios SYSTEM mediante la falsificación de cookies de autenticación en entornos afectados. Además del riesgo de toma de control, el impacto incluye divulgación de ficheros y modificación de datos, sin que el foco principal esté en la disponibilidad del servicio.

La corrección ha llegado en forma de actualización fuera de banda, .NET 10.0.7, tras detectarse el problema por reportes de errores de descifrado en aplicaciones que habían instalado .NET 10.0.6. Un indicador operativo que puede aparecer en entornos impactados es un aumento de cierres de sesión y mensajes repetidos del tipo ‘The payload was invalid’, junto con señales en el grafo de dependencias que confirmen la carga de una versión vulnerable.

El alcance no es homogéneo en todas las plataformas. El impacto principal se concentra en Linux, macOS y otros sistemas no Windows. En Windows tiende a limitarse a escenarios concretos, por ejemplo cuando se fuerza el uso de algoritmos gestionados con UseCustomCryptographicAlgorithms. También hay matices importantes en cómo se consume la librería: existe una configuración secundaria afectada cuando se usa el asset net462 o netstandard2.0 del paquete Microsoft.AspNetCore.DataProtection entre 10.0.0 y 10.0.6, algo relevante para aplicaciones .NET Framework, bibliotecas netstandard2.0 o proyectos que no ejecutan net10.0. A la vez, hay casos en los que no se llega a cargar el binario vulnerable si en ejecución se utiliza el del shared framework de ASP.NET Core, dependiendo de cómo se haya referenciado Microsoft.AspNetCore.App y de comportamientos como PrunePackageReference en .NET 10.

La acción prioritaria es actualizar a .NET 10.0.7 o subir el paquete Microsoft.AspNetCore.DataProtection a 10.0.7, y después recompilar y redeplegar. Esto es clave en Docker y despliegues basados en imágenes, porque actualizar el runtime del host no basta si la dependencia vulnerable quedó embebida al construir la aplicación durante la ventana afectada.

Actualizar corrige la rutina de validación y hace que los payloads falsificados dejen de aceptarse, pero no resuelve por sí solo un matiz operativo: los tokens emitidos legítimamente durante la ventana vulnerable podrían seguir siendo válidos tras el parche si no se actúa sobre las claves. Si existe posibilidad de abuso en ese periodo, conviene rotar el key ring de ASP.NET Core Data Protection y invalidar o reemitir tokens que puedan persistir, como sesiones, refresh tokens, API keys o enlaces de restablecimiento de contraseña. Para una rotación controlada, puede usarse IKeyManager con RevokeAllKeys, o RevokeKey si se puede acotar qué claves estuvieron activas.

En paralelo, es recomendable confirmar si la aplicación está realmente expuesta. Se puede revisar qué versión se ha resuelto con dotnet list package, comprobar el PackageReference en el .csproj, y validar qué binario se carga en tiempo de ejecución. Como apoyo a la detección, se ha señalado un criterio claro: los payloads forjados durante la ventana vulnerable requieren necesariamente una HMAC con bytes a cero, lo que permite diseñar verificaciones posteriores.

Por último, merece atención la monitorización de tráfico y logs. La guía técnica compara el tipo de capacidad con MS10-070, asociada a condiciones de estilo padding oracle, que en la práctica pueden requerir muchas peticiones. Por ello, es prudente revisar telemetría buscando volúmenes sostenidos y patrones de variación de cookies o parámetros contra endpoints que acepten datos protegidos. Si se han protegido secretos de larga duración con IDataProtector.Protect, como cadenas de conexión o claves de terceros, deben tratarse como potencialmente divulgados si hubo exposición y proceder a su rotación.

Más información

• BleepingComputer – Microsoft releases emergency patches for critical ASP.NET flaw : https://www.bleepingcomputer.com/news/microsoft/microsoft-releases-emergency-security-updates-for-critical-aspnet-flaw/
• Microsoft .NET Blog – : https://devblogs.microsoft.com/dotnet/
• The Hacker News – : https://www.thehackernews.com/
• Microsoft .NET Blog – .NET 10.0.7 Out-of-Band Security Update : https://devblogs.microsoft.com/dotnet/dotnet-10-0-7-oob-security-update/
• GitHub – Microsoft Security Advisory CVE-2026-40372 – ASP.NET Core Elevation of Privilege (dotnet/announcements #395) : https://github.com/dotnet/announcements/issues/395
• Ars Technica – Microsoft issues emergency update for macOS and Linux ASP.NET threat : https://arstechnica.com/security/2026/04/microsoft-issues-emergency-update-for-macos-and-linux-asp-net-threat/
• CSO Online – Microsoft issues out-of-band patch for critical security flaw in update to ASP.NET Core : https://www.csoonline.com/article/4162178/microsoft-issues-out-of-band-patch-for-critical-security-flaw-in-update-to-asp-net-core.html
• CERT-FR (ANSSI) – Vulnérabilité dans Microsoft .Net (CERTFR-2026-AVI-0478) : https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0478/

La entrada Microsoft corrige de urgencia un fallo crítico en ASP.NET Core Data Protection (CVE-2026-40372) se publicó primero en Una Al Día.

Los servicios que ofrecen ejecución de código ‘segura’ en backend suelen apoyarse en una combinación de sandboxing, WebAssembly y contenedores Docker para separar el código no confiable del resto de sistemas. En ese contexto, Cohere AI Terrarium se planteó como un entorno para ejecutar código, a menudo generado o asistido por un LLM, recibiéndolo por HTTP y devolviendo artefactos de salida producidos por esa ejecución. El problema es que una vulnerabilidad recién divulgada rompe precisamente la promesa central del aislamiento.

El defecto, registrado como CVE-2026-5752, permite un escape de sandbox aprovechando una travesía de la cadena de prototipos de JavaScript en el entorno de Pyodide sobre WebAssembly. En términos prácticos, un atacante con capacidad de enviar código para ejecutarse en Terrarium puede manipular objetos del entorno JavaScript para alcanzar constructores peligrosos, como Function constructor, y desde ahí obtener acceso a globalThis. Una vez se llega a ese punto, se abre la puerta a interactuar con internals del entorno de Node.js, incluyendo la posibilidad de llegar a require() y cargar funcionalidades que no deberían estar disponibles para el código ‘encapsulado’.

La causa técnica se relaciona con la forma en que Terrarium construye ciertos objetos globales en su configuración, concretamente en service.ts al preparar jsglobals. En lugar de usar objetos sin prototipo o estructuras endurecidas, se utiliza un objeto literal para simular document, que hereda de Object.prototype. Ese detalle facilita que el atacante encadene accesos a propiedades como proto y patrones del tipo constructor.constructor hasta lograr un salto fuera del modelo de seguridad previsto.

El impacto es alto porque la explotación puede traducirse en ejecución de código arbitrario con privilegios de root en el proceso host de Node.js, además de ejecución de comandos del sistema como root dentro del contenedor. Con ese nivel de control, es factible leer o modificar ficheros sensibles del entorno, por ejemplo /etc/passwd, y exfiltrar variables de entorno que a menudo contienen credenciales, tokens o endpoints internos. También aumenta el riesgo de movimiento lateral dentro de la red accesible desde el contenedor, alcanzando potencialmente bases de datos u otras APIs internas que se daban por protegidas al estar ‘detrás’ del sandbox.

Aunque el hallazgo se centra en el escape del sandbox y el control dentro del contenedor, existe además la posibilidad de un escape del contenedor o escalado adicional en función de cómo esté desplegado Terrarium, qué capabilities tenga el contenedor, si se ejecuta en modo privilegiado, si hay montajes de volúmenes sensibles, o qué controles imponga el runtime. El escenario varía por despliegue, pero el riesgo subyacente es claro: cuando el código no confiable obtiene ejecución como root en un contenedor, cualquier error de configuración o superficie extra en el host puede convertir un incidente aislado en una intrusión mayor.

En cuanto a condiciones de explotación, se trata de un ataque que requiere acceso al servicio para ejecutar código, no necesita interacción adicional del usuario ni privilegios especiales dentro de la aplicación, lo que encaja con el modelo típico de plataformas de ejecución bajo demanda. Además, el propio diseño de Terrarium indica que ‘recicla’ el entorno de Pyodide en cada invocación y que no mantiene estado entre llamadas, lo que ayuda frente a persistencia dentro del runtime, pero no mitiga un escape que permite ejecutar comandos del sistema y acceder a secretos disponibles en el contenedor.

La situación se complica porque, en el momento de la divulgación coordinada, no se indicaba un parche disponible y el repositorio cohere-ai/cohere-terrarium aparece archivado, con la advertencia de que el proyecto ya no tiene soporte y que quien quiera continuar debe bifurcarlo. Esto obliga a las organizaciones a priorizar controles compensatorios y endurecimiento del despliegue. Entre las medidas más inmediatas está deshabilitar temporalmente cualquier funcionalidad que permita a usuarios enviar o ejecutar código en Terrarium si es viable, o restringirla de forma drástica a usuarios y servicios estrictamente autorizados.

Si el servicio debe seguir funcionando, es clave reducir el impacto potencial: ejecutar el proceso host sin root, aplicar el principio de mínimos privilegios, eliminar capacidades innecesarias del contenedor, y reforzar el aislamiento envolviendo Terrarium en una capa adicional, por ejemplo una máquina virtual dedicada o un dominio separado. En paralelo, conviene segmentar la red para limitar el alcance a otros servicios, y revisar qué destinos puede alcanzar el contenedor a nivel de egress.

En detección y respuesta, es útil instrumentar alertas sobre patrones típicos de esta clase de ataques, como accesos a proto, usos de constructor.constructor, o señales de creación de procesos y ejecución de comandos desde el contexto del sandbox. Complementariamente, un WAF puede ayudar a bloquear tráfico sospechoso hacia el endpoint HTTP que recibe código y ficheros de entrada, pero debe acompañarse de controles de autorización estrictos, límites de recursos y registros detallados de ejecuciones. También se recomienda monitorizar el contenedor para identificar comportamientos anómalos, como lecturas inesperadas de rutas sensibles o conexiones hacia servicios internos.

A medio plazo, si se decide mantener Terrarium mediante un fork, una línea de mitigación técnica es intentar bloquear o congelar prototipos en el entorno de JavaScript cuando el diseño lo permita, para dificultar la manipulación de la cadena de prototipos. En cualquier caso, esta vulnerabilidad refuerza una lección recurrente en plataformas de ejecución: un sandbox basado en WASM y contenedores no debe considerarse un perímetro suficiente por sí solo, y menos aún si el componente host corre con privilegios elevados y expone superficies como Node.js a código no confiable.

Más información

• The Hacker News – Cohere AI Terrarium Sandbox Flaw Enables Root Code Execution, Container Escape : https://thehackernews.com/2026/04/cohere-ai-terrarium-sandbox-flaw.html
• CERT Coordination Center (CERT/CC) – Vulnerability Note VU#414811 : https://kb.cert.org/vuls/id/414811?utm_source=openai
• NVD – CVE-2026-5752 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-5752?utm_source=openai
• Tenable – CVE-2026-5752 : https://www.tenable.com/cve/CVE-2026-5752
• SentinelOne – CVE-2026-5752: Terrarium Sandbox Escape RCE Vulnerability : https://www.sentinelone.com/vulnerability-database/cve-2026-5752/
• GitHub (cohere-ai) – cohere-ai/cohere-terrarium : https://github.com/cohere-ai/cohere-terrarium

La entrada Un fallo crítico en Cohere AI Terrarium permite saltarse el sandbox y ejecutar código como root se publicó primero en Una Al Día.