432 CVEs del kernel Linux en 24 horas: qué hacer

Actualizado el 22/07/2026: El conteo final de la ola cerró en 440 CVEs (431 el primer día más 9 al día siguiente) y ya hay identificadores concretos con puntaje asignado, entre ellos CVE-2026-31431 “Copy Fail” (CVSS 7.8) y las “Dirty Frag” CVE-2026-43284/43500, que tienen prueba de concepto pública para escalada a root.

En pocas palabras: Entre el 19 y el 21 de julio de 2026 el feed linux-cve-announce publicó unos 440 CVEs del kernel Linux. No es una brecha ni explotación masiva: desde 2024 el kernel es su propia CNA y numera casi todo parche con implicancia de seguridad. Ahora bien, dentro del lote hay tres o cuatro que sí merecen que muevas la ventana de mantenimiento.

El feed oficial linux-cve-announce publicó más de 430 CVEs del kernel Linux en 24 horas, según el reporte del 21 de julio de 2026 en LowEndTalk. Casi ninguna de esas vulnerabilidades Kernel Linux seguridad implica explotación activa: son identificadores asignados en bloque a parches ya corregidos upstream.

Un CVE (Common Vulnerabilities and Exposures) es un identificador público y único que se le asigna a una falla de seguridad de software para que todo el mundo la nombre igual. Desde 2024 el proyecto del kernel Linux es su propia CNA (autoridad de numeración) y asigna CVE a prácticamente cualquier commit que arregle un problema con potencial de seguridad, sin importar si alguien lo explotó o no. El punto clave para un administrador: el advisory sale después de que el fix existe o está en camino, no antes.

¿Qué son las 440 CVEs de Linux Kernel publicadas en julio de 2026?

Son 440 identificadores de vulnerabilidad publicados entre el 19 y el 20 de julio de 2026 por el equipo del kernel Linux actuando como CNA: 431 el primer día y 9 más al día siguiente. Cada uno corresponde a un commit que ya fue corregido en las ramas estables o cuya corrección estaba en curso al momento del anuncio. No hay un incidente detrás; hay una ronda de stable releases cerrada.

El orden importa y suele malinterpretarse. Primero se escribe el fix, después se numera. Cuando el bot de la CNA cierra una ronda, escupe todos los identificadores juntos y el feed queda con cientos de mensajes en pocas horas. Si tu escáner te abre un ticket por cada CVE, un día así te llena la cola con drivers que no compilás y sistemas de archivos que no montás.

Hay un matiz que conviene tener presente: 440 no es una medición del riesgo, es una medición de la actividad de desarrollo. El kernel mergea miles de commits por ciclo y una fracción alta toca memoria, concurrencia o parsing de datos externos. Ese es exactamente el tipo de código que califica para CVE bajo la política actual. Un mes tranquilo y un mes ruidoso pueden tener el mismo riesgo real para tu servidor. Ya lo cubrimos antes en en sistemas Linux para DevOps.

Tipos de vulnerabilidades publicadas y su alcance real

El grueso del lote son fallas de manejo de memoria y concurrencia que requieren acceso local al sistema: use-after-free, desreferencias de puntero nulo, accesos fuera de límites, condiciones de carrera, fugas de referencias y validación insuficiente de entradas. Poco de eso se explota desde internet sin credenciales. La distinción entre “necesita shell” y “no necesita nada” es la que define tu urgencia real.

• Use-after-free y fugas de referencias. El kernel libera una estructura y alguien la sigue usando. Es la clase más común del lote y la más usada para escalar privilegios, porque permite plantar datos controlados donde el kernel espera un objeto válido. Necesita ejecutar código en la máquina.
• Condiciones de carrera. Dos hilos tocan la misma estructura sin sincronizar bien. Difíciles de disparar de forma confiable, pero un atacante con shell puede reintentar miles de veces sin costo.
• Accesos fuera de límites y validación insuficiente. Acá aparecen los que sí pueden ser remotos: si el dato malformado llega por red (SMB, TCP, Wi-Fi), no hace falta usuario local. Son minoría, pero son los que te obligan a mover la ventana de mantenimiento.
• Desreferencias de puntero nulo. Impacto típico: kernel panic, o sea denegación de servicio. Molesto en un host que sostiene servicios, irrelevante como vector de robo de datos.

Los subsistemas tocados cubren casi todo el árbol: sistemas de archivos (XFS, Btrfs, CIFS/SMB), red (Netfilter, TCP, Wi-Fi), virtualización (KVM), almacenamiento (NVMe, RDMA), Bluetooth, IOMMU y mapeo de DMA. En un servidor headless de hosting, buena parte de esa lista ni siquiera está cargada. Revisá con lsmod qué módulos tenés realmente activos antes de asustarte por un CVE de Bluetooth en una máquina que no tiene radio.

¿Cuáles son las vulnerabilidades más críticas mencionadas?

Tres casos concentran la atención: CVE-2026-31431 (“Copy Fail”), con CVSS 7.8 y escalada de privilegios en el subsistema criptográfico algif_aead; y el par CVE-2026-43284 y CVE-2026-43500, bautizado “Dirty Frag”, que permite obtener root y tiene prueba de concepto pública. El tercero es el que más apura: PoC público significa que la barrera de entrada bajó a copiar y pegar.

CVE	Nombre / subsistema	Impacto	¿Qué necesita el atacante?	Prioridad
CVE-2026-31431	“Copy Fail” — algif_aead (crypto)	Escalada de privilegios (CVSS 7.8)	Acceso local sin privilegios	Alta
CVE-2026-43284 / 43500	“Dirty Frag”	Acceso root, PoC público	Acceso local	Crítica
CVE-2026-64188	Qualcomm RMNET	Use-after-free	Hardware Qualcomm presente	Baja en servidor x86
CVE-2026-64024	Pila TCP	Predicción de ISN	Posición de red	Media si exponés servicios
CVE-2026-53383	Validación SMB	Datos malformados por red	Servicio SMB alcanzable	Alta si exponés SMB
CVE-2026-63801	TIPC	Use-after-free	Módulo TIPC cargado	Baja (casi nadie lo usa)

Sobre “Copy Fail”: el Centro Canadiense de Ciberseguridad emitió el aviso AL26-009 específicamente por CVE-2026-31431, lo cual es señal de que no es un CVE de rutina. Que un CERT nacional le dedique un advisory propio a uno solo de 440 dice bastante sobre cómo priorizar.

El caso de CVE-2026-64024 merece un asterisco. La predicción de números de secuencia iniciales de TCP no te da root ni ejecución de código: te habilita ataques de spoofing o inyección en conexiones existentes, y en la práctica exige una posición de red favorable. Peligroso en redes planas y compartidas, bastante teórico si todo tu tráfico sensible va por TLS. Tomalo con pinzas hasta que se completen las asignaciones de CVSS.

Sobre “Dirty Frag” hay cobertura en medios especializados en español con el detalle de los parches disponibles. Si corrés cargas de terceros o das acceso shell a usuarios que no controlás, este es el que define tu ventana de mantenimiento.

¿Por qué aparecen cientos de vulnerabilidades kernel Linux CVE de golpe?

Porque el kernel Linux asigna CVEs por lote a los commits que entran en las versiones estables, no por descubrimiento individual de un investigador de seguridad. Cuando se cierra una ronda grande de stable releases, el bot del CNA emite todos los identificadores juntos. El número asusta; el mecanismo es contable, no epidemiológico. Complementá con especialmente en pipelines CI/CD.

Esa decisión de política tiene defensores y detractores. A favor: cualquier bug con potencial de seguridad queda trazable y las distros pueden decidir por sí mismas qué backportear. En contra: el ruido, que empuja a los equipos a ignorar el feed entero, que es justo lo contrario de lo que se buscaba.

Algunos medios cubrieron el episodio como una detección “asistida por IA”. Ojo con eso: el feed oficial no publica esa atribución, así que tomalo como reporte de un medio y no como dato confirmado por el proyecto. Lo explicamos a fondo en fundamentos de administración segura de servidores.

¿Qué componentes están afectados además del kernel?

La ola de la semana 29 de 2026 toca infraestructura central de servidor: kernel y kernel-rt, runtimes de contenedores, servidores web, Samba y los intérpretes de lenguaje. Según el roundup de LinuxCompatible, hay correcciones por corrupción de memoria y ejecución remota de código en Python, PHP, Go y Node.js, más bugs de manejo de buffers en OpenSSH y NTFS-3G en Debian LTS y Ubuntu.

Componente	Qué reporta el roundup semana 29	Distros mencionadas	Prioridad
Kernel / kernel-rt	Parches masivos, escalada de privilegios crítica	RHEL, Rocky, AlmaLinux, Oracle	Inmediata
Podman / Buildah	Fixes en runtime de contenedores	Red Hat, Rocky, AlmaLinux	Inmediata
Samba	Falla crítica	Oracle	Alta (si exponés SMB)
OpenSSH y NTFS-3G	Manejo de buffers, riesgo de explotación activa	Debian LTS, Ubuntu	Alta
Python, PHP, Go, Node.js	Corrupción de memoria y RCE	Transversal	Alta en hosting web
Chromium	Riesgo “important” de navegador	openSUSE	Baja en servidor

Fijate el patrón: lo que más duele en un servidor no es el kernel en abstracto, es la combinación de kernel más runtime de contenedores. Si corrés cargas multi-tenant en Podman sobre un kernel sin parchear, una escalada local deja de ser “local”.

¿Afecta esto a mi servidor Linux? Cómo evaluar el riesgo

Evaluá en cuatro pasos y en este orden: versión del kernel, módulos cargados, exposición de red y advisories de tu distribución. No compares contra la lista de 440 CVEs. Compará contra lo que tu distro marca como pendiente de seguridad, porque el vendor ya decidió qué aplica a tu kernel empaquetado y qué no.

• Paso 1 — Versión real del kernel. uname -r te dice qué estás corriendo ahora, no qué instalaste. Contrastalo con el paquete instalado; si no coinciden, parcheaste y no rebooteaste. En Debian y Ubuntu, el archivo /var/run/reboot-required te lo canta.
• Paso 2 — Qué subsistemas usás de verdad. lsmod lista los módulos cargados. Buscá específicamente ksmbd, tipc, kvm (con SEV si es AMD), bluetooth y los drivers de Wi-Fi. Si TIPC no está cargado, CVE-2026-63801 no es tu problema y podés bajarlo de la lista sin culpa.
• Paso 3 — Exposición y multi-tenencia. Un host que da shell a usuarios que no controlás está en el peor cuadrante para “Dirty Frag” y “Copy Fail”. Un VPS de un solo dueño, con SSH por clave y sin usuarios locales, convierte casi todo el lote en deuda técnica y no en emergencia.
• Paso 4 — Advisories de tu distro. dnf updateinfo list security en RHEL, Rocky y AlmaLinux; apt list --upgradable en Debian y Ubuntu. Ahí ves el ID del advisory, que es la unidad de trabajo real. Para rastrear un CVE puntual, OpenCVE tiene el listado filtrable por producto y vendor.

Ninguna de estas herramientas te dice si el CVE es explotable en tu caso: te dice si tenés el paquete viejo. La explotabilidad depende de qué módulos cargás, qué expone tu firewall y quién tiene shell. Para más detalles técnicos, mirá automatizar la aplicación de parches críticos.

Cómo parchear el kernel de Linux correctamente

La vía correcta es el gestor de paquetes de tu distribución, con testing previo en un entorno que no sea producción y un plan de rollback armado antes de tocar nada. El kernel es el único componente de esta ola que exige reinicio, salvo que uses live patching. Todo lo demás (Podman, PHP, Node.js, OpenSSH, Samba) se resuelve actualizando el paquete y reiniciando el servicio, con segundos de corte en vez de minutos. Cubrimos ese tema en detalle en si usás Jenkins o GitHub Actions.

• Package manager, siempre primero. apt upgrade o dnf update traen el kernel con los backports que tu vendor ya validó contra su matriz de hardware. Compilar a mano por apuro te saca del canal de backports y perdés el soporte de seguridad del vendor.
• Live patching para ganar tiempo. kpatch en el ecosistema Red Hat, el servicio de livepatch en Ubuntu, y kernel live patching en Amazon Linux 2, documentado por AWS. Aplican correcciones al kernel en memoria sin reboot. Cubren una parte de los fixes, no todos: tarde o temprano vas a rebootear igual.
• Staging antes que producción. Clonás el VPS, actualizás ahí, verificás que levanta. El caso típico donde esto salva: módulos de kernel de terceros compilados a mano, drivers de storage propietarios, o cualquier cosa con DKMS. Ahí es donde un update rompe.
• Rollback listo antes de empezar. Snapshot previo y GRUB con la entrada del kernel anterior disponible. Si el nuevo no bootea, elegís la vieja en el menú y seguís vivo. Sin eso, un kernel que no arranca en un servidor remoto es una visita al panel de rescate.
• Reinicio de servicios en vez de reboot. needrestart te dice qué procesos siguen usando bibliotecas viejas después de un update. Reiniciás php-fpm y listo, sin tocar el host.

¿Y si no podés rebootear esta semana? Mitigá superficie: cerrá SMB al mundo si el fix de Samba te aplica, limitá quién tiene acceso shell (la mayoría de las escaladas del kernel necesitan un usuario local) y descargá los módulos que no usás. Es un puente, no una solución.

Monitoreo y verificación de sistemas parcheados

Verificar es comparar tres cosas: el kernel que corre (uname -r), el paquete instalado y el advisory de tu distro que decía cubrir esos CVEs. Si las tres coinciden, terminaste. La trampa clásica es dar por cerrada la tarea cuando el gestor de paquetes dice “done” y el sistema sigue arrancado con el binario viejo en memoria.

• Alertas automáticas del vendor. Suscribite a los advisories de tu distribución (Canonical, Red Hat, Debian Security). Llegan filtrados por lo que realmente empaquetan, que es una fracción chica de las 440.
• El feed upstream, para contexto y no para tickets. La lista linux-cve-announce te sirve para entender qué pasó, no para armar tu backlog. Si la usás como fuente de tareas, un día como el 19 de julio te rompe el proceso.
• Escáneres de CVE. OpenCVE y cvedetails.com permiten seguir un identificador puntual y ver cuándo se completa la asignación de CVSS. Útil sobre todo con los CVE recién publicados, que muchas veces salen sin puntaje y lo reciben días después.
• Auditoría de configuración. Lynis para higiene general. No reemplaza el parcheo, pero encuentra la otra mitad del problema: servicios innecesarios, permisos flojos, módulos cargados sin motivo.

¿Qué cambia en hosting compartido y entornos multi-tenant?

En multi-tenant, una escalada de privilegios del kernel es el peor escenario posible, porque rompe el aislamiento entre cuentas que comparten el mismo host. Un usuario con acceso limitado que llega a root sale de su jaula y ve el resto. Con “Dirty Frag” y su PoC público circulando, ese riesgo dejó de ser teórico esta semana.

Acá la repartija de responsabilidades importa. En hosting administrado, el kernel del host lo parchea el proveedor y vos te ocupás de tu stack (PHP, Node, WordPress, plugins). En un VPS no administrado, el kernel es tuyo, entero, con reboot incluido. Si estás evaluando dónde parás tus proyectos en Argentina, donweb.com maneja el parcheo del host en sus planes administrados, que es exactamente el trabajo que semanas como esta te sacan de encima.

Plan de respuesta: qué hacer en 48 horas y qué en 7 días

Priorizá por exposición y por privilegio, no por cantidad. Primero lo que un atacante remoto toca sin credenciales, después lo que necesita un usuario local, al final lo que ni siquiera corre en tu servidor. Ya lo cubrimos antes en orquestar despliegues de actualizaciones de emergencia.

• Primeras 48 horas: kernel y kernel-rt en hosts multi-tenant o con shells de terceros (por “Dirty Frag” y “Copy Fail”), OpenSSH, Samba si tenés SMB expuesto, y Podman/Buildah si corrés contenedores.
• Dentro de la semana: runtimes de PHP, Python, Go y Node.js, más el servidor web. Reinicio de servicio, no de máquina.
• Cuando puedas: NTFS-3G, Chromium y todo lo que en un servidor headless no tiene ni sentido tener instalado (aprovechá y desinstalalo).
• Post-parche: verificá con uname -r que estás corriendo lo que creés que estás corriendo, y revisá logs de autenticación las 72 horas siguientes.

Qué está confirmado y qué no

Confirmado: la publicación de unos 440 CVEs del kernel entre el 19 y el 21 de julio de 2026 en el feed linux-cve-announce (431 el primer día, 9 al siguiente). La existencia de CVE-2026-31431 “Copy Fail” con CVSS 7.8 y advisory propio del Centro Canadiense de Ciberseguridad. Que “Dirty Frag” (CVE-2026-43284 y CVE-2026-43500) tiene prueba de concepto pública. La ola de advisories de la semana 29 sobre kernel, Podman, Buildah, Samba, OpenSSH, NTFS-3G, Chromium y los runtimes de Python, PHP, Go y Node.js.

No confirmado: que la detección haya sido en gran medida asistida por IA, que aparece en la cobertura de algunos medios pero no en el anuncio oficial. Tampoco hay evidencia pública de explotación masiva en el mundo real de estos CVEs específicos, ni un desglose oficial de cuántos de los 440 son críticos: muchos siguen sin puntaje CVSS asignado. Te puede servir nuestra cobertura de comparativa de seguridad entre plataformas.

Para más detalles sobre esto, mirá nuestro análisis de la oleada masiva de CVEs Linux.

Para profundizar en el tema, echá un vistazo a nuestro reporte sobre CVEs kernel masivas.

Errores comunes al actualizar el kernel de Linux

• Tratar los 440 CVEs como 440 tareas. Tu distro consolida todo en unos pocos advisories de paquete. Trabajá contra dnf updateinfo list security o el equivalente en apt, no contra el feed upstream.
• Confundir el número de CVE con su gravedad. El identificador no dice nada del impacto. Un CVE-2026-6xxxx puede ser un panic irrelevante y otro con número más bajo puede darte root. El puntaje CVSS y el vector son lo que manda, y en este lote muchos todavía no lo tienen.
• Asumir que las 440 son remotamente explotables. La mayoría necesita acceso local. Si tratás todo como emergencia remota, quemás la ventana de mantenimiento en lo que no la merecía y llegás tarde a “Dirty Frag”.
• Parchear y no rebootear. El error más frecuente y el más silencioso: instalás el kernel nuevo, el servidor sigue corriendo el viejo durante meses y tu dashboard dice verde. uname -r no miente.
• No leer el changelog de la distro antes de actualizar. Si tenés drivers custom, módulos DKMS o storage propietario, el changelog es donde aparece la nota que te avisa qué se rompe. Leerlo cuesta cinco minutos; el rollback a las tres de la mañana, bastante más.
• Reboot masivo de toda la flota al mismo tiempo. Escaloná por grupos, verificá que el primero levantó bien y recién ahí seguí con el resto.

Preguntas Frecuentes

¿Qué es CVE-2026-31431 “Copy Fail”?

Es una vulnerabilidad de escalada de privilegios en el subsistema criptográfico algif_aead del kernel Linux, con puntaje CVSS 7.8. Permite que un usuario local sin privilegios eleve sus permisos en el sistema. El Centro Canadiense de Ciberseguridad le dedicó el advisory AL26-009, algo poco habitual para un CVE individual dentro de un lote grande.

¿Qué es “Dirty Frag” y por qué es urgente?

“Dirty Frag” agrupa a CVE-2026-43284 y CVE-2026-43500, dos fallas del kernel que permiten obtener acceso root y que ya tienen prueba de concepto pública. La urgencia viene de ahí: con el PoC circulando, explotarla no requiere desarrollar nada. Es prioritaria en cualquier host que dé acceso shell a usuarios que no controlás.

¿Cuántas de las 440 CVEs son remotamente explotables?

No hay un desglose oficial, pero la gran mayoría requiere acceso local: use-after-free, condiciones de carrera y desreferencias de puntero nulo necesitan ejecutar código en la máquina. Las remotas se concentran en subsistemas que procesan datos de red, como SMB, TCP y Wi-Fi. Priorizá esas si exponés esos servicios.

¿Hace falta reiniciar el servidor para aplicar un parche de kernel?

Sí, salvo que uses live patching (kpatch en Red Hat, livepatch en Ubuntu, kernel live patching en Amazon Linux 2), que aplica correcciones al kernel en memoria sin reboot. El live patching cubre una parte de los fixes, así que tarde o temprano vas a necesitar una ventana de mantenimiento igual.

¿Por qué el kernel Linux emite tantos CVEs?

Porque el proyecto es su propia CNA desde 2024 y asigna identificadores a casi cualquier commit que corrija un problema con implicancia de seguridad, aunque nadie lo haya explotado. El resultado es un volumen alto y publicaciones en lote cuando se cierra una ronda de versiones estables. En documentar alertas de seguridad en múltiples regiones profundizamos sobre esto.

¿Qué herramientas gratuitas sirven para monitorear CVEs en Linux?

unattended-upgrades y apt list --upgradable en Debian y Ubuntu, dnf updateinfo list security en RHEL, Rocky y AlmaLinux, needrestart para detectar servicios con bibliotecas viejas cargadas, OpenCVE para seguir identificadores puntuales y Lynis para auditoría de configuración. Todas son open source o de acceso libre.

Conclusión

El conteo cerró en 440 CVEs y eso sigue siendo un número de contabilidad, no un evento de seguridad. Lo que cambió respecto de los primeros reportes es que ya hay nombres propios con impacto verificado: “Copy Fail” con CVSS 7.8 y advisory de un CERT nacional, y “Dirty Frag” con acceso root y PoC público. Ahí está la diferencia entre leer el titular y leer el detalle.

El trabajo real es más chico y más aburrido que el titular: corré el listado de seguridad de tu distro, priorizá los dos o tres con exploit conocido si das acceso shell a terceros, actualizá kernel y runtimes de contenedores, reiniciá servicios donde alcance y agendá el reboot donde no. De acá en adelante, seguí dos cosas: si aparece explotación in-the-wild de “Dirty Frag” y qué puntajes CVSS se asignan a los CVEs que todavía salieron sin calificar. Si tenés hosting administrado, buena parte de eso ya lo hizo otro. Si tenés un VPS propio, ese otro sos vos.

¿Tengo que parchear todas las 440 CVEs?

No. La mayoría requieren acceso local al sistema. Solo 3-4 merecen que muevas tu ventana de mantenimiento: CVE-2026-31431 (Copy Fail, CVSS 7.8), CVE-2026-43284/43500 (Dirty Frag con PoC público) y CVE-2026-53383 si exponés SMB. El resto depende de qué módulos del kernel tenés activos.

¿Cómo sé si una CVE me afecta a mi servidor?

Ejecutá lsmod para listar los módulos cargados, luego cotejá con el subsistema de cada CVE en la tabla. Si el módulo no está activo, es irrelevante para tu servidor. Lo urgente primero: kernel estable más kernel-rt, después Podman y Buildah si usás contenedores, después runtimes y servicios web.

¿Ya hay parches disponibles para Dirty Frag?

Sí, ya están en las ramas estables del kernel. Consultá el changelog oficial de tu distribución o linux-cve-announce para confirmar la versión donde aplica el parche. Si estás en una rama LTS (Ubuntu, Debian), puede haber un lag de días entre la corrección upstream y el paquete del repositorio.

¿Son 432 o 440 las CVEs del kernel Linux?

Ambas cifras son correctas: 432 fue el conteo inicial difundido en las primeras 24 horas según el reporte de LowEndTalk, y 440 el total al cierre de la ola (431 el primer día más 9 al siguiente, según GBHackers). El artículo conserva el 432 porque fue el dato del primer reporte.

¿Tenés que reiniciar el servidor para aplicar los parches del kernel?

Sí: los parches de kernel recién quedan activos después de un reinicio, salvo que uses alguna solución de livepatching. Programá la ventana para actualizar kernel y kernel-rt primero, y aprovechá el mismo reinicio para sumar Podman, Buildah y el resto de los paquetes de la ola.

¿Cómo filtro qué CVEs de la ola aplican a mi servidor?

Listá tus módulos activos con lsmod y descartá lo que toque subsistemas que no usás, como Bluetooth o TIPC en un servidor headless. Priorizá después los tres identificadores críticos: CVE-2026-31431 (Copy Fail) y el par Dirty Frag CVE-2026-43284 y CVE-2026-43500.

Fuentes

• linux-cve-announce — Feed oficial de anuncios de CVE del kernel Linux
• GBHackers — El equipo del kernel Linux publica 440 advisories de seguridad
• CyberSecurityNews — Linux parchea más de 400 vulnerabilidades del kernel
• Centro Canadiense de Ciberseguridad — Aviso AL26-009 sobre CVE-2026-31431
• AWS — Kernel live patching en Amazon Linux 2
• OpenCVE — Listado de CVEs del kernel Linux filtrable
• LinuxCompatible — Linux Security Roundup semana 29 de 2026