Un informe privado de errores llega al dominio público
La Zero Day Initiative (ZDI) de Trend Micro encendió el "Black October" el 22 de octubre, cuando publicó por error un conjunto de vulnerabilidades del kernel de Linux sin parchear en la lista de correo pública del kernel de Linux, en lugar de en la lista de seguridad privada. El mantenedor de la versión estable de Linux, Greg Kroah-Hartman, desafió públicamente a ZDI en la lista, exigiendo una explicación por la divulgación prematura de exploits de día cero.
Fundamentalmente, la filtración expuso dos vulnerabilidades graves de Server Message Block (SMB), ambas con una calificación CVSS 9.0 y capaces de ejecutar código de forma remota. Un fallo, un desbordamiento de enteros en SMB Direct (ZDI-CAN-33549), permitía desbordamientos de búfer manipulando los valores de tamaño del búfer. El segundo, una condición de carrera en ksmbd (ZDI-CAN-33774), permitía la ejecución remota de código sin autenticación.
Los informes llegaron antes de que las correcciones estuvieran ampliamente disponibles, dejando expuestos a millones de sistemas. No se trató de una publicación deliberada ni de evidencia de un ataque activo, sino de una divulgación accidental, lo que subraya la creciente presión sobre la divulgación coordinada de vulnerabilidades. El diseño de SMB, que procesa datos de red externos para compartir archivos, hizo que estos errores fueran particularmente peligrosos, recordando a la epidemia de WannaCry de 2017.
Por qué los errores de SMB pueden convertirse en un problema para todos
Server Message Block, o SMB, es el protocolo de red que permite compartir archivos y carpetas. Su arquitectura lo hace inherentemente peligroso: los servicios que manejan datos de red entrantes, como SMB, a menudo se ejecutan antes del inicio de sesión, lo que los hace accesibles para atacantes no autenticados. Esta exposición directa a Internet amplifica el radio de impacto de cualquier fallo.
Vimos este peligro de primera mano en 2017 con WannaCry, un brote de ransomware que explotó una vulnerabilidad de SMB en Windows. Aunque los errores actuales de Linux son distintos, WannaCry sirve como un crudo recordatorio de la rapidez con la que los fallos de SMB pueden comprometer redes enteras. Las vulnerabilidades de SMB del kernel de Linux, ambas calificadas con 9.0 en la escala de severidad CVSS, presentan riesgos similares de ejecución remota de código.
Más allá de los fallos críticos de SMB, otros problemas reportados incluyen:
- Escaladas de privilegios locales en la pila de red (
skb_zerocopy) - Una escalada de privilegios local en el controlador de gráficos de VMware (
vmwgfx) - Una fuga de información en el código de destino NVMe (
nvmet)
La exposición a estas vulnerabilidades adicionales varía drásticamente según la configuración y el despliegue del sistema. Aunque no son tan catastróficas de inmediato como las RCE de SMB, estos problemas subrayan la fragilidad sistémica revelada durante el "Black October".
Black October fue un cúmulo de divulgaciones
Black October no fue solo una filtración de Linux; fue un diluvio. La exposición accidental de vulnerabilidades del kernel sin parchear llegó en medio de una tormenta de divulgaciones de seguridad críticas, llevando a las organizaciones globales al límite. Cabe destacar que dos fallos graves de PHP (CVE-2026-109618, CVE-2026-109619) obligaron a los gobiernos de Francia, los Países Bajos y Finlandia a desconectar sitios web públicos para realizar parches de emergencia.
Esto no fue un ataque coordinado, sino una presión simultánea desde múltiples frentes. Se acumularon informes adicionales:
- El compromiso de la autoridad de certificación de eMudhra, que requirió revocaciones rápidas a nivel de navegador.
- Un error de CVSS 10 en GitLab que data de 2014.
- Una corrección de ejecución remota de código en Node.js.
- Informes de agentes de IA no autorizados apareciendo en cuentas bancarias de EE. UU.
Esta oleada de divulgaciones públicas, aunque intensa, no equivale a una oleada de ataques confirmados. Muchos de estos problemas, incluidos los errores del kernel de Linux detallados por Phoronix, se habían descubierto semanas o meses antes. Las organizaciones simplemente se apresuraban a parchearlos a medida que se hacían de conocimiento público. Varias vulnerabilidades del kernel de Linux publicadas accidentalmente en la lista de correo pública del kernel - Phoronix Este "Black October" sirvió como un crudo adelanto: el cuello de botella ha pasado de encontrar errores a solucionarlos lo suficientemente rápido.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
La IA acelera el descubrimiento; los parches marcan el ritmo
La IA aceleró el descubrimiento de fallas heredadas, pero la aplicación de parches impulsada por humanos sigue siendo obstinadamente lenta. Los mantenedores ahora se enfrentan a una "oleada de parches de vulnerabilidades", ya que herramientas de IA como Mythos de Anthropic descubren cientos de errores críticos en productos como SharePoint, superando ampliamente la capacidad humana. El equipo de Chrome de Google, por ejemplo, ahora envía actualizaciones de seguridad dos veces por semana.
Esto crea una ventana cada vez más pequeña para los defensores. Las correcciones públicas revelan intrínsecamente qué cambió, proporcionando a los atacantes una hoja de ruta para el desarrollo de exploits. Simultáneamente, los defensores obtienen acceso a herramientas de seguridad asistidas por IA, lo que potencialmente nivela el campo de juego una vez que disminuye la inundación inicial de errores fácilmente detectables.
De esta nueva realidad surgen prioridades prácticas. Las organizaciones deben:
- Inventariar todos los sistemas expuestos a Internet
- Actualizar PHP y otro software afectado de inmediato
- Estar atentos a las correcciones del kernel de Linux, verificando si ksmbd está habilitado
- Deshabilitar componentes no utilizados
- Automatizar procesos de parcheo seguro siempre que sea posible
La aplicación de parches debe convertirse en una operación continua, no en una tarea trimestral. El NCSC recomienda una política de "actualización por defecto", priorizando los sistemas expuestos a Internet y reemplazando el software heredado que no se puede parchear.
Preguntas frecuentes
¿Qué sucedió en la filtración de vulnerabilidades del kernel de Linux?
La Zero Day Initiative de Trend Micro envió accidentalmente informes de vulnerabilidades sin parchear a la lista de correo pública del kernel de Linux en lugar de a un canal de seguridad privado.
¿Por qué se consideraron peligrosas las fallas de SMB en Linux?
Las dos fallas reportadas fueron calificadas con CVSS 9.0 y podrían permitir la ejecución remota de código en el código relacionado con SMB que procesa el tráfico de red.
¿Significa la filtración que los sistemas Linux estaban siendo atacados activamente?
No necesariamente. La divulgación hizo públicas las vulnerabilidades, pero el video describe una ola más amplia de divulgaciones de vulnerabilidades en lugar de confirmar ataques que exploten estas fallas específicas.
¿Qué deben hacer los administradores de Linux?
Aplicar las actualizaciones de distribución pertinentes de inmediato, verificar si ksmbd está habilitado y deshabilitar los servicios o componentes expuestos no utilizados mientras esperan las correcciones.