Entre los incidentes más destacados se encuentra la investigación de Binance sobre transacciones no autorizadas que podrían ascender a miles de millones de dólares, presuntamente originadas por el compromiso del equipo de un ingeniero de DevOps. Por otro lado, la comunidad de desarrollo web se ha visto forzada a una carrera urgente de actualizaciones debido a fallos críticos de seguridad en PHP (el denominado "PHP2Shell", con un nivel de gravedad de 9.2) y en Node.js, los cuales permitían la ejecución remota de código en servidores vulnerables. Asimismo, una versión comprometida de la biblioteca de IA LiteLLM en PyPI encendió el pánico al incluir un programa de robo de credenciales, demostrando una vez más los peligros de los ataques a la cadena de suministro de software.

Otros casos notables incluyeron filtraciones de datos e incidentes de seguridad en plataformas como Polymarket y Coinbase (a través de un proveedor externo), así como la exposición de millones de registros de personal en el Pentágono (mediante una vulnerabilidad de transferencia de archivos) y de la población en Dinamarca. Esta oleada de incidentes pone de relieve que el robo de credenciales, el compromiso de secretos en entornos de desarrollo y la falta de control sobre los canales de distribución de software de confianza siguen siendo los eslabones más débiles y peligrosos de la infraestructura digital actual.

La implementación comenzará el 16 de noviembre de 2026 con la publicación de páginas web para los servidores y resúmenes de discusión. El despliegue de los mensajes individuales se realizará de manera progresiva a partir de mediados de diciembre, otorgando un margen de tiempo para que usuarios y administradores ajusten sus preferencias de privacidad.

¿Qué contenido se mostrará en los resultados de búsqueda?

Esta medida afectará exclusivamente a los servidores descubribles (Discoverable Servers), aquellos de acceso público que no requieren invitación. Para calificar, los servidores deben contar con al menos 1,000 miembros, tener una antigüedad mínima de ocho semanas y cumplir con las normas de actividad y seguridad. Actualmente, más de 63,000 comunidades cumplen con estas condiciones.

• Sistemas excluidos: Los mensajes directos, chats grupales y servidores privados no serán indexados en ningún caso.
• Mensajes antiguos protegidos: Solo las publicaciones realizadas a partir del lanzamiento podrán aparecer en la web; el historial previo no se hará público.
• Anonimización inicial: El contenido se mostrará inicialmente como texto plano, omitiendo los avatares y los nombres de usuario de los autores.
• Aviso visual: Los canales habilitados mostrarán un icono y una advertencia antes de que los usuarios envíen sus comentarios.

Cómo desactivar la publicación de mensajes

Los usuarios que prefieran que sus textos no se indexen pueden desactivar la opción desde la aplicación de escritorio o el navegador:

1. Ir a Ajustes de usuario > Datos y privacidad.
2. Desactivar la opción «Mostrar el contenido de mis mensajes de canales descubribles en páginas web».

Este ajuste se aplica a nivel de cuenta para todos los servidores. En la Unión Europea, Reino Unido, Canadá, Brasil, Australia y Corea del Sur viene desactivado por defecto, mientras que en otras regiones está activo inicialmente. Las cuentas de menores de edad tienen la función deshabilitada sin posibilidad de activarla.

Es relevante considerar que desactivar la opción solo protege las publicaciones futuras; los mensajes compartidos mientras la función estuvo activa seguirán estando visibles a menos que el usuario los elimine manualmente de la plataforma.

Gestión para administradores y precauciones

Los moderadores pueden gestionar la presencia de su comunidad desde Ajustes del servidor > Presencia web, permitiendo excluir canales específicos o desactivar la función por completo. Si una comunidad no desea mantener una página pública, tiene la opción de salir del programa de descubrimiento y permanecer como servidor comunitario.

Dado que los mensajes pueden incluir información sensible dentro del propio texto redactado, los equipos de seguridad recomiendan revisar los canales públicos antes de que se habilite la indexación. Asimismo, se recuerda a los usuarios verificar siempre los enlaces de los servidores encontrados a través de buscadores para evitar comunidades fraudulentas o intentos de manipulación.

Diversos informes públicos vinculan las próximas correcciones con los identificadores 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟏𝟎𝟗𝟔𝟏𝟖 𝐲 𝐂𝐕𝐄-𝟐𝟎𝟐𝟔-𝟏𝟎𝟗𝟔𝟏𝟗. La firma de seguridad watchTowr describe estas fallas como vulnerabilidades de ejecución remota de código, las cuales podrían permitir a los atacantes ejecutar su propio código en los servidores afectados. No obstante, el aviso previo de PHP no menciona los identificadores CVE ni explica el funcionamiento de dichas vulnerabilidades. Según los informes, estas fallas podrían afectar a las versiones de PHP desde la 5 en adelante.

PHP publicará un parche de emergencia

En el momento de la publicación de la actualización, watchTowr no tenía constancia de que la vulnerabilidad estuviera siendo explotada en entornos reales. La advertencia de PHP sobre un posible lanzamiento anticipado es una medida de precaución, no una confirmación de que se hayan producido ataques. Las afirmaciones sobre demostraciones filtradas o código de explotación no deben considerarse pruebas de ataques contra objetivos reales.

Incidentes anteriores demuestran por qué los administradores deben prepararse con rapidez. Cybersecurity News documentó la explotación activa de CVE-2024-4577, otra vulnerabilidad de PHP, con intentos de ataque detectados apenas 24 horas después de su divulgación. Estos antecedentes subrayan la necesidad de planificar la aplicación de parches con urgencia, aunque no implican que estas nuevas vulnerabilidades estén siendo explotadas actualmente.

Anteriormente, en 2026, también se informó sobre vulnerabilidades en la extensión SOAP de PHP; no obstante, aquellos problemas afectaban a componentes distintos y requerían soluciones diferentes. Los administradores no deben asumir que la instalación de parches para fallos anteriores de PHP resolverá las dos vulnerabilidades que abordará esta próxima actualización.

CERT-EU recomienda identificar las aplicaciones PHP existentes y prepararse para aplicar parches en los sistemas afectados tan pronto como estén disponibles las versiones corregidas. En los casos en que no sea posible aplicar el parche de inmediato, las organizaciones deberían considerar aislar de las redes públicas aquellas aplicaciones expuestas a Internet hasta que se pueda implementar la corrección. Cualquier decisión de aislamiento debe tener en cuenta la disponibilidad del servicio y las necesidades operativas del negocio.

Los equipos deben aprovechar este periodo de preparación para determinar quién gestiona cada instalación de PHP y cómo llegarán las actualizaciones a los sistemas en producción. Una vez disponible la actualización, los administradores deben consultar la lista oficial de versiones afectadas, aplicar las correcciones pertinentes con prontitud y verificar la versión de PHP que se está ejecutando. Hasta entonces, ningún entorno debe considerarse seguro simplemente porque su configuración difiera de la descrita en informaciones que circulan por Internet.

Las conexiones fallidas pueden devolver el error 0xC000000D y mostrar el mensaje: “El token que se pasó a la función no es válido” (“The token that was passed to the function is invalid”). Microsoft registró el problema el 13 de octubre y actualizó su estado a “Mitigado” esa misma mañana. Se encuentra disponible una solución temporal, aunque la compañía aún está desarrollando una corrección permanente.

Sistemas Windows 11 afectados

Microsoft enumera como afectadas las versiones de Windows 11 24H2, 25H2, 26H1 y 26H2. Windows Server no se ve afectado por este problema específico. El fallo ocurre cuando la protección de Administrador está habilitada en el host remoto, independientemente de cómo hayan activado la función los administradores.

Esto convierte a la configuración de seguridad del host en un factor clave a la hora de resolver problemas. Los equipos de soporte que investiguen fallos coincidentes deben verificar las actualizaciones de Windows instaladas, confirmar el error reportado y comprobar si la protección de Administrador está activa antes de realizar cambios en las directivas. Estas comprobaciones ayudan a identificar los equipos que coinciden con la descripción del problema de Microsoft.

La protección de Administrador limita la forma en que Windows concede permisos del sistema con elevados privilegios. Esta característica crea un token de administrador separado y temporal una vez que el usuario aprueba una tarea administrativa. Windows elimina ese token al finalizar el proceso, lo que ayuda a evitar que el malware obtenga derechos de administrador en segundo plano.

Las organizaciones que utilicen las líneas base de seguridad (security baselines) de Microsoft para Windows deben revisar sus configuraciones minuciosamente. Las líneas base para las versiones 24H2, 25H2 y 26H2 de Windows 11 habilitan la protección de Administrador a menos que la organización haya modificado dicha directiva. La línea base de seguridad actualizada de Microsoft para 26H2 también recomienda probar la configuración según las necesidades del negocio.

Solución temporal recomendada

Microsoft aconseja a los administradores de TI desactivar temporalmente la protección de Administrador en los hosts de Escritorio Remoto afectados a través de sus herramientas de gestión habituales. La solución temporal requiere reajustar la directiva “Control de cuentas de usuario: Modo de aprobación de administrador para la cuenta Administrador integrada” (User Account Control Type Of Admin Approval Mode) mediante Microsoft Intune o Directivas de Grupo (GPO).

Debido a que esto elimina una salvaguarda de seguridad adicional, las organizaciones deben limitar este cambio únicamente a los dispositivos afectados y registrar la excepción para una revisión posterior.

Microsoft aclara que las correcciones anteriores no solucionan este incidente. El aviso actual de estado de la versión indica que una futura actualización de Windows proporcionará la resolución definitiva, con más detalles por venir.

El componente afectado, vhost, optimiza el rendimiento del tráfico de red y de entrada/salida en entornos virtualizados mediante el uso de colas compartidas (virtqueues) entre el invitado y el host. La falla radica en la gestión de memoria interna, concretamente en cómo se almacenan en caché las traducciones de la IOTLB empleadas para ubicar estas colas.

Al reconfigurar un anillo virtual, la dirección o dimensión del dispositivo se modifica dentro del sistema, pero el kernel omite purgar las entradas en caché asociadas a las zonas de descriptores y áreas de intercambio de datos.

Debido a esta falta de invalidez en la memoria caché, una consulta posterior utiliza punteros obsoletos para traducir las nuevas direcciones de memoria, saltándose los controles de validación. Como resultado, las funciones de copia del kernel operan sobre direcciones no válidas.

De acuerdo con análisis divulgados en la lista de correo Seclists, este comportamiento deriva de la combinación de dos modificaciones previas en el código base del kernel: la incorporación de la caché de metadatos y el aplazamiento en la comprobación de direcciones de E/S procedentes de la máquina virtual.

Para la escalada de privilegios local, un atacante necesita primero permiso para abrir un dispositivo vhost, como /dev/vhost-net o /dev/vhost-vsock. La prueba de concepto (PoC) prepara la caché, modifica una dirección de anillo (ring address) sin borrar la entrada almacenada en caché y, a continuación, activa la cola. Los investigadores afirman que esto permite leer y escribir en la memoria del kernel.

La cadena de explotación demostrada utiliza una lectura de memoria del kernel para determinar el desplazamiento de aleatorización de direcciones y, posteriormente, escribe en el parámetro modprobe_path del kernel. Al activar una solicitud de módulo del kernel, es posible ejecutar un programa auxiliar controlado por el atacante con privilegios de root.

Los investigadores informan haber reproducido esta cadena en Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0 y Oracle Linux 10.2. Los permisos de los dispositivos variaban: el sistema Ubuntu probado limitaba el acceso al grupo kvm, mientras que los otros sistemas de prueba mencionados exponían el dispositivo a usuarios comunes.

Esta diferencia convierte a los permisos del dispositivo en un factor importante para evaluar la exposición, pero no sustituye la aplicación de parches. La pertenencia al grupo kvm o a cualquier otro grupo con acceso a dispositivos vhost debe considerarse un privilegio elevado mientras el sistema permanezca sin actualizar.

La segunda vía de ataque comienza dentro de una máquina virtual. Requiere un dispositivo vhost que utilice una IOMMU virtual, iommu_platform y la funcionalidad de reinicio de cola de virtio VIRTIO_F_RING_RESET. Un sistema invitado puede reiniciar y reactivar una cola, lo que provoca que el host reconfigure su anillo mientras los metadatos obsoletos permanecen en la caché.

Cuando el sistema invitado activa la cola, la asignación obsoleta puede provocar una escritura en el anillo de usados ​​(used-ring) que sobrepase la memoria del invitado y afecte al heap del proceso QEMU. Los investigadores señalan que esta corrupción puede provocar el bloqueo de QEMU o alterar su flujo de control. Se trata de un riesgo de escape de máquina virtual (VM) que depende de la configuración; no implica que todas las máquinas virtuales sean vulnerables a este tipo de escape.

La corrección aplicada en la rama principal (upstream) borra la caché de metadatos del vring cuando se modifica la dirección o el tamaño del anillo, garantizando así que la nueva configuración supere la validación IOTLB.

Las primeras versiones estables corregidas en la rama principal para las series afectadas son: 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 y 7.2. Los administradores deben instalar un kernel corregido o un backport del proveedor y reiniciar el sistema utilizando dicha versión.

Hasta entonces, se recomienda restringir el acceso a todos los nodos de dispositivo vhost, incluidos /dev/vhost-net, /dev/vhost-vsock, /dev/vhost-scsi y /dev/vhost-vdpa-*. No se deben asignar estos dispositivos a contenedores que no sean de confianza.

En el caso de hosts de virtualización sin el parche aplicado, evite exponer dispositivos vhost configurados con iommu_platform (detrás de una IOMMU virtual) a sistemas invitados no confiables. Los cambios en los permisos no revocan los descriptores de archivo que ya están abiertos ni solucionan la ruta de ejecución iniciada por el sistema invitado.

Impacto y alcance de la vulnerabilidad***

• Alcance comprobado: Los ataques buscan causar una denegación de servicio (DoS). Si la explotación ocurre de forma continua, puede bloquear por completo el acceso a las plataformas y aplicaciones alojadas.

• Seguridad de la información: Citrix confirmó que no se ha registrado robo de información ni alteración en la integridad de los datos; el daño se limita a la interrupción del servicio.

• Sistemas comprometidos: Afecta a despliegues gestionados por el cliente (incluyendo entornos híbridos de Secure Private Access). Los servicios en la nube administrados directamente por Citrix (Citrix Cloud y Adaptive Authentication) son actualizados de forma automática por Cloud Software Group.

Diagnóstico para equipos de seguridad

Para determinar si una máquina está expuesta, los administradores deben revisar la configuración del sistema en busca de las siguientes directivas:

• add authentication samlAction (Proveedor de servicios SAML)

• add authentication samlIdPProfile (Proveedor de identidad SAML)

Nota: La presencia de estas líneas confirma que el dispositivo cumple la condición de vulnerabilidad si ejecuta una versión desactualizada, pero no implica necesariamente que el equipo haya sido vulnerado.

Recomendaciones clave

1. No confiar en parches recientes: Haber actualizado los equipos con boletines de seguridad anteriores no protege contra este fallo específico. Es obligatorio instalar de nuevo si se está en las versiones afectadas.

2. Aplicar actualizaciones inmediatamente: Aunque Citrix está desplegando listas de bloqueo de IP globales (Global Deny Lists) para mitigar conexiones sospechosas, la única solución definitiva es la instalación del parche.

3. Auditoría rápida: Validar la versión del firmware y la configuración SAML de cada nodo para priorizar el despliegue del firmware corregido.

Identificada como CVE-2026-84782, la vulnerabilidad se origina en una lectura fuera de límites dentro de la lógica de retransmisión de la negociación DTLS y también puede provocar el bloqueo del proceso afectado, generando una condición de denegación de servicio.

El proyecto OpenSSL dio a conocer el problema el 29 de septiembre de 2026, junto con las versiones de seguridad OpenSSL 4.0.3, 3.6.5, 3.5.9 y 3.4.8. OpenSSL describió estas versiones como parches de seguridad e indicó que la vulnerabilidad más grave corregida en cada una de ellas está clasificada como de nivel alto.

DTLS proporciona seguridad al estilo TLS sobre transportes de datagramas no fiables, en los que los paquetes pueden sufrir retrasos, alteraciones en el orden o pérdidas. En consecuencia, su capa de negociación (handshake) tiene la capacidad de fragmentar mensajes extensos y retransmitir datos enviados previamente cuando expira un temporizador.

La vulnerabilidad CVE-2026-84782 se produce cuando OpenSSL interrumpe una operación de escritura de un mensaje de negociación porque el transporte no puede aceptar más datos, devolviendo el estado WANT_WRITE.

Mientras dicha escritura permanece suspendida, un temporizador de retransmisión puede solicitar el reenvío de un mensaje de negociación anterior. Las versiones vulnerables de OpenSSL reutilizaban el búfer interno y el seguimiento de posición asociados a la escritura interrumpida, pero no restablecían el desplazamiento de lectura (read offset) al inicio del mensaje en cola.

Por consiguiente, la retransmisión podía iniciarse en una posición desactualizada, incluir bytes residuales de un mensaje distinto y de mayor tamaño, y continuar la lectura más allá de los límites del búfer asignado.

Este comportamiento puede provocar que se envíen contenidos adyacentes de la memoria dinámica (heap) al interlocutor conectado como datos de negociación en texto plano. Los bytes expuestos dependen del contenido de la memoria del proceso en las zonas próximas, por lo que el aviso de seguridad no especifica un conjunto fijo de secretos que se filtren invariablemente.

Si el fallo de acceso fuera de límites afecta a una región de memoria no asignada, el proceso podría terminar abruptamente, permitiendo que una parte remota provoque una denegación de servicio. OpenSSL clasifica esta vulnerabilidad como CWE-125 (lectura fuera de límites).

El error genera un segundo problema de gestión de estado. Incluso cuando la retransmisión comienza en el desplazamiento (offset) correcto, completarla mientras otra operación de escritura del protocolo de enlace (handshake) está en pausa sobrescribe datos de control compartidos necesarios para reanudar la operación original. Una llamada posterior a SSL_read(), SSL_write(), SSL_accept() o SSL_connect() puede encontrarse entonces con un estado inconsistente respecto al mensaje suspendido; OpenSSL indica que esto provoca una interrupción (abort) en las compilaciones de depuración.

OpenSSL corrigió la vulnerabilidad restableciendo la posición de lectura de la retransmisión antes de reenviar un mensaje. El código también omite la retransmisión mientras la escritura del protocolo de enlace permanece suspendida, posponiendo la tarea hasta que una llamada posterior la reanude. La lógica afectada se encuentra fuera de los límites del módulo FIPS de OpenSSL, por lo que el proyecto afirma que los módulos FIPS no se ven afectados.

Todas las ramas son vulnerables: OpenSSL 4.0 (versiones anteriores a la 4.0.3), 3.6 (anteriores a la 3.6.5), 3.5 (anteriores a la 3.5.9), 3.4 (anteriores a la 3.4.8), 3.0 (anteriores a la 3.0.23), 1.1.1 (anteriores a la 1.1.1zj) y 1.0.2 (anteriores a la 1.0.2zs). Las correcciones para las tres ramas más antiguas están reservadas a clientes con soporte premium.

Los administradores deben inventariar los dispositivos, sistemas embebidos, productos VPN y aplicaciones que utilicen OpenSSL DTLS, y posteriormente realizar la actualización a través de su sistema operativo o del proveedor del producto.

La actualización a las versiones 4.0.3, 3.6.5, 3.5.9 o 3.4.8 soluciona el problema en las ramas con mantenimiento activo, mientras que los clientes con soporte deben obtener las versiones 3.0.23, 1.1.1zj o 1.0.2zs. Dado que las aplicaciones pueden incluir OpenSSL internamente en lugar de utilizar la biblioteca del sistema, consultar únicamente el gestor de paquetes del host podría dejar pasar por alto copias expuestas. Laurent Gaffie, de Secorizon, notificó la vulnerabilidad CVE-2026-84782 el 17 de agosto de 2026, y Ryan Hooper desarrolló la corrección tras recibir el informe en agosto.

OpenSSL 4.0.3 también soluciona otras 13 vulnerabilidades que afectan al procesamiento de X.509, QUIC, CMP, DTLS, SM2 y a las operaciones de curvas elípticas, lo que refuerza la necesidad de considerar esta versión como una actualización de seguridad y no simplemente como un parche para un único error.

La filtración incluyó números de Seguro Social y detalles de los puestos que desempeñaba personal militar y civil. El impacto va más allá de un posible robo de identidad tradicional: vincular nombres completos con roles específicos en el área de defensa permite trazar perfiles detallados e iniciar tácticas de abordaje dirigidas si la información cae en manos de actores hostiles.

De acuerdo con ABC News, una fuente del Departamento de Defensa confirmó que el incidente afectó a 2.76 millones de personas con vida y a cerca de 294,000 fallecidos, dando un gran total de 3.054 millones de individuos.

Las autoridades indicaron que el acceso no autorizado ocurrió entre octubre de 2025 y julio de 2026, momento en que se detectó y corrigió el fallo. Aunque señalaron que hasta el momento no hay pruebas de que los datos robados hayan sido usados con fines maliciosos —lo cual da cierto alivio sobre los hallazgos iniciales—, esto no descarta repercusiones a largo plazo.

Una falla en el sistema de archivos compartidos dejó registros sin cifrar

Military Times reportó el caso por primera vez el 24 de septiembre tras revisar una carta de notificación enviada a una persona afectada el 18 de septiembre. Dicho documento detallaba que el DMDC detectó el 16 de julio una vulnerabilidad en una plataforma para compartir archivos.

Según esta versión, usuarios sin autorización accedieron a archivos que contenían datos de identificación personal sin cifrado. Al destinatario se le expuso su número de Seguro Social junto con al menos un dato de identificación adicional, los cuales podían incluir nombre, fecha de nacimiento, datos de contacto, sexo, raza o información del puesto militar (como la especialidad ocupacional).

Cabe destacar la precisión del comunicado: esto no significa que a todos los afectados se les haya filtrado la totalidad de las categorías mencionadas.

La notificación aclara que el sistema se actualizó para corregir la falla y volvió a operar con normalidad. Sin embargo, los informes públicos no revelaron la marca del software afectado, la clave de la vulnerabilidad ni la técnica exacta usada para ingresar.

El inventario general del DMDC supera los 60 millones de registros. Esa cifra refleja la base de datos global del organismo y no debe interpretarse como la cantidad de víctimas de este incidente.

La relevancia y el peligro de los datos ocupacionales militares

CNN revisó de forma independiente la carta de notificación y confirmó las mismas cifras de afectados reportadas por ABC.

El medio hizo énfasis en la filtración de las especialidades militares. Al cruzar esta información con otros identificadores y registros públicos o privados, un adversario podría mapear qué personas cumplen funciones clave dentro de las Fuerzas Armadas.

Justin Sherman, director ejecutivo de Global Cyber Strategies, comentó a CNN que la información obtenida del DMDC se puede combinar con bases de datos comerciales para estructurar perfiles minuciosos del personal de defensa, abarcando su situación financiera, redes de contactos y actividad en línea. Sherman advirtió que entre los riesgos principales se encuentran ataques de phishing dirigidos y acercamientos por parte de inteligencia extranjera.

Estas apreciaciones corresponden a análisis de riesgo y no a una confirmación de que un gobierno extranjero ya posea los datos. De hecho, los reportes no aclaran quién estuvo detrás de la intrusión.

La diferencia operativa es sustancial: mientras que la respuesta ante un robo de identidad común busca frenar fraudes financieros y restituir créditos, la respuesta desde el plano de la contrainteligencia debe evaluar si los datos filtrados hacen que una persona sea más fácil de rastrear, presionar, engañar o reclutar.

Informes previos ya advertían sobre los perfiles digitales del personal militar

Las consecuencias de consolidar información dispersa quedaron documentadas en un informe de la Oficina de Rendición de Cuentas del Gobierno (GAO) sobre información de defensa disponible al público, presentado en octubre de 2025 y publicado al mes siguiente.

La GAO explicó cómo los datos generados por dispositivos móviles, plataformas digitales y comunicaciones de defensa se pueden ensamblar en perfiles digitales que ponen en riesgo a las tropas, a sus familias y a la seguridad de las operaciones.

La investigación reveló que los materiales de capacitación en 9 de las 10 dependencias examinadas no cubrían de manera integral el manejo de la información pública sensible en todos sus módulos de seguridad. Asimismo, 8 de las 10 dependencias no realizaban evaluaciones de amenaza que abarcasen todos los ámbitos requeridos, centrándose casi de forma exclusiva en la seguridad operacional.

Frente a esto, la GAO emitió 12 recomendaciones sobre políticas, coordinación, entrenamiento y análisis de riesgo. El Departamento de Defensa aceptó 11 de ellas y coincidió parcialmente con una.

Aunque las conclusiones de la GAO no investigaron este incidente específico del DMDC ni determinaron su causa, sirven para comprender por qué la pérdida de información militar requiere un enfoque distinto al de un simple fraude bancario: el valor táctico de un dato se multiplica cuando se conecta con otros registros.

Investigadores demostraron lo económico que es comprar datos militares

Un estudio realizado por la Universidad de Duke en 2023 demostró que información altamente sensible de personal militar ya se comercializaba libremente a través de data brokers (intermediarios de datos).

Los investigadores analizaron cientos de plataformas de venta de datos y se hicieron pasar por compradores usando dominios web de EE. UU. y de la región de Asia (.asia). Lograron adquirir registros individuales identificables de personal militar por montos desde tan solo 12 centavos de dólar por expediente.

La información disponible incluía detalles confidenciales sobre salud, finanzas y afiliación religiosa. El equipo detectó controles sumamente laxos para verificar la identidad de los compradores, incluso en transacciones realizadas con clientes ubicados fuera de Estados Unidos. Aunque no compraron datos de geolocalización, confirmaron que también estaban a la venta.

El informe alertaba que esta información facilitaba la creación de perfiles, intentos de extorsión y campañas de desinformación dirigidas contra militares, veteranos y sus familias. Estos hallazgos son anteriores al incidente del DMDC y no prueban que los datos filtrados del Pentágono se hayan puesto a la venta; sin embargo, demuestran que un atacante no necesita vulnerar un servidor gubernamental completo para armar un perfil detallado de una persona, pues puede comprar gran parte de la información en el mercado comercial.

Las amenazas mediante datos de ubicación ya afectan operaciones reales

Documentación parlamentaria más reciente demuestra que la preocupación por el mercado de datos comerciales dejó de ser un ejercicio académico para convertirse en un problema real de defensa.

Una carta enviada el 28 de mayo de 2026 por el Congreso al director de informática del Pentágono incluyó respuestas del Mando Central de EE. UU. (CENTCOM), en las que se reconocían múltiples alertas sobre el uso de datos de geolocalización comercial por parte de adversarios para rastrear y vigilar al personal estadounidense desplegado en el terreno.

CENTCOM señaló que su unidad de fusión de amenazas monitoreó y distribuyó esos informes para alertar a los equipos de protección de la fuerza. Además, se aplicaron restricciones de geolocalización y se emitieron guías para revisar la privacidad en los dispositivos móviles y reducir lo que se comparte en redes públicas.

Si bien el documento aborda el rastreo comercial y no la brecha del DMDC (sin sugerir que los archivos filtrados contengan historiales de GPS), sienta un precedente operativo: cualquier información personal de un militar representa un riesgo de seguridad. El peligro radica en que un expediente que confirme el rol o puesto de alguien hace que otras bases de datos comerciales sean mucho más útiles para un enemigo.

Reguladores imponen sanciones al mercado de datos sensibles

Por su parte, la Comisión Federal de Comercio (FTC) ha comenzado a sancionar la venta no regulada de datos de ubicación geográfica sensible.

En una medida tomada en diciembre de 2024 contra la empresa Mobilewalla, la FTC sostuvo que la compañía recopilaba y comercializaba ubicaciones precisas sin verificar adecuadamente el consentimiento de los usuarios.

El acuerdo propuesto fijó restricciones estrictas sobre el manejo de datos asociados a bases militares, centros médicos, recintos religiosos y otras áreas delicadas. El organismo regulador enfatizó que almacenar y vender esa información exponía a las personas a riesgos físicos y otros peligros graves.

Aunque esta acción legal aborda una vía de filtración totalmente distinta y no vincula a Mobilewalla con el caso del Pentágono, al analizarse junto con la investigación de Duke y los informes del Congreso, explica por qué un ciberataque gubernamental no se puede evaluar de forma aislada: lo determinante es qué se puede deducir al cruzar esos datos con los que ya circulan en el mercado.

La GAO detecta vacíos en la planificación tecnológica de la Defensa

La divulgación del ciberataque coincidió con otro informe de la GAO publicado el 28 de septiembre de 2026, el cual examinó 18 programas clave de tecnología e informática del sector defensa.

El organismo reveló que 6 de esos programas no tenían un plan para adoptar la arquitectura de "confianza cero" (zero trust) antes de la fecha límite fijada para 2027, mientras que 3 ni siquiera contaban con una estrategia de ciberseguridad aprobada.

Asimismo, el personal de 7 programas manifestó no haber recibido —o desconocer— capacitación para identificar o reportar alteraciones y fraudes en los sistemas informáticos. Solo 10 de los 18 programas reportaron haber realizado evaluaciones formales sobre riesgos de fraude.

Los programas auditados representan un gasto presupuestado de aproximadamente 10,300 millones de dólares entre los años fiscales 2024 y 2026.

Estos hallazgos ilustran las dificultades estructurales que enfrenta el Departamento de Defensa para gestionar su infraestructura tecnológica. No prueban que las fallas del DMDC hayan sido causadas por estas deficiencias específicas, pero sí dejan clara la brecha que existe entre fijar un objetivo de seguridad en el papel y ejecutarlo de manera efectiva en cada sistema.

Proteger la información requiere entender el contexto

Las pautas del Instituto Nacional de Estándares y Tecnología (NIST) para la protección de datos personales destacan que las medidas de seguridad deben ajustarse al contexto en que se almacena la información y al impacto que tendría su divulgación.

Este principio es vital al tratar con expedientes militares. Un cargo de trabajo puede ser de dominio público en un entorno civil, pero relacionar a una persona específica con una unidad o función militar reservada conlleva riesgos considerablemente mayores.

Por ende, el punto crítico no es solo si un dato es habitualmente privado o no, sino qué revela sobre el individuo, qué otros registros permite conectar y qué clase de daño podría desencadenar.

Frente al incidente del DMDC, esto obliga a clasificar a los grupos afectados y el tipo de datos expuestos para medir el riesgo real. Ofrecer servicios estándar de monitoreo de crédito ayuda con el riesgo financiero, pero determinado personal podría requerir asesoría de seguridad reforzada según los datos que se hayan filtrado. La información pública disponible no aclara si las autoridades ya completaron estas evaluaciones personalizadas.

El modelo de "Confianza Cero" debe incluir los servicios de soporte

Las directrices del NIST sobre el modelo de "confianza cero" (Zero Trust Architecture) plantean que la protección debe centrarse directamente en los usuarios, los dispositivos y los recursos individuales. Estar dentro de la red interna o pertenecer a la organización ya no basta para asumir que un acceso es seguro.

En la gestión de datos de personal, esto implica que las autorizaciones deben ser específicas para la información que se solicita, abarcando también los servicios y plataformas secundarias donde se alojan archivos o extractos.

Una base de datos centralizada y un archivo compartido que contiene un extracto de esa misma base presentan riesgos de confidencialidad equivalentes. Proteger el servidor principal no garantiza que las copias o extractos generados posteriormente cuenten con el mismo nivel de resguardo.

Esta es una lección general sobre la vulnerabilidad reportada en el sistema de archivos compartidos, más allá de cuál haya sido la causa técnica puntual (la cual aún se desconoce, ya que no se ha precisado si el fallo se debió a problemas de autenticación, exceso de permisos u otra brecha). Esa falta de detalles hace necesario un informe técnico exhaustivo para que otras instituciones evalúen si están expuestas a un problema similar.

Filtraciones históricas recuerdan la magnitud del riesgo

El caso del DMDC evoca la gravedad de las filtraciones ocurridas en 2015 en la Oficina de Administración de Personal (OPM), aunque no existe una relación directa entre ambos episodios.

Un informe oficial del Pentágono sobre la investigación de la OPM detalló el robo de expedientes de antecedentes que afectó a 21.5 millones de personas, incluyendo solicitantes de empleo, cónyuges y cohabitantes.

Entre la información sustraída figuraban historiales laborales y de residencia, contactos personales y otros datos sensibles de verificación. De forma paralela, una intrusión vinculada expuso datos de personal de 4.2 millones de individuos. Al existir una superposición de personas entre ambos grupos, las cifras no deben sumarse como totales independientes.

Esta comparación histórica evidencia el valor estratégico que tienen los registros administrativos para las operaciones de inteligencia enemiga. No implica que los archivos del DMDC contuvieran la misma profundidad de datos ni que los atacantes sean los mismos.

A la par de esto, Reuters informó el 23 de septiembre sobre otro incidente donde el grupo ShinyHunters habría robado datos que incluían asignaciones laborales sensibles del FBI. Aunque Reuters verificó parte del contenido, no pudo autenticar la totalidad de la base. Eric O’Neill, exoperativo de contrainteligencia del FBI, advirtió sobre el alto valor defensivo que esos datos representan para un servicio de inteligencia extranjero. No se ha establecido ningún vínculo entre este hecho y la filtración del Pentágono.

El monitoreo crediticio solo resuelve una parte del problema

Military Times confirmó que la notificación emitida por el DMDC ofrece a las víctimas un año de monitoreo crediticio y servicios de restauración de identidad mediante la empresa IDX.

Por su parte, la FTC sugiere herramientas de protección complementarias:

• Congelamiento de crédito: Bloquea el acceso al historial crediticio para evitar la apertura de cuentas fraudulentas. Es un trámite gratuito que debe gestionarse por separado ante Equifax, Experian y TransUnion.

• Alerta de fraude: Exige que las entidades financieras verifiquen la identidad del solicitante antes de otorgar un crédito. La alerta inicial dura un año y basta con solicitarla en una sola central de riesgo, la cual está obligada a notificar a las otras dos.

• Alertas para personal en servicio activo: Mecanismos específicos y monitoreo electrónico gratuito para miembros elegibles de las Fuerzas Armadas.

Estas soluciones mitigan el daño económico, pero no eliminan los datos en poder de los atacantes ni evitan que la información laboral sea usada para perfilamiento de inteligencia. Por ello, la respuesta gubernamental debe juzgarse en función de la naturaleza de los datos filtrados y no solo por la entrega de una suscripción a un servicio de monitoreo.

Alerta ante posibles intentos de suplantación de identidad (phishing)

Un riesgo colateral derivado de estas filtraciones es la llegada de mensajes falsos que simulen ser avisos oficiales relacionados con el incidente. Se trata de una medida preventiva y no de una alerta por una campaña activa detectada.

Las recomendaciones del NIST contra el phishing aconsejan validar cualquier comunicación inesperada utilizando números de teléfono o portales web oficiales verificados por cuenta propia, sin confiar en los enlaces o datos proporcionados en el mensaje recibido.

El organismo alerta sobre mensajes con tono de urgencia que solicitan abrir archivos adjuntos, hacer clic en enlaces, ingresar a cuentas o revelar datos personales. Asimismo, recuerda que la suplantación puede ocurrir por correo electrónico, llamadas telefónicas, mensajes de texto o redes sociales.

Para el personal afectado, el hecho de que un interlocutor conozca su nombre correcto o su unidad militar no garantiza que la comunicación sea legítima. Cualquier instrucción para inscribirse en servicios de protección debe validarse por canales oficiales e independientes, y todo acercamiento sospechoso relacionado con el trabajo debe reportarse siguiendo los protocolos de seguridad de la institución.

Preguntas clave sobre el acceso a los datos y el impacto a largo plazo

Una rendición de cuentas transparente requerirá aclarar qué falló en los controles de acceso, cómo se detectó la brecha y de qué manera se determinó la cifra exacta de personas afectadas.

Aunque la ventana de acceso no autorizado abarcó casi nueve meses, esto no significa que haya habido actividad maliciosa ininterrumpida durante todo ese tiempo. De igual forma, la falta de evidencias sobre el uso indebido de los datos no garantiza que la información no haya sido copiada, compartida o explotada por medios fuera del alcance de los investigadores.

Tampoco se ha explicado públicamente la razón de la demora entre la detección de la vulnerabilidad en julio y el envío de las notificaciones en septiembre.

Las guías de respuesta ante incidentes del NIST (actualizadas en abril de 2025) conciben la gestión de crisis como un proceso continuo de gestión de riesgos que abarca la preparación, detección, respuesta y recuperación.

En este caso, la distinción es clara: reparar la vulnerabilidad cierra la puerta de entrada, pero medir el impacto real exige comprender el alcance exacto de la información filtrada y el perfil de las personas afectadas. La efectividad real de la respuesta dependerá de la claridad con que se respondan estas interrogantes y de si las medidas de protección implementadas están a la altura de los riesgos identificados.

Fuente de la información

La filtración de datos fue revelada por medios de comunicación como ABC News y CNN, los cuales basaron sus informes en una carta y declaraciones de un funcionario de defensa del Departamento de Defensa de Estados Unidos (el Pentágono) y del Defense Manpower Data Center (DMDC).

Un funcionario del Departamento de Defensa confirmó la brecha a medios como CNN y ABC News, detallando que afectó a 2,76 millones de personas vivas y 294.000 fallecidas.

El Pentágono envió notificaciones por carta a los afectados ofreciendo un año de monitoreo de crédito y protección de identidad, indicando que por el momento no han detectado un uso indebido de los datos expuestos

El 18 de septiembre de 2026, la CISA añadió las vulnerabilidades CVE-2025-39682, CVE-2026-53266 y CVE-2025-39964 a su catálogo de vulnerabilidades explotadas conocidas (KEV), exigiendo su remediación antes del 21 de septiembre en virtud de la Directiva Operativa Vinculante (BOD) 26-04.

El catálogo KEV registra las vulnerabilidades explotadas en ataques reales, mientras que la BOD 26-04 obliga a las agencias federales civiles sujetas a la norma a acelerar la remediación en función del riesgo operativo.

Asimismo, la CISA determinó que las tres vulnerabilidades requieren un triaje forense; esto significa que las agencias afectadas deben investigar los activos potencialmente expuestos en busca de indicios de compromiso, en lugar de limitarse a instalar los parches como única medida de respuesta.

El problema más grave, CVE-2025-39682, es una vulnerabilidad crítica derivada de una comprobación de condiciones incorrecta en la ruta de recepción de TLS (Transport Layer Security) del kernel de Linux. El registro CVE le asigna una puntuación CVSS de 9,8 y describe un caso límite en el que un registro de longitud cero, recuperado de la lista de recepción (rx_list), elude el manejo previsto del tipo de registro en recvmsg(). En consecuencia, los registros TLS posteriores podrían procesarse basándose en suposiciones erróneas sobre el uso de zero-copy (copia cero) y las colas.

El fallo es relevante cuando la funcionalidad TLS del kernel (conocida comúnmente como kTLS) está habilitada y asociada a sockets TCP. Red Hat señala que la ruta de código afectada puede activarse de forma remota al utilizar esta funcionalidad, por lo que la corrección en servicios accesibles a través de Internet que emplean kTLS constituye una prioridad importante.

A nivel de código fuente, la vulnerabilidad infringe una regla fundamental de la ruta de recepción: una operación recvmsg() debe procesar registros de datos contiguos o un único registro que no contenga datos. Cuando el primer registro en cola tiene longitud cero, es posible que se omita la comprobación de transición de tipo, lo que podría generar un estado inseguro en el búfer del socket.

Existen parches disponibles en la rama principal (upstream) del kernel estable; sin embargo, los administradores deben utilizar los paquetes del kernel proporcionados por su distribución que incluyan la corrección, en lugar de evaluar la exposición basándose únicamente en números de versión genéricos.

La vulnerabilidad CVE-2026-53266 es un fallo de escritura fuera de límites (out-of-bounds write) de alta gravedad en el objetivo SNAT de ebtables (parte de netfilter bridge), con una puntuación CVSS de 8,8. Durante una reescritura opcional de la dirección de hardware del remitente en el protocolo ARP (Address Resolution Protocol), el kernel puede invocar skb_store_bits() sin verificar que el rango de destino permita la escritura. Si dichos datos residen en un fragmento no lineal del búfer del socket respaldado por una página de archivo importada mediante splice, la operación puede escribir directamente en la página subyacente.

Red Hat advierte que un atacante local que apunte a un sistema configurado con reglas específicas de bridge netfilter podría provocar corrupción de memoria, denegación de servicio o una posible escalada de privilegios. La corrección upstream garantiza que el rango de la dirección de hardware del remitente ARP permita la escritura antes de que el kernel lea la cabecera ARP y realice la modificación.

La vulnerabilidad CVE-2025-39964 consiste en una condición de carrera (race condition) en la interfaz criptográfica AF_ALG del kernel. Las operaciones de escritura simultáneas en un mismo socket AF_ALG pueden entremezclarse de forma impredecible, dejando el estado interno del socket en una condición inconsistente. La vulnerabilidad tiene una puntuación CVSS de 7,8; ​​su vector indica una ruta de ataque local con privilegios bajos y un impacto potencialmente alto en la confidencialidad, la integridad y la disponibilidad. La corrección añade una propiedad de escritura exclusiva, de modo que solo un escritor pueda utilizar sendmsg() a la vez.

CISA no ha identificado públicamente a los atacantes, a las víctimas ni a las técnicas de explotación asociadas con estos incidentes, y se desconoce si hubo implicación de ransomware. La falta de detalles sobre la campaña no disminuye el riesgo, ya que la inclusión en el catálogo KEV confirma que la explotación ha ocurrido en entornos reales.

Las organizaciones deben instalar las actualizaciones del núcleo (kernel) proporcionadas por el fabricante, reiniciar el sistema con el núcleo corregido y verificar posteriormente la versión activa. Cuando no haya parches disponibles, CISA recomienda aplicar las medidas de mitigación del fabricante, seguir las directrices de la directiva BOD 26-04 específicas para la nube o dejar de utilizar productos sin soporte.

Las medidas de protección temporales pueden incluir deshabilitar la funcionalidad kTLS no utilizada, eliminar las reglas SNAT de ebtables que reescriben ARP, restringir la capacidad CAP_NET_ADMIN o impedir la carga del módulo af_alg, previa evaluación cuidadosa del impacto operativo.

Antes de proceder a la remediación, los equipos de seguridad deben conservar la telemetría pertinente e inspeccionar los sistemas expuestos en busca de fallos del núcleo (kernel crashes), cambios sospechosos de privilegios, actividad inesperada en los espacios de nombres (namespaces) y modificaciones no autorizadas en netfilter.

Ante la proximidad de la fecha límite del 21 de septiembre, los equipos de defensa deben combinar la aplicación rápida de parches con análisis forenses para determinar si los sistemas Linux vulnerables fueron comprometidos antes de la implementación de las correcciones.

Detalles técnicos de la vulnerabilidad

• Tipo de fallo: Elevación de privilegios (EoP) por control de autorización deficiente.

• Mecanismo: Un error en la lógica de código permite evadir los permisos del módem sin requerir credenciales adicionales de ejecución.

• Vector de ataque: Requiere que el atacante opere desde una red cercana o dentro del alcance de radio del dispositivo objetivo para escalar sus permisos de forma imperceptible.

Se recomienda a todos los usuarios de dispositivos Pixel instalar a la brevedad la actualización correspondiente al parche de seguridad del 5 de septiembre de 2026

El fallo es una vulnerabilidad de elevación de privilegios (EoP) derivada de una autorización incorrecta y un fallo en el mecanismo de protección del módem celular.

Según el aviso de seguridad, «en el módem celular existe la posibilidad de eludir los permisos debido a un error lógico en el código», lo que «podría conducir a una elevación de privilegios remota (a corta distancia o en una red adyacente) sin necesidad de privilegios de ejecución adicionales».

En términos sencillos, un atacante situado en una red adyacente —alguien que se encuentre dentro del alcance de radio del dispositivo objetivo y que ya disponga de privilegios básicos en él— puede elevar sus niveles de acceso de forma silenciosa.

Lo que hace que la vulnerabilidad CVE-2026-58704 sea especialmente preocupante es lo poco que requiere el ataque. Google señala que el exploit es de baja complejidad y no precisa interacción por parte del usuario; es decir, la víctima no necesita pulsar un enlace, instalar una aplicación ni cometer ningún error para que la intrusión tenga éxito.

Las vulnerabilidades en la capa del módem son especialmente valoradas por actores sofisticados, ya que se sitúan cerca de la banda base y pueden servir como trampolín sigiloso para comprometer el dispositivo a un nivel más profundo.

La terminología de «alcance limitado y dirigido» empleada por Google es la misma que la empresa ha utilizado históricamente para referirse a vulnerabilidades de día cero explotadas por proveedores de software espía comercial y operadores de vigilancia vinculados a Estados; esto sugiere un grupo de víctimas reducido pero de alto valor, en lugar de una explotación masiva.

La vulnerabilidad CVE-2026-58704 no llegó sola. Según el aviso oficial de Google, el boletín de seguridad de Pixel de septiembre de 2026 —publicado el 15 de dicho mes— corrige un total de 110 vulnerabilidades en el hardware Pixel, incluidas 12 de ejecución remota de código (RCE) y 89 de escalada de privilegios (EoP) clasificadas como críticas o de gravedad alta.

Varias fallas de RCE de gravedad crítica afectan a componentes como el Subsistema Multimedia IP (IMS), libpixelimsmedia, la VPU, el módem y el motor multimedia BigOcean; asimismo, una extensa lista de componentes relacionados con el cargador de arranque (bootloader), el Entorno de Ejecución Confiable (TEE) y la seguridad Titan recibió correcciones críticas para vulnerabilidades de escalada de privilegios.

Dado que los dispositivos Pixel utilizan hardware controlado por Google, reciben un boletín específico, independiente del Boletín de seguridad de Android general que se distribuye a otros fabricantes de equipos originales (OEM).

Los parches para Pixel complementan la actualización general de Android de septiembre de 2026; según informó SecurityWeek, dicha actualización abordó cerca de 180 vulnerabilidades en todo el ecosistema, incluidas docenas de fallos críticos como el error de corrupción de memoria en Wi-Fi identificado como CVE-2026-28662.

Google lanzó dos niveles de parches este mes (2026-09-01 y 2026-09-05); este último incluye todas las correcciones pertinentes de septiembre, así como problemas pendientes de meses anteriores.

Cualquier nivel de parche de seguridad con fecha 2026-09-05 o posterior soluciona completamente la vulnerabilidad CVE-2026-58704 y el resto de los problemas detallados en el boletín; la actualización está llegando a todos los dispositivos Google compatibles. Esta lista de dispositivos compatibles abarca desde la serie Pixel 6 hasta la recién lanzada familia Pixel 11, incluyendo también los modelos Pixel Tablet y Pixel Fold.

Los propietarios de los modelos Pixel 6 y 6 Pro —que ya llevan tiempo en el mercado— deben tener en cuenta que estos dispositivos alcanzan el fin de su vida útil en octubre de 2026, por lo que esta es una de las últimas actualizaciones de seguridad garantizadas que recibirán.

Para instalar la actualización, los usuarios de Pixel deben abrir la aplicación Configuración, ir a Seguridad y privacidad > Sistema y actualizaciones, tocar en Actualización de seguridad, seleccionar Instalar y reiniciar el dispositivo para completar el proceso.

También hay imágenes de firmware disponibles en el sitio para desarrolladores de Google, destinadas a usuarios avanzados que prefieran realizar la instalación manual (flasheo).

Dado que se ha confirmado la explotación activa de estas vulnerabilidades, la aplicación de este parche debe considerarse una medida urgente y no una rutina; esto es especialmente importante para periodistas, ejecutivos, activistas y otras personas que encajan en el perfil típico de objetivos para ataques a módems de tipo "zero-click" (sin interacción del usuario) y de proximidad.

El problema afecta al subsistema de red IPv6 del kernel de Linux. Podría permitir a un atacante local obtener privilegios elevados en un sistema vulnerable.

Actualmente, la CVE-2026-53362 se describe como una vulnerabilidad no especificada del kernel de Linux. Sin embargo, la CISA señaló que el fallo puede facilitar la escalada de privilegios a través del componente de red IPv6.

Las vulnerabilidades de escalada de privilegios son especialmente peligrosas, ya que un atacante con acceso limitado a un sistema Linux podría obtener permisos superiores, llegando incluso a conseguir el control a nivel de root.

La vulnerabilidad puede afectar a distribuciones de Linux y a productos que utilizan el kernel de Linux, incluidas las plataformas de SUSE, Red Hat y otros proveedores.

Las organizaciones no deben asumir que solo las distribuciones mencionadas están afectadas, ya que la exposición depende de la versión del kernel, la compilación del proveedor, la configuración y la disponibilidad de parches de seguridad o medidas de mitigación.

La CISA añadió la vulnerabilidad CVE-2026-53362 a su catálogo el 27 de agosto de 2026 y estableció el 30 de agosto de 2026 como fecha límite para su remediación por parte de las agencias civiles federales del poder ejecutivo.

Asimismo, la agencia ha determinado que esta vulnerabilidad requiere un análisis forense preliminar (triage) conforme a la Directiva Operativa Vinculante (BOD) 26-04, lo que implica que las organizaciones afectadas deben evaluar si ya se ha producido una explotación antes o durante la aplicación del parche.

Aunque la CISA no ha vinculado el fallo a ninguna operación de ransomware específica, las vulnerabilidades de escalada de privilegios suelen ser valiosas para los atacantes una vez que han obtenido acceso inicial.

Un actor de amenazas podría explotar estas debilidades tras establecer un punto de acceso inicial mediante credenciales robadas, una aplicación vulnerable expuesta a Internet, phishing o una carga de trabajo en la nube comprometida.

Contar con privilegios elevados puede permitir a los atacantes desactivar herramientas de seguridad, acceder a datos confidenciales, realizar movimientos laterales y desplegar ransomware en todo el entorno.

La CISA instruyó a las organizaciones a aplicar medidas de mitigación siguiendo las recomendaciones del proveedor y a cumplir con los requisitos de actualización de seguridad basados ​​en el riesgo establecidos en la BOD 26-04.

En los casos en que no exista un parche del proveedor, las partes interesadas deben evaluar si es posible reducir la exposición mediante controles compensatorios. La CISA también indicó que las organizaciones deberían dejar de utilizar los productos afectados si no se dispone de medidas de mitigación.

Los administradores de sistemas Linux deben identificar de inmediato aquellos sistemas críticos para el negocio y expuestos a Internet que ejecuten versiones del núcleo (kernel) potencialmente afectadas.

Los equipos de seguridad deben revisar la actividad de autenticación, los cambios de privilegios, los errores inesperados relacionados con el kernel, los procesos sospechosos que se ejecutan como root y las alertas de detección en endpoints en busca de indicios de actividad posterior a una intrusión.

Dado que la información sobre la explotación sigue siendo limitada, las organizaciones deben seguir de cerca las actualizaciones de los proveedores de distribuciones de Linux y de la CISA.

La prioridad inmediata es determinar qué activos Linux dependen de kernels potencialmente afectados, aplicar las correcciones de los proveedores y realizar un análisis forense preliminar (triage) en los sistemas de alto riesgo.

La vulnerabilidad, identificada como CVE-2026-65643, afecta a todas las versiones compatibles de cPanel y WHM.

cPanel describió el problema como una vulnerabilidad de seguridad crítica e indicó que un titular de cuenta autenticado, con capacidad para añadir dominios aparcados o adicionales, puede crear archivos arbitrarios en el servidor.

"Una explotación exitosa conduce a la ejecución de código como usuario root, otorgando al atacante control total sobre el servidor", señaló cPanel en una notificación dirigida a sus clientes.

cPanel ha publicado las siguientes versiones corregidas:

11.110.0.141 o posterior

11.134.0.53 o posterior

11.136.0.37 o posterior

11.138.0.2 o posterior

11.138.1.7 o posterior (WP Squared)

La notificación incluye a WP Squared en la lista de versiones corregidas, pero no menciona a DNSOnly.

En julio, cPanel corrigió tres vulnerabilidades distintas; las versiones reparadas citadas en aquellos avisos incluían las ramas 11.118 y 11.126. La lista del 27 de agosto abarca las ramas 110, 134, 136 y 138, y la empresa no ha aclarado si las ramas 11.118 y 11.126 siguen contando con soporte.

En su aviso de julio sobre la vulnerabilidad de Exim, cPanel indicó que esta podría permitir la escalada de privilegios desde subcuentas de tipo "Team User" (usuario de equipo). La notificación del 27 de agosto no especifica si las subcuentas "Team User" con permisos sobre dominios aparcados o adicionales se ven afectadas por este problema.

Los servidores configurados para actualizaciones diarias automáticas recibirán la versión corregida de forma automática, según el aviso publicado el 27 de agosto.

Los administradores pueden aplicarla de inmediato iniciando sesión en el servidor como root y ejecutando el comando /scripts/upcp --force. La actualización también puede instalarse desde WHM en la ruta Inicio > cPanel > Actualizar a la última versión (Home > cPanel > Upgrade to Latest Version); posteriormente, se puede verificar la compilación instalada en Configuración del servidor > Preferencias de actualización (Server Configuration > Update Preferences).

Los servidores que ejecutan una versión cuyo ciclo de vida ha finalizado deben actualizarse a una versión con soporte para recibir la corrección.

La notificación dirigida a los clientes no incluye una puntuación CVSS; asimismo, The Hacker News confirmó el 28 de agosto de 2026, a través del registro del programa CVE, que no se ha publicado ningún registro para la vulnerabilidad CVE-2026-65643. En el momento de la verificación, sí figuraban los registros correspondientes a CVE-2026-58048 y CVE-2026-58047, dos fallos de cPanel divulgados el 31 de julio.

cPanel no ha informado si la vulnerabilidad ha sido explotada, y esta no aparece en el catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de la Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. (CISA) en la versión publicada el 27 de agosto de 2026. Dicho catálogo ya incluye dos fallos presentes en un complemento de cPanel.

La CISA añadió la vulnerabilidad CVE-2026-48172 —un problema de escalada de privilegios en el complemento de cPanel para LiteSpeed— el 26 de mayo de 2026, señalando que puede ser explotada por cualquier cuenta de usuario de cPanel para ejecutar scripts arbitrarios con privilegios de root.

El 15 de junio de 2026, añadió la CVE-2026-54420, un fallo relacionado con el seguimiento de enlaces simbólicos (symlinks) en el mismo complemento, que afecta a servidores de alojamiento compartido con CloudLinux o CageFS donde un usuario dispone de acceso FTP o web shell.

El catálogo también incluye la CVE-2026-41940 —un fallo de omisión de autenticación corregido en abril—, la cual se ha utilizado en campañas de ransomware.

La notificación a los clientes no ofrece medidas de mitigación provisionales ni métodos para verificar si un servidor ya ha sido comprometido.

Los administradores pueden aplicarla de inmediato iniciando sesión en el servidor como root y ejecutando el comando /scripts/upcp --force. La actualización también puede instalarse desde WHM en la ruta Inicio > cPanel > Actualizar a la última versión (Home > cPanel > Upgrade to Latest Version); posteriormente, se puede verificar la compilación instalada en Configuración del servidor > Preferencias de actualización (Server Configuration > Update Preferences).

Los servidores que ejecutan una versión cuyo ciclo de vida ha finalizado deben actualizarse a una versión con soporte para recibir la corrección.

La notificación dirigida a los clientes no incluye una puntuación CVSS; asimismo, The Hacker News confirmó el 28 de agosto de 2026, a través del registro del programa CVE, que no se ha publicado ningún registro para la vulnerabilidad CVE-2026-65643. En el momento de la verificación, sí figuraban los registros correspondientes a CVE-2026-58048 y CVE-2026-58047, dos fallos de cPanel divulgados el 31 de julio.

cPanel no ha informado si la vulnerabilidad ha sido explotada, y esta no aparece en el catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de la Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. (CISA) en la versión publicada el 27 de agosto de 2026. Dicho catálogo ya incluye dos fallos presentes en un complemento de cPanel.

La CISA añadió la vulnerabilidad CVE-2026-48172 —un problema de escalada de privilegios en el complemento de cPanel para LiteSpeed— el 26 de mayo de 2026, señalando que puede ser explotada por cualquier cuenta de usuario de cPanel para ejecutar scripts arbitrarios con privilegios de root.

El 15 de junio de 2026, añadió la CVE-2026-54420, un fallo relacionado con el seguimiento de enlaces simbólicos (symlinks) en el mismo complemento, que afecta a servidores de alojamiento compartido con CloudLinux o CageFS donde un usuario dispone de acceso FTP o web shell.

El catálogo también incluye la CVE-2026-41940 —un fallo de omisión de autenticación corregido en abril—, la cual se ha utilizado en campañas de ransomware.

La notificación a los clientes no ofrece medidas de mitigación provisionales ni métodos para verificar si un servidor ya ha sido comprometido.

Una vulnerabilidad crítica en cPanel podría permitir a un cliente de alojamiento obtener control root de todo el servidor

Las actualizaciones, anunciadas el 25 de agosto, constituyen un esfuerzo integral para abordar algunas de las formas más habituales en que los delincuentes comprometen las cuentas de mensajería: el robo de códigos de verificación, el aprovechamiento de protecciones débiles, la manipulación de usuarios para vincular dispositivos no autorizados y el uso de llamadas inesperadas para generar presión o sensación de urgencia.

En el centro de estos cambios se encuentra una mejora sustancial del sistema de verificación en dos pasos de WhatsApp. Los usuarios podrán sustituir el actual PIN de seguridad de seis dígitos por una contraseña alfanumérica más larga que admita caracteres especiales, creando así una barrera adicional más sólida frente al registro no autorizado de cuentas.

WhatsApp también está ampliando la compatibilidad con claves de acceso (passkeys), permitiendo a los usuarios registrar más de una clave para una misma cuenta cuando utilizan dispositivos tanto Android como iOS. En Android, la compañía está introduciendo información adicional sobre quien llama, diseñada para ayudar a los usuarios a evaluar las llamadas de números desconocidos antes de contestar.

La empresa informó que más de mil millones de personas ya han configurado una clave de acceso en WhatsApp, lo que pone de relieve la rapidez con la que la autenticación sin contraseña se ha integrado en la estrategia de seguridad de la plataforma.

WhatsApp sustituye los PIN de verificación de seis dígitos por contraseñas más robustas

El cambio más inmediato en la seguridad de las cuentas es la transición de un PIN de verificación en dos pasos de seis dígitos a una contraseña más flexible.

Anteriormente, los usuarios de WhatsApp podían activar la verificación en dos pasos configurando un PIN numérico que ofrecía una capa de protección adicional al registrar su número de teléfono en el servicio. Este mecanismo ayudaba a evitar que un atacante tomara el control de una cuenta utilizando únicamente un código de verificación robado o interceptado.

Sin embargo, los PIN de seis dígitos presentan limitaciones prácticas. Los usuarios suelen elegir combinaciones predecibles, números repetidos o secuencias que resultan más fáciles de recordar, pero también más fáciles de adivinar.

El sistema actualizado permite utilizar contraseñas más largas que incluyen letras, números y caracteres especiales. Esta mayor variedad de combinaciones posibles puede mejorar considerablemente la resistencia a intentos de adivinación en comparación con un PIN numérico corto, especialmente cuando los usuarios eligen contraseñas únicas que no reutilizan en otros servicios.

Meta describió el nuevo requisito de contraseña como una medida de seguridad adicional capaz de proteger la cuenta incluso si alguien obtiene el código de un solo uso empleado durante el registro.

Esta distinción es importante porque, a menudo, los atacantes no necesitan vulnerar el cifrado subyacente de WhatsApp para comprometer una cuenta. En su lugar, atacan el proceso de autenticación persuadiendo a las víctimas para que revelen sus códigos de verificación, haciéndose pasar por el servicio de asistencia técnica o explotando vulnerabilidades asociadas al número de móvil del usuario.

Una segunda credencial de verificación más robusta supone un obstáculo adicional. Incluso si un delincuente logra obtener un código de registro, necesitaría también la contraseña de la cuenta —que es independiente— para completar la toma de control en los casos en que dicha protección esté activada.

Esta actualización no implica que la contraseña sea intrínsecamente inmune al phishing. Las contraseñas pueden seguir siendo robadas si los usuarios las introducen en sitios web fraudulentos o las revelan a alguien que se hace pasar por un contacto de confianza. Su valor reside en añadir un control de seguridad más sólido a nivel de cuenta, complementando el proceso de verificación mediante código de un solo uso ya existente.

Los usuarios deben elegir una contraseña larga y única, evitando reutilizar credenciales empleadas en servicios de correo electrónico, banca o redes sociales. Un gestor de contraseñas puede ayudar a generar y almacenar una combinación más segura sin depender de patrones fáciles de recordar.

El uso de múltiples claves de acceso amplía la protección en Android e iOS

La segunda gran actualización de WhatsApp introduce la compatibilidad con más de una clave de acceso (passkey) por cuenta, respondiendo a las necesidades de los usuarios que utilizan distintos dispositivos y sistemas operativos.

Una clave de acceso permite al usuario verificar su identidad mediante el mecanismo de seguridad ya configurado en su dispositivo, como el reconocimiento de huella dactilar, la autenticación facial o el código de bloqueo de pantalla.

En lugar de introducir manualmente una contraseña o depender de un código de verificación enviado por mensaje de texto, el proceso de autenticación utiliza credenciales criptográficas vinculadas al dispositivo o al gestor de credenciales del usuario.

WhatsApp ha informado que los usuarios que utilizan tanto Android como iOS ya pueden añadir más de una clave de acceso a una misma cuenta. La compañía indica a los usuarios que deben dirigirse a la sección Configuración > Cuenta > Claves de acceso de la aplicación para configurar esta función.

Este cambio resulta especialmente relevante para aquellas personas que utilizan dispositivos de distintos ecosistemas, alternan entre teléfonos personales y laborales, o cambian un dispositivo Android por un iPhone y desean mantener opciones de autenticación seguras.

El uso de múltiples claves de acceso también puede reducir la dependencia de un único dispositivo o de un sistema de almacenamiento de credenciales específico de una plataforma. No obstante, la experiencia concreta de recuperación y sincronización seguirá dependiendo del dispositivo, el sistema operativo, el proveedor de credenciales y la configuración de la cuenta en cuestión.

El anuncio no especifica si WhatsApp establece un límite máximo de claves de acceso, qué proveedores de credenciales son compatibles en cada configuración ni si todos los usuarios recibirán la actualización simultáneamente. Es posible que estos detalles varíen a medida que avance el despliegue de la función.

Cómo las passkeys mejoran la protección contra el phishing

Las passkeys se basan en la criptografía de clave pública en lugar de en un secreto reutilizable que una persona deba memorizar y escribir.

Cuando un usuario crea una passkey, se genera un par de claves criptográficas. La clave privada permanece en el dispositivo del usuario, en la llave de seguridad o en el gestor de credenciales, mientras que la clave pública asociada se registra en el servicio en línea.

Durante la autenticación, el servicio envía un desafío que se firma utilizando la clave privada. A continuación, el servicio verifica dicha respuesta mediante la clave pública que ya posee.

Dado que la clave privada no se introduce manualmente en un formulario de inicio de sesión, los atacantes no pueden capturarla a través de una página falsa convencional (como las que imitan formularios de acceso) de la misma manera que podrían robar una contraseña o un código de un solo uso.

La FIDO Alliance, organización que desarrolla y promueve estándares de autenticación ampliamente utilizados, explica que las passkeys están diseñadas para vincularse al servicio legítimo para el que fueron creadas. Esta vinculación las hace resistentes a las técnicas comunes de phishing, las cuales dependen de engañar al usuario para que introduzca sus credenciales en un sitio web fraudulento.

Los usuarios de Android verán más información sobre las llamadas de números desconocidos

WhatsApp también está incorporando información contextual adicional en las pantallas de llamada cuando se recibe una llamada de un número que no está guardado en los contactos del usuario.

En Android, la aplicación mostrará datos como si el número parece provenir de otro país y si la persona que llama comparte algún grupo con el destinatario.

Estos detalles adicionales tienen como objetivo ayudar a los usuarios a tomar una decisión más informada antes de contestar.

Una llamada internacional inesperada no implica necesariamente un fraude, y compartir un grupo no garantiza que quien llama sea de confianza. Sin embargo, estos detalles pueden ayudar a los usuarios a identificar situaciones que requieren mayor precaución.

Por ejemplo, una persona que afirma representar a una organización local puede parecer menos creíble si su número está asociado a otro país y no existe ninguna conexión evidente.

Del mismo modo, puede resultar más fácil identificar a una persona desconocida si comparte un grupo profesional o comunitario, aunque los atacantes también pueden unirse a grupos públicos o comprometer cuentas legítimas.

Esta función está diseñada para contrarrestar la sensación de urgencia que suele propiciar el fraude telefónico. Los delincuentes a menudo intentan mantener a las víctimas al teléfono, presionarlas para que tomen decisiones inmediatas y disuadirlas de verificar por su cuenta la identidad de quien llama.

La Comisión Federal de Comercio de EE. UU. ha advertido que los estafadores suelen suplantar a organizaciones de confianza y crear situaciones de emergencia ficticias para obtener credenciales de cuenta, información financiera y códigos de verificación.

El anuncio de WhatsApp especifica que esta mejora en la información de la pantalla de llamada se aplicará en Android. No se indica cuándo, ni si acaso, se implementará esta misma función en iOS.

Estos fallos afectan a ramas ampliamente desplegadas, incluidas OpenSSL 4.0, 3.6, 3.5, 3.4 y 3.0, así como —en algunos casos— a la línea heredada 1.1.1; por ello, la aplicación de parches es una prioridad para cualquier organización que utilice servicios TLS, CMS o CMP basados ​​en esta biblioteca.

El problema más grave, registrado como CVE-2026-63072 y clasificado con una gravedad moderada, reside en el código de descifrado CMS de OpenSSL. Al determinar el tamaño del búfer para una clave desempaquetada (unwrapped key), la biblioteca consulta la longitud de salida esperada; sin embargo, la primitiva de desempaquetado AES-WRAP-PAD puede llegar a escribir y limpiar más bytes de los que indica dicha consulta.

Un atacante puede tomar un mensaje cifrado legítimo, modificar un único byte en el identificador del algoritmo de empaquetado de claves (key-wrap) y forzar una escritura de 8 bytes fuera de los límites de la memoria dinámica (heap) cada vez que la víctima invoque la función CMS_decrypt(). Dado que tanto el tamaño como el valor de la escritura son fijos, la explotación resulta fiable y no requiere una configuración especial del servidor; no obstante, OpenSSL señala que la consecuencia más probable es la corrupción de la memoria dinámica y una denegación de servicio, en lugar de la ejecución de código.

Una segunda vulnerabilidad de gravedad moderada, la CVE-2026-63076, afecta al Protocolo de Gestión de Certificados (CMP). Durante la verificación MAC basada en contraseña, OpenSSL se limita a comprobar que un parámetro del algoritmo de protección no sea nulo, sin verificar su tipo real; esto permite que un mensaje especialmente manipulado provoque una desreferencia de puntero no válido.

El problema más grave, registrado como CVE-2026-63072 y clasificado con una gravedad moderada, reside en el código de descifrado CMS de OpenSSL. Al determinar el tamaño del búfer para una clave desempaquetada (unwrapped key), la biblioteca consulta la longitud de salida esperada; sin embargo, la primitiva de desempaquetado AES-WRAP-PAD puede llegar a escribir y limpiar más bytes de los que indica dicha consulta.

Un atacante puede tomar un mensaje cifrado legítimo, modificar un único byte en el identificador del algoritmo de empaquetado de claves (key-wrap) y forzar una escritura de 8 bytes fuera de los límites de la memoria dinámica (heap) cada vez que la víctima invoque la función CMS_decrypt(). Dado que tanto el tamaño como el valor de la escritura son fijos, la explotación resulta fiable y no requiere una configuración especial del servidor; no obstante, OpenSSL señala que la consecuencia más probable es la corrupción de la memoria dinámica y una denegación de servicio, en lugar de la ejecución de código.

Una segunda vulnerabilidad de gravedad moderada, la CVE-2026-63076, afecta al Protocolo de Gestión de Certificados (CMP). Durante la verificación MAC basada en contraseña, OpenSSL se limita a comprobar que un parámetro del algoritmo de protección no sea nulo, sin verificar su tipo real; esto permite que un mensaje especialmente manipulado provoque una desreferencia de puntero no válido.

Este fallo puede ser desencadenado remotamente por un atacante no autenticado contra cualquier aplicación que ejecute un servidor CMP que acepte mensajes protegidos mediante PBM, y también puede provocar el bloqueo de un cliente CMP que se conecte a un servidor malicioso o interceptado.

El boletín de seguridad también detalla cinco problemas de gravedad baja. La vulnerabilidad CVE-2026-14457 puede provocar una desreferencia de puntero nulo en servidores o clientes TLS configurados con claves públicas sin procesar (Raw Public Keys) pero sin un certificado asociado, cuando la otra parte envía la extensión signature_algorithms_cert.

Este fallo puede ser desencadenado remotamente por un atacante no autenticado contra cualquier aplicación que ejecute un servidor CMP que acepte mensajes protegidos mediante PBM, y también puede provocar el bloqueo de un cliente CMP que se conecte a un servidor malicioso o interceptado.

El boletín de seguridad también detalla cinco problemas de gravedad baja. La vulnerabilidad CVE-2026-14457 puede provocar una desreferencia de puntero nulo en servidores o clientes TLS configurados con claves públicas sin procesar (Raw Public Keys) pero sin un certificado asociado, cuando la otra parte envía la extensión signature_algorithms_cert.

El fallo tiene una puntuación de gravedad CVSS de 9,8. Puede permitir a atacantes no autenticados cargar archivos maliciosos, ejecutar código de forma remota y, potencialmente, obtener el control total de los sitios de WordPress afectados.

La vulnerabilidad, detallada por Wordfence, afecta a las versiones de Everest Forms anteriores a la 3.0.9.5. Se encuentra en la lógica de gestión de carga de archivos del plugin, concretamente en la clase EVF_Form_Fields_Upload.

Una validación insuficiente de los tipos de archivo y de las rutas puede permitir a los atacantes cargar archivos arbitrarios, incluidos scripts PHP que el servidor web podría ejecutar.

Un atacante no necesita una cuenta de WordPress válida para explotar la vulnerabilidad. Al atacar una función de carga de archivos mediante formularios que sea vulnerable, utilizando peticiones especialmente manipuladas, un actor malicioso podría alojar una web shell PHP maliciosa en el servidor.

Una web shell proporciona a los atacantes una interfaz remota para ejecutar comandos, explorar archivos, extraer bases de datos, modificar el contenido del sitio o instalar malware adicional.

Esto puede convertir un sitio web comprometido en una plataforma para realizar phishing, distribuir malware, generar spam de SEO, robar credenciales o lanzar ataques contra los visitantes del sitio.

El problema también podría permitir la eliminación arbitraria de archivos. Los atacantes podrían borrar archivos importantes de WordPress, incluido wp-config.php, que almacena los detalles de conexión a la base de datos.

La eliminación de este archivo puede hacer que la instancia de WordPress entre en modo de instalación, creando así otra vía para que los atacantes conecten el sitio a una base de datos bajo su control y tomen el control del entorno, según indica el informe de Wordfence.

Los administradores de sitios web deben actualizar inmediatamente Everest Forms a la versión 3.0.9.5 o posterior. Aquellos sitios que no puedan aplicar el parche rápidamente deberían desactivar temporalmente el plugin, especialmente si utilizan formularios públicos de carga de archivos.

Zoom corrigió el fallo mediante actualizaciones de software distribuidas entre junio y julio, dos meses antes de la divulgación pública del problema. A la fecha, no se han registrado casos de explotación en el entorno real y la CISA no ha incluido estos identificadores en su registro de vulnerabilidades explotadas conocidas.

Las versiones que corrigen estas vulnerabilidades:

·        Zoom Workplace, todas las plataformas compatibles, versiones anteriores a la 7.1.5 y a la 7.0.6 en sus respectivas ramas

·        Zoom Workplace VDI Client para Windows, versiones anteriores a la 7.0.11 y a la 6.6.16

·        Zoom Rooms y Zoom Meeting SDK, todas las plataformas, versiones anteriores a la 7.1.0 (y anteriores a la 7.1.5 para la tercera vulnerabilidad).

La investigación provino de "A Security", una startup de seguridad ofensiva fundada en Israel que salió de su fase de desarrollo confidencial (stealth mode) en junio tras recaudar 37 millones de dólares en financiación. La empresa afirma haber pasado de detectar la vulnerabilidad a crear un exploit funcional en menos de un día, utilizando menos de 20 prompts en modelos de IA disponibles públicamente.

Nadie ajeno a la compañía puede verificar dicha afirmación, ya que el informe no especifica qué modelo se utilizó. Además, el proveedor asigna a los fallos una gravedad menor que la empresa investigadora y atribuye uno de los tres defectos a su propio equipo interno.

Zoom no ha publicado detalles técnicos, por lo que la información sobre el funcionamiento interno proviene de la ingeniería inversa realizada por la propia firma. Un dibujo no se transmite a través de la red como una imagen convencional; el cliente lo convierte en un objeto estructurado y lo envía como una secuencia de valores de conteo seguidos de datos, y el receptor confía en dichos valores para determinar cuánta información debe leer.

Uno de estos procesos rellena un búfer fijo de 128 bytes sin verificar si los datos caben en él; dado que se trata del último campo del objeto, un valor de conteo excesivo provoca que la escritura sobrepase el límite del búfer y sobrescriba la dirección de retorno.

La vulnerabilidad se originaba en la ausencia de validación sobre el origen de los mensajes transmitidos entre el presentador y los espectadores. El canal de comunicación no verificaba el rol ni la identidad del remitente al procesar la información.

Durante el proceso de despacho, el sistema interpretaba el identificador del tipo de mensaje (por ejemplo, 0x10001 para el envío de objetos o 0x10002 para confirmaciones de recepción) y lo entregaba directamente al analizador correspondiente. Al enviar un objeto bajo el canal reservado para confirmaciones, el cliente de la víctima procesaba y reconstruía la estructura recibida de forma remota sin validar su procedencia.

Zoom clasifica estas vulnerabilidades como CVE-2026-53413 (puntuación CVSS: 8,3), una escritura fuera de los límites del búfer (buffer over-write); CVE-2026-53414 (puntuación CVSS: 6,5), una lectura fuera de los límites del búfer (buffer over-read), ambas cubiertas por los boletines ZSB-26015 y ZSB-26016; y CVE-2026-53415 (puntuación CVSS: 8,3), un error de uso tras liberación (use-after-free), cubierto por el ZSB-26017.

La empresa asigna a las tres una puntuación de 9,0 según el estándar CVSS 4.0, una cifra que no aparece en ninguno de los boletines. Zoom emite sus propios registros CVE y el NIST ya no reevalúa sistemáticamente sus puntuaciones, por lo que es probable que se mantengan las cifras más bajas. Asimismo, los vectores de vulnerabilidad del fabricante indican que se requiere interacción por parte del usuario, lo cual resulta contradictorio con la descripción del fallo como un ataque de tipo "zero-click" (sin interacción).

Las dos versiones difieren principalmente en lo relativo a la vulnerabilidad de lectura fuera de límites (over-read). La empresa afirma haber recuperado memoria del heap no inicializada del cliente de una víctima —la cual contenía código activo y punteros a tablas virtuales (vtable)—, que es precisamente el material necesario para eludir las técnicas de aleatorización de direcciones de memoria.

El boletín de seguridad indica que el mismo fallo podría permitir a un participante «provocar una denegación de servicio» y califica el impacto en la confidencialidad como nulo. También hay discrepancias en la atribución del mérito: dos boletines mencionan a Idan Levcovich, de A Security, mientras que el que trata sobre el fallo de uso tras liberación (use-after-free) reconoce la labor de Zoom Offensive Security, el equipo interno responsable de la vulnerabilidad crítica (puntuación 9.8) que permitía la toma de control de cuentas y que la compañía corrigió en julio.

La publicación de la startup atribuye los tres hallazgos a su propio equipo, aunque reconoce que Zoom ya estaba al tanto del tercero y lo había filtrado en el servidor antes de recibir el informe. La descripción del trabajo realizado con IA también resulta más compleja y menos clara que el resumen inicial de la propia empresa.

La primera fase —una clasificación automatizada de funciones accesibles desde la capa de Java— generó una lista de 3.762 funciones distribuidas en 70 bibliotecas, pero no detectó en absoluto la biblioteca vulnerable, situándola en el puesto 45. Esta solo salió a la luz cuando rastrearon el cliente en ejecución durante una llamada activa, analizando funcionalidad por funcionalidad. Levcovich señala que la barrera para desarrollar este tipo de exploit «se ha derrumbado y no volverá a levantarse».

Esta divulgación se produce poco después de que OpenAI dividiera su programa Daybreak y lanzara GPT-5.6-Cyber ​​exclusivamente para socios seleccionados, argumentando que dicha capacidad requiere restricciones de acceso. La startup afirma haber logrado sus resultados utilizando modelos disponibles para cualquier usuario. Según las propias métricas de OpenAI, su modelo público con medidas de seguridad responde al 1,5 % de las consultas avanzadas sobre seguridad ofensiva, frente al 95 % que responde el modelo restringido.

El fallo de la base de datos está registrado como CVE-2026-58048 (puntuación CVSS 4.0: 9,4) y afecta a todas las versiones compatibles de cPanel & WHM, así como a WP Squared. Para explotarlo, se requiere una cuenta de cPanel válida y acceso a la función de MySQL/MariaDB. A partir de ahí, según el proveedor, el titular de la cuenta podría ejecutar comandos arbitrarios en la base de datos con privilegios administrativos completos.

Dependiendo del sistema operativo y de la configuración del motor de base de datos, "esto podría derivar en un compromiso a nivel del sistema operativo".

cPanel corrigió la vulnerabilidad CVE-2026-58048 en las siguientes versiones:

·       11.110.0.137

·       11.118.0.71

·       11.126.0.78

·       11.134.0.48

·       11.136.0.32

·       138.1.6 para WP Squared

Los servidores que no puedan actualizarse de inmediato pueden revocar temporalmente la función MySQL a los usuarios de cPanel. Esto permite que las bases de datos existentes sigan funcionando, pero impide a los usuarios añadir o eliminar bases de datos. Los administradores pueden realizar la actualización desde WHM o utilizar el comando documentado por cPanel:

/usr/local/cpanel/scripts/upcp --force

La información complementaria publicada por la CISA el 4 de agosto indicaba «Explotación: ninguna», evaluaba el fallo como no automatizable y calificaba su impacto técnico como total. Se trata de una instantánea que no refleja la situación en los días posteriores.

En condiciones normales de funcionamiento, cPanel admite privilegios a nivel de base de datos que no requieren acceso de superusuario (SUPER) ni permiten modificaciones globales. La vulnerabilidad CVE-2026-58048 elude estas limitaciones al provocar que las instrucciones SQL se ejecuten en el contexto administrativo de la base de datos.

El fallo reside en el proceso de cambio de nombre de bases de datos de cPanel. El registro de la CNA en HackerOne señala que el modo SQL no se conserva al renombrar una base de datos, lo que provoca que el código SQL se ejecute con privilegios de root. Según la documentación de la empresa sobre bases de datos, el sistema crea una base de datos de reemplazo, traslada los datos originales, vuelve a generar los permisos y el código almacenado, y finalmente elimina la base de datos antigua junto con sus permisos.

El aviso del proveedor califica el problema como una escalada de privilegios y no utiliza el término «inyección SQL». Por su parte, la CNA clasifica el mismo defecto como CWE-89 (inyección SQL). Ambos registros describen el mismo error desde perspectivas distintas. Ni el aviso ni el registro CVE identifican la entrada inyectada, el modo SQL afectado ni la carga útil (payload) exacta. Tampoco aclaran si las subcuentas de usuario de equipo (Team User) —inicios de sesión con permisos restringidos que puede crear el propietario de una cuenta— cumplen con la definición de titular de cuenta autenticado en caso de tener acceso a la base de datos.

Una calificación de «Crítico» es una medida de gravedad. No indica cuántos servidores cuentan con usuarios en condiciones de explotar la vulnerabilidad; en este caso, dicho grupo viene determinado por quién posee cuentas en el sistema: la situación de un servidor cuyas cuentas pertenecen a una sola empresa difiere de la de uno que vende cuentas a desconocidos. La distinción no es absoluta, ya que las cuentas pueden ser objeto de phishing o revenderse. Asimismo, esta calificación no aporta detalles sobre las consecuencias, que la CISA evaluó como totales.

La vulnerabilidad CVE-2026-58047 (puntuación CVSS 4.0: 5,6) es un problema de contrabando de solicitudes HTTP (HTTP request smuggling) en cpsrvd, el demonio que sirve las interfaces de cPanel y WHM. En determinadas condiciones, un atacante remoto no autenticado podría manipular las respuestas enviadas a otros usuarios del mismo servidor. El registro de la CNA indica que, como resultado, podrían filtrarse credenciales.

Cuando no es posible aplicar el parche de inmediato, la solución alternativa consiste en deshabilitar la reutilización de conexiones backend estableciendo cpsrvd_keepalives_disabled=1 en el archivo /var/cpanel/cpanel.config y reiniciando cpsrvd. cPanel señala que esta medida obliga a establecer una nueva conexión TCP y TLS para cada solicitud en los puertos 2083, 2087 y 2096, lo que aumenta la latencia y el uso de CPU en servidores con alta carga de trabajo. cPanel reconoce a Vincent55 Yang como la persona que notificó ambas vulnerabilidades.

El tercer aviso de cPanel aborda la vulnerabilidad GCVE-25-2026-07-45-3 en Exim. El archivo .forward de un usuario local puede desencadenar una expansión de cadenas insegura en el enrutador de redirección (redirect router) bajo ciertas configuraciones de transporte mediante tuberías (pipe-transport). Con la configuración predeterminada de cPanel, la expansión y la ejecución se realizan con los privilegios del usuario de cPanel; según la empresa, esto podría permitir una escalada de privilegios desde subcuentas de tipo "Team User".

El boletín de seguridad de Exim indica que la explotación requiere un enrutador de redirección que gestione archivos .forward, un transporte de tipo pipe accesible, la opción force_command habilitada en dicho transporte y la ejecución con privilegios elevados. La versión Exim 4.99.5 elimina la expansión vulnerable.

Exim 4.99.5 también corrige la vulnerabilidad GCVE-25-2026-07-45-1, un fallo de recorrido de directorios local de gravedad alta que se produce a través de los argumentos de línea de comandos queue-name. Según Exim, esta vulnerabilidad permite acceder a archivos fuera del área de spool y puede utilizarse para la escalada de privilegios.

Los propios boletines de cPanel discrepan sobre qué compilaciones incluyen la corrección. El boletín relativo a la base de datos enumera la compilación 11.118.0.71 entre las versiones parcheadas; sin embargo, los boletines sobre request-smuggling y Exim —publicados en la misma actualización— omiten por completo la rama 11.118 de sus listas. Quienes utilicen dicha rama deberían verificar la versión menor instalada consultando el boletín de la base de datos, en lugar de confiar en las listas más reducidas.

Los dos fallos de seguridad, identificados como CVE-2026-63030 y CVE-2026-60137, han recibido el nombre en clave de "wp2shell".

"A primera hora del sábado (UTC), la explotación exitosa ya estaba muy avanzada; inicialmente se utilizó código de explotación público para extraer credenciales cifradas (hashes), seguido de la ejecución remota de código una vez que se hicieron públicos detalles adicionales", declaró a The Hacker News Jake Knott, investigador principal de seguridad en watchTowr.

"Desde nuestra perspectiva, al contar con una base de clientes global, observamos un impacto generalizado de esta vulnerabilidad en organizaciones de todos los tamaños y sectores".

Los datos de telemetría recopilados por KEVIntel indican que 13 direcciones IP únicas —procedentes de Suiza, Alemania, el Reino Unido, Indonesia, Lituania, los Países Bajos y Singapur— se han vinculado a la explotación de la vulnerabilidad CVE-2026-63030.

Ryan Dewhurst, fundador y director ejecutivo de KEVIntel, explicó a The Hacker News que la explotación ha pasado de atacar sensores específicos de WordPress a realizar escaneos masivos de Internet, con solicitudes que coinciden con exploits de prueba de concepto (PoC) disponibles públicamente.

"Los atacantes emplearon diversas técnicas de inyección SQL, incluidas cargas útiles de tipo ciego (blind), basadas en UNION y basadas en lógica booleana", señaló Dewhurst. "En nuestras propias pruebas, el análisis asistido por IA facilitó enormemente la reproducción de la vulnerabilidad y el desarrollo de una prueba de concepto funcional. Esto reduce considerablemente la barrera técnica para crear código de explotación una vez que se dispone públicamente de suficientes detalles sobre la vulnerabilidad".

La cadena de explotación, descubierta por Searchlight Cyber ​​utilizando OpenAI GPT 5.6 Sol en un proceso de más de 10 horas, permite esencialmente que atacantes no autenticados logren la ejecución remota de código en instalaciones estándar de WordPress, en cualquier versión lanzada desde diciembre de 2025. Se han omitido los detalles técnicos dada la gravedad del problema.

"El ataque no requiere condiciones previas y puede ser ejecutado por un usuario anónimo en una instalación estándar de WordPress sin plugins", señaló Searchlight Cyber.

Según Cloudflare, la vulnerabilidad CVE-2026-63030 permite la ejecución remota de código (RCE) sin autenticación únicamente cuando no se utiliza la caché de objetos persistente. Si bien la vulnerabilidad de inyección SQL (CVE-2026-60137) está presente desde la versión 6.8 en adelante, la RCE afecta a las versiones a partir de la 6.9.

"Esta explotación utiliza una cadena de vulnerabilidades de dos fases para lograr una inyección SQL sin autenticación en una instalación estándar de WordPress mediante una única solicitud HTTP", explicó Ben Marr, ingeniero de seguridad de Intruder. "La CVE-2026-60137 es el punto de entrada: un fallo de confusión de rutas en el endpoint de procesamiento por lotes de la API REST que elude la autenticación, permitiendo a un atacante invocar controladores internos sin ninguna verificación de permisos".

Este fallo se origina en una sanitización incorrecta del parámetro 'author__not_in' dentro de 'WP_Query' cuando un plugin o tema le transmite datos no confiables. Esta vulnerabilidad permite que una entrada manipulada altere una consulta a la base de datos, lo que podría conducir a un acceso no autorizado o a la manipulación de datos.

Datos de Wiz, empresa propiedad de Google, sugieren que el 60 % de las organizaciones que utilizan WordPress tenían inicialmente al menos una instancia vulnerable en el momento en que se publicaron estos CVE, y el 25 % exponía un servidor vulnerable a Internet. Estas cifras han disminuido a medida que las organizaciones continúan aplicando las correcciones.

La filial de seguridad en la nube ha observado las siguientes actividades posteriores a la explotación tras el aprovechamiento de ambos fallos:

• Carga de un plugin malicioso.

• Enumeración de usuarios y recopilación de nombres de usuario y direcciones de correo electrónico de administradores.

• Ejecución de ataques de inclusión de archivos locales (LFI) para obtener credenciales de bases de datos y claves de autenticación con fines de exfiltración.

• Acceso al panel de administración y autenticación exitosa.

• Carga de una web shell PHP básica que facilita la ejecución remota de código.

"También hemos observado una actividad de escaneo de gran volumen sin una explotación posterior, lo que sugiere campañas oportunistas de escaneo masivo que buscan identificar objetivos vulnerables, coexistiendo con actividades legítimas de escaneo de seguridad", señalaron los investigadores de Wiz, Shahar Dorfman y Gili Tikochinski. "Aún no hemos detectado movimientos laterales ni exfiltración de datos, pero continuamos monitoreando e investigando".

Como parte de esta actividad, también se ha observado una web shell de 150 KB disfrazada de un plugin de seguridad legítimo de WordPress llamado CMSmap. Esta herramienta actúa como una "plataforma de ataque completa" que admite gestión de archivos, acceso a bases de datos, escaneo de puertos, inyección de código por lotes y múltiples módulos de escalada de privilegios, incluida la explotación de UDF de MySQL.

WatchTowr también informó que los atacantes han comenzado a lanzar ataques indiscriminados por toda la Internet tras la publicación de un exploit público; sus sistemas trampa (honeypots) han registrado "decenas de miles de intentos de explotación".

Se estima que, tras la explotación, se crearon más de 100 cuentas de administrador con acceso de puerta trasera (backdoor), lo que permitió a los atacantes desplegar plugins falsos de WordPress para ejecutar código o descargar herramientas secundarias con el fin de comprometer aún más el sistema. En al menos un caso, se observó a un actor de amenazas intentando instalar repetidamente Overlord RAT, un troyano de acceso remoto basado en Golang.

Se recomienda a los responsables de seguridad que inspeccionen sus instancias de WordPress en busca de nuevas cuentas de administrador, plugins maliciosos u otros archivos sospechosos —independientemente de si han aplicado los parches— para erradicar la amenaza por completo.

Dewhurst señaló que el alcance potencial del ataque se vio reducido gracias a las medidas defensivas ya existentes. "WordPress lleva años admitiendo actualizaciones automáticas en segundo plano para los parches de seguridad; además, algunos proveedores de infraestructura recibieron aviso previo y pudieron desplegar parches virtuales rápidamente", añadió. "Estas medidas redujeron la ventana de exposición de los sitios que se actualizaban automáticamente o que estaban protegidos por las reglas WAF correspondientes.

"Sin embargo, los sitios en los que las actualizaciones automáticas estaban desactivadas, no eran compatibles o fallaron podrían seguir siendo vulnerables. Dada la enorme presencia de WordPress en la web, es posible que un número considerable de instalaciones aún carezca del parche de seguridad. Los administradores de sitios que permanecieron vulnerables tras la publicación del código del exploit deberían actualizar sus sistemas de inmediato y buscar indicadores de compromiso, en lugar de asumir que basta con aplicar el parche".