Más allá del malware en dependencias, este incidente muestra cómo un fallo de higiene en CI/CD puede convertir una intrusión limitada en un problema mayor: basta con que una sola credencial quede fuera del proceso de contención para reabrir la puerta. En el caso de Grafana Labs, el vector inicial se relaciona con el compromiso de la cadena de suministro de TanStack en npm, que llevó a la exposición de credenciales dentro de su entorno de GitHub Actions.

El ataque a TanStack se concentró en una ventana muy corta, el 11 de mayo de 2026 entre las 19:20 y las 19:26 UTC, y consistió en la publicación de decenas de versiones maliciosas, 84 en total, repartidas en 42 paquetes @tanstack/. La campaña abusó de OIDC Trusted Publishing de GitHub Actions, lo que permitió publicar en el registro con un token OIDC obtenido durante un workflow, sin depender de tokens de npm de larga duración. A nivel técnico, se ha descrito una cadena que combina un workflow con pull_request_target, un patrón conocido como Pwn Request, junto con cache poisoning en las cachés de GitHub Actions* entre forks y el repositorio base, y la extracción de secretos desde la memoria del runner.

Dentro de esos paquetes, los manifiestos incluían una optionalDependency que apuntaba a un commit huérfano en GitHub, usando el nombre ficticio @tanstack/setup y la referencia github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c. La carga útil, identificada como router_init.js y con un tamaño aproximado de 2,3 MB, se ejecutaba durante la instalación a través de scripts del ecosistema npm, y realizaba robo de credenciales. La exfiltración se apoyaba en infraestructura asociada a Session, destacando filev2.getsession.org y varios seed*.getsession.org, con comunicaciones cifradas de extremo a extremo. Además, se observaron comportamientos de propagación tipo gusano, ya que el malware enumeraba paquetes mantenidos por la víctima y republicaba versiones comprometidas, maximizando el alcance dentro del ecosistema.

En Grafana, esa fase inicial permitió que se filtraran tokens de workflows. La compañía detectó actividad maliciosa el 1 de mayo y rotó numerosos tokens de GitHub Actions como parte de la respuesta. Sin embargo, una credencial concreta quedó fuera del proceso de rotación, y ese token ‘rezagado’ se utilizó después para acceder a repositorios privados. El resultado confirmado fue la descarga de código fuente, además de información operativa y datos de contactos comerciales, como nombres y correos empleados en relaciones profesionales.

En paralelo, la actividad maliciosa vinculada a TanStack se detectó el 11 de mayo de 2026 y la extorsión a Grafana se recibió el 16 de mayo de 2026. La organización notificó a autoridades federales y optó por no pagar, en línea con la recomendación del FBI de no negociar pagos. En cuanto al impacto, el alcance confirmado se limita al entorno de GitHub de la compañía, sin evidencias de compromiso de Grafana Cloud ni de sistemas de producción u operaciones de clientes. También se indicó que no se modificó el código durante el incidente, por lo que el código descargado por usuarios en ese periodo se considera seguro.

Para equipos que operan pipelines similares, la lección principal es operativa: tras cualquier indicio de exfiltración, hay que inventariar y rotar de forma completa todas las credenciales usadas en CI/CD, sin excluir workflows por una clasificación errónea. Es clave revisar jobs que consumieron dependencias potencialmente afectadas y qué secretos estuvieron disponibles en ejecución, aplicar mínimo privilegio al GITHUB_TOKEN y a los permisos de workflows, y reforzar la observabilidad con alertas por autenticaciones inusuales, clones o descargas masivas de repositorios privados.

En defensa de la cadena de suministro, conviene endurecer el consumo de dependencias con pinning de versiones, controles de integridad y revisiones antes de ejecutar en CI. En momentos de alto riesgo, se puede recurrir temporalmente a instalaciones más estrictas, como npm ci o pnpm con frozen lockfile, e incluso usar ignore scripts como control defensivo mientras se valida la integridad. Si existe sospecha de cache poisoning, es recomendable purgar y rotar cachés de GitHub Actions y de gestores de paquetes, incluido el almacén de pnpm, antes de reanudar publicaciones.

También se han descrito mecanismos de persistencia fuera de node_modules, con artefactos en directorios .vscode y .claude, que pueden sobrevivir a un borrado de dependencias. Se documentó un componente destructivo, gh-token-monitor, con persistencia en macOS mediante LaunchAgents y en Linux mediante systemd de usuario, capaz de borrar el directorio home si detecta revocación del token. Por ello, antes de revocar tokens potencialmente expuestos, conviene buscar y eliminar persistencia para reducir el riesgo de acciones destructivas.

Como verificación concreta, se recomienda buscar en lockfiles y artefactos de build la huella @tanstack/setup con la referencia github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c y tratar cualquier coincidencia como incidente. Otra práctica útil es validar versiones sin ejecutar scripts, por ejemplo descargando el tarball con npm pack para revisar el package.json y detectar la presencia de router_init.js. En paralelo, bloquear y monitorizar tráfico saliente hacia filev2.getsession.org y seed*.getsession.org, además de cualquier IOC confirmado, ayuda a cortar la exfiltración.

Por último, si se utiliza OIDC Trusted Publishing para npm, merece la pena limitar su alcance a un workflow concreto y a una rama protegida, evitando confianza a nivel de repositorio cuando sea posible. Y, de forma crítica, incorporar un paso de verificación post incidente que confirme con evidencias que la rotación de todos los tokens y secretos se completó de verdad, para que no vuelva a ocurrir lo que aquí desencadenó el acceso a repositorios privados: un solo token olvidado.

Más información

• BleepingComputer – Grafana breach caused by missed token rotation after TanStack attack : https://www.bleepingcomputer.com/news/security/grafana-breach-caused-by-missed-token-rotation-after-tanstack-attack/
• Grafana Labs – Grafana Labs security update: Latest on TanStack npm supply chain ransomware incident : https://grafana.com/blog/grafana-labs-security-update-latest-on-tanstack-npm-supply-chain-ransomware-incident/
• TanStack Blog – Postmortem: TanStack npm supply-chain compromise : https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
• GitHub Advisory Database – Malware in @tanstack/* packages exfiltrates cloud credentials, GitHub tokens, and SSH keys (GHSA-g7cv-rxg3-hmpx) : https://github.com/advisories/GHSA-g7cv-rxg3-hmpx
• Endor Labs – Shai-Hulud compromises the @tanstack ecosystem: 80+ packages compromised : https://www.endorlabs.com/learn/shai-hulud-compromises-the-tanstack-ecosystem-80-packages-compromised
• Orca Security – TanStack and 160+ npm/PyPI Packages Compromised in Supply Chain Worm Attack : https://orca.security/resources/blog/tanstack-npm-supply-chain-worm/

La entrada Grafana atribuye el acceso a repositorios privados a un token de GitHub Actions que no se rotó tras el ataque a TanStack se publicó primero en Una Al Día.

El incidente vuelve a poner el foco en un punto débil recurrente en la seguridad del desarrollo: el endpoint del desarrollador. Aunque muchas organizaciones concentran controles en el perímetro, en CI/CD o en el propio repositorio, una simple instalación en el editor puede abrir la puerta a robo de credenciales, acceso a código y movimiento lateral. En este caso, el vector inicial fue una extensión de Visual Studio Code manipulada con fines maliciosos instalada en el equipo de un empleado.

Tras el compromiso del dispositivo, se produjo la exfiltración de aproximadamente 3.800 repositorios internos de GitHub. GitHub aseguró que no hay evidencias de impacto en datos de clientes fuera del conjunto de repositorios afectados, un matiz importante porque este tipo de fuga suele mezclar código, documentación, scripts de despliegue y, en el peor de los casos, secretos incrustados por error. Como parte de la respuesta, la empresa retiró del VS Code Marketplace la versión maliciosa de la extensión, aisló el endpoint comprometido y rotó credenciales críticas el mismo día, priorizando los secretos más sensibles.

La atribución pública está en evolución. El actor TeamPCP reivindicó el acceso y llegó a ofrecer los datos presuntamente robados por un mínimo de 50.000 dólares, acompañando la presión con amenazas de filtración gratuita si no aparecía comprador. A falta de verificación independiente completa, el episodio encaja con una serie de campañas atribuidas a TeamPCP desde marzo de 2026, orientadas a ecosistemas de desarrollo y a compromisos de cadena de suministro, donde la rapidez es parte de la ventaja del atacante. En incidentes recientes, la ventana de exposición puede ser de minutos: un ejemplo citado en el sector es la retirada de una versión con backdoor de una extensión popular, Nx Console, en cuestión de decenas de minutos, lo que ilustra que confiar solo en reacciones del marketplace no basta para entornos corporativos.

Los análisis técnicos publicados en torno a esta oleada describen técnicas de persistencia especialmente preocupantes para equipos que clonan repositorios con frecuencia. Se ha observado un patrón denominado Mini Shai Hulud, descrito como un gusano de cadena de suministro capaz de persistir mediante modificaciones en ficheros de configuración del propio entorno de desarrollo. Entre las señales a vigilar destacan inyecciones en .vscode/tasks.json con disparadores como folderOpen, y cambios en el directorio .claude, por ejemplo .claude/settings.json o ficheros inesperados como .claude/setup.mjs, con disparadores tipo SessionStart. El riesgo práctico es la reinfección: basta con volver a clonar un repositorio contaminado y abrirlo para reactivar tareas o flujos que descarguen y ejecuten carga maliciosa.

En la misma cadena técnica se han descrito abusos de scripts de instalación en npm, como preinstall o postinstall, junto con la descarga y ejecución del runtime Bun como bootstrap del payload. Para investigación y hunting, se ha propuesto buscar en historiales de commits el indicador IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner, que se ha usado como marca de infección en casos relacionados. También conviene añadir detecciones en EDR y SIEM para ejecuciones de bun iniciadas tras npm install o por procesos de VS Code, además de patrones de conexiones a objects.githubusercontent.com asociadas a instalaciones, cuando se utilicen como mecanismo de descarga.

El impacto potencial no se limita a la fuga de código. En campañas atribuidas a TeamPCP se han documentado técnicas contra GitHub Actions, incluyendo el envenenamiento de versiones mediante force push que repunta múltiples tags hacia commits maliciosos. Este enfoque puede permitir el robo de secretos en runners y, en escenarios avanzados, intentos de lectura de memoria del proceso Runner.Worker. Además, se han observado canales de exfiltración y mando y control mediante dominios typosquat y, de forma oportunista, el uso de GitHub como canal alternativo, por ejemplo creando repositorios públicos para volcado cifrado o utilizando patrones de búsqueda de commits como dead drop.

En términos defensivos, la lección principal es tratar las extensiones del IDE como software con capacidad equivalente a un agente privilegiado. Es recomendable restringir la instalación de extensiones en VS Code mediante políticas corporativas, allowlists y bloqueo de orígenes no autorizados, y mantener un inventario auditado de extensiones instaladas en los equipos de desarrollo. También se recomienda no basarse en ficheros de recomendación del repositorio como mecanismo de control y aplicar controles a nivel de máquina mediante MDM o políticas gestionadas.

En paralelo, debe asumirse que cualquier repositorio interno puede contener credenciales expuestas por error o accesos útiles para pivotar. Por eso, conviene rotar tokens y secretos que pudieran existir en repositorios, automatizaciones y sistemas de build, incluyendo PATs, credenciales de CI, secretos de GitHub Actions y tokens de GitHub Apps. Tras la rotación, es clave revisar registros y telemetría para detectar abuso posterior, accesos anómalos, clonados masivos y operaciones fuera de patrón. Para minimizar el radio de explosión, aplicar mínimo privilegio a cuentas de desarrollador y permisos a repositorios reduce lo que un atacante puede extraer desde un único endpoint comprometido.

Como medida preventiva adicional, es útil imponer un periodo de enfriamiento para nuevas versiones de extensiones y dependencias, por ejemplo 24 a 72 horas, antes de permitir su instalación o actualización en equipos y en CI, y endurecer la cadena de dependencias en npm con lockfiles, npm ci y, cuando sea viable, desactivar scripts de ciclo de vida con ignore-scripts en CI. En entornos maduros, limitar el acceso directo de equipos y runners a registros públicos y enrutar descargas a través de un proxy o registro privado con control de egress reduce la superficie. Finalmente, conviene monitorizar señales de exfiltración encubierta, como creación inesperada de repositorios públicos o commits con patrones anómalos, porque la salida de datos no siempre ocurre por canales tradicionales.

GitHub ha indicado que publicará un informe más completo cuando termine la investigación. Mientras tanto, el caso sirve como recordatorio de que la cadena de suministro no empieza en el repositorio, empieza en el editor, en el gestor de paquetes y en cada actualización que un desarrollador instala para trabajar más rápido.

Más información

• BleepingComputer – GitHub confirms breach of 3,800 repos via malicious VSCode extension : https://www.bleepingcomputer.com/news/security/github-confirms-breach-of-3-800-repos-via-malicious-vscode-extension/amp/
• The Record (Recorded Future News) – GitHub confirms being hacked by TeamPCP, says customer data unaffected : https://therecord.media/github-confirms-teampcp-hack-customers-unaffected
• Aikido Security (blog) – GitHub breached via a malicious VS Code extension: why developer devices are the real target : https://www.aikido.dev/blog/github-breached-vs-code-extension
• Hive Security (blog) – One Extension, 3,800 Repos: Inside TeamPCP’s GitHub Breach : https://hivesecurity.gitlab.io/blog/github-breach-vscode-extension-teampcp-2026/
• Phoenix Security (blog) – TeamPCP’s Five-Day Siege: How One Stolen Token Cascaded Across GitHub Actions, Checkmarx, VS Code Extensions, and npm : https://phoenix.security/teampcp-supply-chain-attack-trivy-checkmarx-github-actions-npm-canisterworm/
• Unit 42, Palo Alto Networks (research) – The npm Threat Landscape: Attack Surface and Mitigations (Updated May 1) : https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/?_wpnonce=e85efdbd7a&lg=en&pdf=print

La entrada GitHub confirma la exfiltración de 3.800 repositorios internos tras una extensión maliciosa de VS Code se publicó primero en Una Al Día.

La publicación de una prueba de concepto funcional para MiniPlasma eleva el riesgo defensivo en entornos Windows, no porque facilite una intrusión desde cero, sino porque convierte un acceso previo limitado en control total del equipo. En la práctica, este tipo de escalada local de privilegios (LPE) suele ser el paso decisivo tras un primer ‘foothold’, por ejemplo mediante phishing, documentos maliciosos o la ejecución de un instalador adulterado con permisos de usuario estándar.

La técnica se apoya en el componente Windows Cloud Filter, concretamente el controlador cldflt.sys, y en una rutina asociada al control de acceso a placeholders, citada como HsmOsBlockPlaceholderAccess. El abuso descrito gira alrededor de una API no documentada, CfAbortHydration, que permitiría forzar condiciones en las que se crean entradas del Registro de Windows sin las comprobaciones de permisos que cabría esperar. El resultado es la capacidad de crear claves arbitrarias en el hive .DEFAULT, lo que abre escenarios en los que un atacante local puede preparar el terreno para ejecutar acciones con privilegios máximos.

Lo más llamativo es que el PoC se ha verificado en Windows 11 en su versión pública más reciente y con las actualizaciones de Patch Tuesday de mayo de 2026 aplicadas. También se indica una confirmación independiente en esa misma rama estable. En cambio, no habría funcionado en una compilación específica de Windows 11 Insider Preview Canary, un detalle que sugiere diferencias en el código o mitigaciones presentes en canales de prueba. Además, al presentarse como una posible race condition, la fiabilidad del exploit puede variar entre sistemas, cargas y timing, algo habitual en defectos de esta naturaleza.

Este caso se interpreta como una reaparición o persistencia de CVE-2020-17103, una EoP con CVSS 7.0 que se daba por corregida en diciembre de 2020 y que ya se había relacionado con manipulación del registro mediante una API no documentada, incluyendo la creación de una clave en el hive DEFAULT sin controles de acceso. Incluso se apunta a que el PoC original atribuido a Google Project Zero podría funcionar sin cambios, lo que, de confirmarse, reforzaría la idea de una corrección incompleta o de un comportamiento reintroducido con el tiempo. Microsoft ha reconocido que está investigando el informe y que tomará medidas para proteger a los clientes.

En paralelo, conviene encajar este episodio en un patrón más amplio: el ecosistema de Windows Cloud Files ya ha sido un objetivo de alto valor. En diciembre de 2025 se corrigió CVE-2025-62221, un use after free en el mismo ámbito, y se identificó explotación activa. Es un recordatorio de que las elevaciones de privilegios, aunque no sean un vector de entrada, se utilizan para desactivar defensas, obtener credenciales y facilitar movimiento lateral. No es casual que, en el Patch Tuesday de mayo de 2026, Microsoft abordase un volumen muy alto de fallos, con una proporción relevante de vulnerabilidades de elevación de privilegios, lo que refuerza la necesidad de parchear rápido incluso aquello que ‘solo’ afecta a post explotación.

A nivel práctico, la prioridad inmediata es endurecer detección y respuesta. Resulta recomendable bloquear y detectar la ejecución de binarios asociados al PoC con reglas de EDR, y aumentar la telemetría sobre creación y modificación anómala de claves en el contexto de .DEFAULT. En particular, se proponen rutas concretas a vigilar por actividad compatible con esta técnica: \Registry\User\Software\Policies\Microsoft\CloudFiles\BlockedApps y \Registry\User\.DEFAULT\Volatile Environment. Junto a ello, conviene revisar el mínimo privilegio** real en estaciones y servidores, ajustar restricciones de ejecución para usuarios estándar y reforzar controles de post compromiso, especialmente en equipos que no puedan actualizarse de inmediato.

Para organizaciones con capacidad de ingeniería interna, es sensato validar la exposición mediante pruebas controladas en laboratorio, usando sistemas equivalentes a producción, antes de desplegar mitigaciones a gran escala. También es un buen momento para inventariar endpoints donde el subsistema Cloud Files y cldflt.sys sean relevantes, y verificar de forma continua que las actualizaciones se aplican correctamente, sobre todo tras la publicación de PoC públicos.

Por último, aunque no esté directamente conectado con MiniPlasma, la higiene operativa en PowerShell sigue siendo clave en cadenas de ataque reales. Revisar scripts administrativos que descargan contenido con Invoke WebRequest, evitando parámetros inseguros y aplicando UseBasicParsing cuando proceda, ayuda a reducir ejecuciones accidentales y a cerrar vías de abuso que a menudo proporcionan ese primer acceso local que luego se convierte en SYSTEM.

Más información

• BleepingComputer – New Windows ‘MiniPlasma’ zero-day exploit gives SYSTEM access, PoC released : https://www.bleepingcomputer.com/news/microsoft/new-windows-miniplasma-zero-day-exploit-gives-system-access-poc-released/
• The Hacker News – Mini Shai-Hulud Pushes Malicious AntV npm Packages via Compromised Maintainer Account : https://thehackernews.com/
• SecurityWeek – Researcher Drops MiniPlasma Windows Exploit for Unpatched 2020 CVE : https://www.securityweek.com/researcher-drops-miniplasma-windows-exploit-for-unpatched-2020-cve/
• The Hacker News – MiniPlasma Windows 0-Day Enables SYSTEM Privilege Escalation on Fully Patched Systems : https://thehackernews.com/2026/05/miniplasma-windows-0-day-enables-system.html
• Tenable – Microsoft’s May 2026 Patch Tuesday Addresses 118 CVEs (CVE-2026-41103) : https://www.tenable.com/blog/microsofts-may-2026-patch-tuesday-addresses-118-cves-cve-2026-41103
• CSO Online – December Patch Tuesday: Windows Cloud Files Mini Filter Driver hole already being exploited : https://www.csoonline.com/article/4103681/december-patch-tuesday-windows-cloud-files-mini-filter-driver-hole-already-being-exploited.html
• Malwarebytes – December Patch Tuesday fixes three zero-days, including one that hijacks Windows devices : https://www.malwarebytes.com/blog/news/2025/12/december-patch-tuesday-fixes-three-zero-days-including-one-that-hijacks-windows-devices

La entrada MiniPlasma: un PoC reabre una escalada local a SYSTEM en Windows 11 pese a estar parcheado se publicó primero en Una Al Día.

La seguridad del plano de control en entornos SD-WAN vuelve a situarse en el centro de atención por un defecto que afecta a componentes que suelen estar muy cerca del ‘corazón’ de la red. En despliegues donde Cisco Catalyst SD-WAN Controller y Cisco Catalyst SD-WAN Manager concentran la orquestación y las conexiones de control, un fallo crítico puede traducirse en cambios de configuración a gran escala, pérdida de integridad del enrutamiento y acceso persistente a funciones de administración.

La vulnerabilidad CVE-2026-20182 tiene severidad crítica (CVSS 10.0) y permite a un atacante remoto sin autenticar eludir la autenticación y obtener privilegios administrativos en los componentes de control afectados. El problema reside en el mecanismo de autenticación durante el emparejamiento al establecer conexiones de control, de forma que un actor externo puede ‘presentarse’ como un peer válido y alcanzar un nivel de acceso equivalente al de un usuario interno de alto privilegio, aunque no se trate de acceso root. Aun así, el impacto es especialmente delicado porque habilita el acceso a NETCONF y, con ello, la capacidad de manipular la configuración del tejido SD-WAN.

El riesgo se dispara cuando los sistemas de Catalyst SD-WAN Controller están expuestos a Internet con puertos accesibles públicamente. La superficie de ataque descrita incluye vdaemon sobre DTLS en UDP 12346, además de NETCONF over SSH en TCP 830 y SSH en TCP 22. En la práctica, comprometer vdaemon puede implicar comprometer la confianza del tejido, ya que el atacante puede establecer relaciones de peering que no deberían existir y, después, aprovechar interfaces de gestión para mantener control.

A nivel técnico, el bypass puede lograrse completando el DTLS handshake con cualquier certificado y respondiendo al CHALLENGE con un CHALLENGE_ACK que declara un tipo de dispositivo vHub con el valor indicado, evitando así parte de la verificación del certificado en el flujo de vdaemon. Tras ello, el envío de un mensaje Hello permite que el peer pase a estado up una vez marcado como autenticado. Además, se ha descrito una vía de persistencia basada en la inyección de una clave SSH mediante MSG_VMANAGE_TO_PEER, un tipo de mensaje que permite escribir en modo append en /home/vmanage-admin/.ssh/authorized_keys, facilitando accesos posteriores. Existe incluso un módulo de Metasploit, cisco_sdwan_vhub_auth_bypass, que automatiza el bypass y la inyección de claves, y abre la puerta a interactuar con NETCONF por SSH en el puerto 830.

Se ha observado explotación de forma limitada en mayo de 2026, y no hay mitigaciones parciales que ‘compensen’ el defecto. La corrección requiere actualizar a versiones específicas según rama, con ejemplos como 20.9.9.1, 20.12.7.1, 20.12.6.2, 20.12.5.4, 20.15.5.2, 20.15.4.4, 20.18.2.2 o 26.1.1.1. En entornos Cisco SD-WAN Cloud gestionados, la corrección se incorpora en 20.15.506 sin acción del cliente, pero en despliegues on premises la actualización es imprescindible. En paralelo, conviene recordar que se ha señalado CVE-2026-20127 como vulnerabilidad distinta, ya corregida previamente, y que en el ecosistema SD-WAN se han descrito cadenas de ataque con otros CVE, lo que refuerza la necesidad de parchear de forma integral, no solo ‘el último’ fallo.

Antes de aplicar cambios, se recomienda conservar evidencias ejecutando request admin-tech en cada componente de control. Para búsqueda de compromisos, un primer punto de control es /var/log/auth.log, identificando entradas como Accepted publickey for vmanage-admin desde IPs no autorizadas. También es útil comparar las IPs observadas con los System IP configurados en la WebUI en la ruta de dispositivos, para detectar incoherencias. En los controladores, los eventos de peering deben validarse manualmente, revisando hora, IP pública de origen, system IP, tipo de peer y su correlación con actividad autorizada, especialmente si aparecen peers de tipo vmanage fuera de lo esperado.

Como apoyo adicional, puede revisarse el estado del plano de control con show control connections detail o show control connections-history detail. Si se detectan patrones sospechosos, por ejemplo conexiones en state up con challenge-ack 0, es recomendable escalarlo con Cisco TAC para confirmación y guía de respuesta. Si existe cualquier indicio de autenticación exitosa desde una IP desconocida o de peering no autorizado, conviene tratar el sistema como comprometido, abrir un caso con Cisco TAC incluyendo CVE-2026-20182 y evitar acciones disruptivas antes de recopilar artefactos.

En cuanto a hardening, la prioridad es reducir exposición: impedir el acceso directo desde Internet a UDP 12346 y TCP 830, y limitar esos puertos a las IP estrictamente necesarias del plano de control mediante filtrado y listas de permitidos. Para verificar persistencia, debe revisarse /home/vmanage-admin/.ssh/authorized_keys, eliminando claves no autorizadas y rotando credenciales y claves de administración si aparecen entradas sospechosas. También se recomienda auditar si se ha activado PermitRootLogin en /etc/ssh/sshd_config y buscar señales de encubrimiento, como borrados en syslog, wtmp, lastlog, bash_history o cli-history.

En vManage, la caza puede ampliarse revisando /var/log/nms/containers/service-proxy/serviceproxy-access.log en busca de accesos a data-collection-agent/.dca y solicitudes POST a rutas que terminen en .gz o .jsp, diferenciando respuestas HTTP 200 como una señal fuerte de ejecución de webshell. Asimismo, en /var/log/nms/vmanage-server.log conviene localizar eventos asociados a SmartLicensingManager que intenten escribir ficheros usando traversal ../ hacia despliegues de wildfly, registrando los nombres de payload detectados para su escalado.

La respuesta más efectiva combina parcheo inmediato y reducción de superficie. Además de CVE-2026-20182, es recomendable cerrar el resto de CVE relacionados con acceso inicial y cadenas publicadas, como CVE-2026-20133, CVE-2026-20128 y CVE-2026-20122, y abordar también escalados como CVE-2022-20775 cuando aplique. En un contexto en el que se han descrito múltiples clústeres oportunistas tras la publicación de PoC, mantener un enfoque de actualización integral y una verificación rigurosa de logs, claves y conexiones de control es clave para reducir el riesgo operativo en redes SD-WAN.

Más información

• BleepingComputer – Cisco warns of new critical SD-WAN flaw exploited in zero-day attacks : https://www.bleepingcomputer.com/news/security/cisco-warns-of-new-critical-sd-wan-flaw-exploited-in-zero-day-attacks/amp/
• Cisco Security Advisory – Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-rpa2-v69WY2SW
• Rapid7 – CVE-2026-20182: Critical authentication bypass in Cisco Catalyst SD-WAN Controller (FIXED) : https://www.rapid7.com/blog/post/ve-cve-2026-20182-critical-authentication-bypass-cisco-catalyst-sd-wan-controller-fixed/
• Help Net Security – Cisco patches another actively exploited SD-WAN zero-day (CVE-2026-20182) : https://www.helpnetsecurity.com/2026/05/15/cisco-sd-wan-zero-day-cve-2026-20182/
• Tenable – Frequently asked questions about the continued exploitation of Cisco Catalyst SD-WAN vulnerabilities (CVE-2026-20182) : https://www.tenable.com/blog/faq-about-the-continued-exploitation-of-cisco-catalyst-sd-wan-vulnerabilities-uat-8616
• The Hacker News – CISA Adds Cisco SD-WAN CVE-2026-20182 to KEV After Admin Access Exploits : https://thehackernews.com/2026/05/cisa-adds-cisco-sd-wan-cve-2026-20182.html
• Cisco Support – Remediate Catalyst SD-WAN Security Advisory (February 2026) : https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/225525-internal-remediate-catalyst-sd-wan.html

La entrada Cisco corrige un bypass de autenticación crítico en Catalyst SD-WAN se publicó primero en Una Al Día.

La comunidad de desarrollo de software se enfrenta a una de las amenazas más sofisticadas de los últimos tiempos. Bajo el nombre de Shai-Hulud, una campaña de ataque a la cadena de suministro ha logrado infiltrar cientos de paquetes en los registros de npm y PyPI, afectando a proyectos de gran relevancia como TanStack y Mistral AI. Lo que hace que este ataque sea especialmente peligroso es su capacidad para eludir las defensas tradicionales mediante el uso de tokens OIDC legítimos y firmas digitales válidas, lo que otorga a los paquetes maliciosos una apariencia de autenticidad absoluta.

¿En qué consiste el ataque?

La campaña representa una evolución táctica que demuestra un conocimiento profundo de los flujos de trabajo de CI/CD (Integración Continua y Despliegue Continuo). Comenzó comprometiendo decenas de paquetes en los espacios de nombres de TanStack y Mistral AI, pero rápidamente se expandió a otros proyectos críticos como Guardrails AI, UiPath y OpenSearch.

El núcleo del problema reside en el encadenamiento de tres vulnerabilidades críticas en los flujos de trabajo de GitHub Actions:

1. Workflows de pull_request_target de alto riesgo: configuraciones inseguras que permitieron a los atacantes ejecutar código en el contexto del repositorio principal.
2. Envenenamiento de la caché de GitHub Actions: una técnica que permite inyectar dependencias maliciosas que luego son utilizadas por el sistema de construcción.
3. Robo de tokens OIDC desde la memoria del runner: al extraer estos tokens, los atacantes pudieron publicar versiones maliciosas con atestación de procedencia SLSA, lo que significa que, para los sistemas de seguridad automatizados, los paquetes parecían 100% legítimos y construidos en el entorno oficial.

Impacto: robo masivo de credenciales

El objetivo principal de Shai-Hulud no es solo el sabotaje, sino el espionaje y el robo de secretos de desarrolladores. El malware inyectado busca de forma exhaustiva en el entorno de la víctima para extraer credenciales sensibles, incluyendo:

• Tokens de GitHub Actions y Personal Access Tokens (PATs).
• Credenciales de publicación en npm y credenciales de Git.
• Secretos de AWS Manager, IAM y Kubernetes.
• Configuraciones de herramientas de IA como Claude Code y tareas de VS Code.

Para evadir la detección, el malware utiliza la red de Session Messenger (basada en la infraestructura descentralizada de Oxen/Lokinet), lo que hace que el tráfico de exfiltración parezca comunicación cifrada de mensajería legítima, complicando enormemente las tareas de bloqueo por parte de los equipos de seguridad.

Además, se ha detectado un comportamiento de sabotaje selectivo: en entornos cuyas variables sugieren ubicación en Israel o Irán, el malware tiene una probabilidad aproximada de 1 entre 6 de ejecutar un comando de borrado recursivo (rm -rf /), lo que subraya la naturaleza destructiva y posiblemente geopolítica de la operación.

Versiones afectadas y alcance técnico

Diferentes firmas de seguridad han proporcionado cifras alarmantes sobre el alcance de la campaña. Endor Labs ha identificado más de 160 paquetes comprometidos en npm, mientras que Socket ha rastreado hasta 416 artefactos comprometidos entre npm y PyPI.

Componentes clave afectados:

Recomendaciones de Seguridad

Dada la sofisticación del ataque, en el que la firma digital ya no es garantía de seguridad, se recomienda a los equipos de desarrollo y seguridad tomar medidas inmediatas:

• Auditoría de versiones: revisar exhaustivamente los archivos package-lock.json, yarn.lock, pnpm-lock.yaml o poetry.lock en busca de actualizaciones inesperadas en los últimos días, especialmente de los proyectos mencionados.
• Rotación de credenciales: si se ha descargado alguna versión afectada, asumir que todos los secretos en esa máquina o entorno de CI/CD están comprometidos. Es imperativo rotar tokens de GitHub, npm, AWS y claves SSH.
• Limpieza de persistencia: el malware puede integrarse en hooks de herramientas como Claude Code y en archivos tasks.json de VS Code. Desinstalar el paquete no elimina la amenaza; es necesario auditar los directorios de configuración de los IDE.
• Lockfiles estrictos: forzar instalaciones basadas únicamente en archivos de bloqueo (npm ci, pnpm install --frozen-lockfile, pip install --require-hashes) para evitar actualizaciones automáticas o silenciosas.
• Bloqueo de infraestructura C2: bloquear los dominios e indicadores de compromiso (IOCs) que vayan publicando fuentes verificadas como Socket, Endor Labs, StepSecurity y Aikido Security en sus boletines oficiales.

Más información

• Shai Hulud attack ships signed malicious TanStack, Mistral npm packages – https://www.bleepingcomputer.com/news/security/shai-hulud-attack-ships-signed-malicious-tanstack-mistral-npm-packages/

La entrada Shai-Hulud: ataque a la cadena de suministro compromete cientos de paquetes en npm y PyPI se publicó primero en Una Al Día.

La compañía dio a conocer los avisos este 12 de mayo y la lectura, más allá del detalle técnico, es bastante directa: no se trata de fallos menores ni de esos problemas que pueden dejarse para la siguiente ventana de mantenimiento. En los dos casos, la propia documentación de Fortinet describe un escenario en el que un atacante no autenticado puede lanzar peticiones manipuladas para ejecutar código o comandos sobre sistemas vulnerables, una combinación especialmente delicada cuando estos equipos están expuestos o cumplen funciones críticas dentro de la red.

El primero de los fallos es CVE-2026-44277, una vulnerabilidad de control de acceso incorrecto en la API de FortiAuthenticator. Según el aviso oficial, afecta a las ramas 6.5, 6.6 y 8.0 en varias versiones concretas y queda corregido al actualizar a 6.5.7, 6.6.9 y 8.0.3. La buena noticia para quienes usan la edición en la nube es que FortiAuthenticator Cloud no está afectado.

El segundo es CVE-2026-26083, un fallo de autorización insuficiente en la interfaz web de FortiSandbox, FortiSandbox Cloud y FortiSandbox PaaS. En este caso, el problema también puede aprovecharse sin credenciales válidas mediante solicitudes HTTP manipuladas. Fortinet indica que las instalaciones locales afectadas deben actualizar, como mínimo, a FortiSandbox 5.0.2 o 4.4.9, mientras que en las variantes cloud y PaaS la recomendación pasa por migrar a una versión ya corregida.

La severidad no sorprende. Tanto FortiAuthenticator como FortiSandbox ocupan posiciones sensibles dentro de muchas arquitecturas empresariales: el primero en la capa de identidad y control de acceso, el segundo en tareas de análisis y contención de ficheros sospechosos. Cuando una vulnerabilidad de este tipo afecta a piezas tan centrales, el problema deja de ser solo técnico y pasa a ser operativo. No hace falta explotación masiva confirmada para que el parcheo suba al primer nivel de prioridad.

De hecho, el contexto tampoco invita a relajarse. BleepingComputer recuerda que los fallos en productos de Fortinet han sido aprovechados en otras ocasiones por actores ligados al ransomware y al espionaje, y que este fabricante acumula un historial reciente de vulnerabilidades críticas que han acabado entrando en circuitos de explotación reales. En esta ocasión, la firma no ha marcado estos dos fallos como explotados activamente, pero esa ausencia de evidencia pública no equivale a riesgo bajo cuando hablamos de dispositivos y plataformas que suelen estar muy expuestos.

Para los administradores, la recomendación práctica es clara. Conviene revisar de inmediato las versiones desplegadas, confirmar si existe exposición externa de estas consolas o servicios y adelantar la actualización allí donde sea posible. Si el parcheo no puede aplicarse en el corto plazo, tiene sentido reforzar controles perimetrales, restringir el acceso administrativo a segmentos de confianza y revisar la telemetría disponible para detectar peticiones anómalas contra las interfaces afectadas.

Los dos avisos publicados por Fortinet no describen un incidente abierto, pero sí un riesgo serio y muy utilizable si los sistemas siguen sin actualizar. En productos que gestionan autenticación y análisis de amenazas, una vulnerabilidad crítica sin autenticar merece muy poco margen. La mejor respuesta, en este caso, sigue siendo la de siempre: comprobar versiones, parchear cuanto antes y no dar por hecho que la falta de explotación pública ofrece tiempo de sobra.

Más información

• BleepingComputer – Fortinet warns of critical RCE flaws in FortiSandbox and FortiAuthenticator – https://www.bleepingcomputer.com/news/security/fortinet-warns-of-critical-rce-flaws-in-fortisandbox-and-fortiauthenticator/
• FortiGuard Labs – Improper access control on API endpoints – https://fortiguard.fortinet.com/psirt/FG-IR-26-128
• FortiGuard Labs – Incorrect global authorization – https://fortiguard.fortinet.com/psirt/FG-IR-26-136

La entrada Fortinet corrige dos fallos críticos que permiten ejecución remota de código se publicó primero en Una Al Día.

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.