432 CVE del kernel de Linux publicados en las últimas 24 horas

• Según el título en Hacker News, en las últimas 24 horas se publicaron 432 CVE del kernel de Linux, pero actualmente no es posible verificar el contenido individual en la página de anuncio
• La página de anuncio aplica el procedimiento anti-bots Anubis para evitar caídas del servidor y restricciones de acceso a recursos causadas por la recolección web a gran escala
• Con una prueba de trabajo (Proof-of-Work) de la familia Hashcash, mantiene baja la carga para el acceso normal mientras eleva el costo acumulado de la recolección masiva
• Este método es una solución temporal hasta que exista una tecnología para identificar navegadores sin interfaz gráfica
• Se requieren funciones modernas de JavaScript, y plugins como JShelter que las bloquean deben desactivarse en ese dominio para poder acceder

---

Estado actual de la página de anuncio de CVE

• El título en Hacker News indica que en las últimas 24 horas se publicaron 432 CVE del kernel de Linux, pero en la página proporcionada no hay una lista de CVE ni detalles individuales
• En su lugar, solo se muestra una pantalla de cálculo de prueba de trabajo de nivel 4

Cómo funciona Anubis y sus limitaciones

• La prueba de trabajo de la familia Hashcash impone una carga de cálculo despreciable para cada acceso individual, pero genera un costo acumulado para la recolección a gran escala
• A futuro, el objetivo es identificar por huella digital a los navegadores sin interfaz gráfica mediante aspectos como el renderizado de fuentes, para no mostrar la página de prueba de trabajo a los usuarios legítimos
• Las funciones modernas de JavaScript que exige Anubis pueden ser bloqueadas por JShelter y herramientas similares, por lo que es necesario desactivar ese plugin para poder acceder

[GN⁺]

Opiniones en Lobste.rs

• Un CVE no es la vulnerabilidad en sí, sino un identificador, y puede asignarse cuando efectivamente se descubre una vulnerabilidad

  • Entendí tarde la intención; parece que querían decir que el título debería haber sido 432 vulnerabilidades del kernel de Linux

• El proyecto del kernel de Linux ha dicho varias veces que considera la mayoría de los bugs como candidatos a CVE, salvo correcciones de rendimiento, arreglos de bugs de hardware, corrupción de sistemas de archivos, etc.

  http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

  http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

  • El equipo de seguridad del kernel no puede saber dónde ni cómo se usa el kernel, y esto también es una consecuencia particular de que el kernel de Linux se haya convertido en su propia autoridad de numeración CVE (CNA).
    El sistema CVE fue creado originalmente para productos, por lo que no encaja tan bien con un kernel de sistema operativo que se usa como componente de muchos productos. Idealmente, CachyOS, el fabricante de una cámara con kernel integrado y Red Hat deberían evaluar de forma independiente si el mismo bug es candidato a CVE en sus respectivos entornos.
    Pero si se hiciera así, podrían aparecer CVE separados para 300 modelos de cámaras, 300 routers/servidores de archivos que se comportan de forma extraña al insertar un USB y decenas de consolas retro de emulación de juegos que usan tarjetas SD; por eso, aunque estructuralmente sea incómodo, para todo el ecosistema es mejor gestionarlo a nivel de componente.
  • Los bugs de corrupción del sistema de archivos también pueden considerarse candidatos a CVE

• Me pregunto si entre ellos hay alguna vulnerabilidad especialmente interesante

• Muchas entradas empiezan con la frase “En el kernel de Linux se resolvió la siguiente vulnerabilidad”

• No pude resistirme y le pedí a un LLM que inventara nombres llamativos para cada CVE
  https://git.infradead.org/~rw/cvenames-2026-07-19.html

• Si se mira el primer elemento relacionado con XFS, dice que el problema solo ocurre con logs manipulados.
  Para explotarlo en la práctica, parece que habría que desconectar el sistema de archivos y escribir directamente en el dispositivo de bloques donde está guardado el log; si es así, parecería hacer falta acceso root o acceso físico, además de la capacidad de apagar el sistema. Me pregunto si estoy entendiendo mal el log de XFS.

  • Puede que no sea una amenaza para servidores que no montan automáticamente unidades USB o tarjetas SD y que además tienen vigilancia física, pero sí podría afectar a otros entornos Linux.
    Por ejemplo, alguien podría entregarte una tarjeta SD diciendo que contiene “fotos”, pero en realidad incluir un sistema de archivos XFS malicioso, y al conectarla en casa podría ejecutarse una cadena de exploits. Montar un sistema de archivos debería ser una operación segura, igual que abrir un archivo de imagen.
  • Que sea poco probable no significa que no sea una vulnerabilidad potencial, y el entorno de uso también importa.
    Puede haber dispositivos tipo kiosco que monten automáticamente cualquier almacenamiento conectado, y problemas que normalmente parecen poco realistas pueden convertirse en ataques viables cuando se combinan varias fallas o un entorno específico.
  • Creo que un ataque conectando un USB o HDD a un servidor en una instalación de hosting de colocation tendría una tasa de éxito de alrededor del 95%.
    Aunque quedara grabado por una cámara, sería difícil verificar con claridad que no se está conectando a otro servidor del mismo rack.