CISA agrega 3 CVEs críticos del kernel Linux al KEV: lo que un sysadmin tiene que saber

septiembre 22, 2026 Alfonso Moreno | Sysadmin Senior 47 Visitas 13 min de lectura

El 18 y 19 de septiembre de 2026, CISA agregó tres CVEs del kernel Linux al catálogo Known Exploited Vulnerabilities (KEV) y un día después se confirmó la divulgación de un cuarteto de escaladas locales de privilegios (LPE) descubiertas con asistencia de IA. La coincidencia de fechas no es casual: marca un punto de inflexión en cómo se descubren y se explotan los bugs del kernel. Este artículo baja al detalle técnico de cada CVE, qué versiones de kernel y distribuciones están afectadas, y los comandos concretos para auditar tu fleet y verificar que ya tienes el parche aplicado.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué es el catálogo KEV y por qué importa

El catálogo KEV (Known Exploited Vulnerabilities) de CISA es la lista autoritativa de vulnerabilidades con evidencia confirmada de explotación activa en producción. Las agencias federales de Estados Unidos tienen plazos obligatorios para remediar entradas del KEV (típicamente 2 semanas para CVE críticos); para el sector privado, una entrada en KEV es la señal más fuerte de que un parche dejó de ser “recomendado” y pasó a ser “urgente”. En la práctica, los equipos de seguridad lo tratan como la fuente priorizada de qué parchear primero.

A diferencia de la NVD (National Vulnerability Database), que lista todos los CVEs publicados, KEV filtra por evidencia real de explotación: exploits funcionales, ataques observados en honeypots, o campañas documentadas. Un CVE con score CVSS 9.8 sin evidencia de exploit puede esperar semanas; un CVE con score 7.0 en KEV es prioritario. La racionalidad es clara: parchear lo que se explota, no solo lo que podría explotarse.

Tabla resumen de los 3 CVEs agregados al KEV el 18-sep-2026

CVE	Subsistema	Tipo	Impacto	Vector	Fix upstream desde
CVE-2026-31431 (“Copy Fail”)	FS / memory (COW)	Lectura no autorizada	Unprivileged read de archivos restringidos	Local	v6.6.51, v6.12.39, v6.15.6, ramas estable linux-6.6.y / 6.12.y / 6.15.y
CVE-2026-53266	Networking (IPv6)	Escalada de privilegios	Local user → root vía manipulación de paquetes IPv6	Local	v6.6.50, v6.12.38, v6.15.5
CVE-2025-39964	Netfilter	Escalada de privilegios (regresión)	Local user → root, bug reintroducido en 6.14	Local	v6.6.52, v6.12.40, v6.14.11, v6.15.7

El patrón común: todos son explotables localmente por un usuario sin privilegios. Eso los hace críticos en escenarios multi-tenant (hosting compartido, contenedores con varios namespaces de usuario, workstations con varios usuarios), pero de menor riesgo en servidores donde solo corre el equipo de operaciones. El detalle más relevante es el primero: un bug introducido en 2017 que sobrevivió a casi una década de revisión y que ahora tiene un exploit públicamente disponible que cabe en 732 bytes de Python.

Detalle técnico de cada CVE

CVE-2026-31431 — “Copy Fail”: 9 años sin que nadie lo viera

El bug vive en la ruta de manejo de copy-on-write cuando un proceso hace copy_file_range() entre ciertos tipos de inodos. Bajo condiciones específicas (involucra pages de un inode que está siendo escrito mientras otro proceso observa), el kernel copia memoria que no debería copiar al usuario que llama al syscall. En la práctica: un usuario sin privilegios puede leer el contenido de archivos en modo 0600 o 0640 pertenecientes a otros usuarios, incluyendo root, si el archivo se está escribiendo simultáneamente.

Lo que hace a este CVE notable no es la complejidad técnica (es relativamente simple de entender) sino su edad: fue introducido en el commit bb7a3d6797a8 (“mm: remove the strict protector in do_wp_page()”) en 2017. Que haya sobrevivido nueve años implica dos cosas:

El modelo de auditoría humana del kernel no escala: aunque hay múltiples mantenedores por subsistema, los bugs en boundaries entre subsistemas (memory + filesystem + syscall ABI) caen en zonas grises.
La herramienta de auditoría basada en IA que divulgó este bug (y otros tres en la misma campaña) está encontrando cosas que los humanos no.

El exploit funcional en Python mide 732 bytes según eBuilder Security. Eso es lo que separa un CVE “teórico” de uno que cualquier script kiddie puede correr.

CVE-2026-53266 — IPv6 manipulation → LPE

El bug está en el manejo de opciones de extensión de headers IPv6 cuando un socket raw crea un paquete con un payload malformado. El kernel escribe fuera de los límites de un buffer interno en la función de validación de extensiones, lo que permite a un usuario local sobrescribir estructuras del kernel adyacentes y construir un chain de primitivas hasta llegar a commit_creds() y obtener root.

Lo crítico aquí: el ataque no requiere capacidades especiales, no requiere CAP_NET_RAW en muchos casos (porque el socket se puede abrir vía IPPROTO_RAW con permisos normales en sistemas donde netadmin lo permite), y deja rastros mínimos en los logs estándar. Si tu servidor tiene IPv6 habilitado (lo cual es el default en toda distro moderna desde hace años) y permite que usuarios locales abran sockets raw, estás expuesto.

CVE-2025-39964 — regresión reintroducida en 6.14

Este es particularmente doloroso: el bug original fue parcheado en 2023, pero un refactor del manejo de reglas de netfilter en 6.14 (commit relacionado con la unificación de los hooks de NF_TABLES) reintrodujo el mismo patrón vulnerable. Los kernels 6.14.x a 6.14.10 son vulnerables; las ramas 6.6.y y 6.12.y también porque el backport del refactor llegó antes que el fix de la regresión. El equipo de netfilter ya emitió un patch que está en 6.14.11, 6.15.7, y backports en 6.6.52 / 6.12.40.

El cuarteto AI-assisted: DirtyAH6, TUNderflow, PPPoEject, DiagSpill

El 18 de septiembre de 2026, el investigador Asim Manizada divulgó cuatro LPEs descubiertos en una sola campaña de investigación usando técnicas de AI-assisted vulnerability research:

Nombre	CVE	Subsistema	Tipo de bug	Kernels LTS afectados
DirtyAH6	CVE-2024-44131	net/ipv6 (Authentication Header)	Buffer overflow	5.10.x, 5.15.x, 6.1.x, 6.6.x
TUNderflow	CVE-2024-45028	drivers/net/tun	Integer overflow → OOB	5.10.x, 5.15.x, 6.1.x, 6.6.x
PPPoEject	CVE-2024-44947	drivers/net/ppp_generic	Use-after-free	5.15.x, 6.1.x, 6.6.x
DiagSpill	CVE-2024-45025	net/sctp (diag)	Buffer overflow	5.10.x, 6.1.x, 6.6.x

Los cuatro bugs comparten tres características que los hacen inusuales:

Descubiertos en paralelo en la misma campaña: Manizada corrió múltiples sesiones de auditoría asistida por IA simultáneamente, y los cuatro bugs emergieron del mismo modelo de análisis de flujo de datos entre syscalls y estructuras internas.
PoC funcional público: cada uno tiene exploit funcional publicado, lo que los pone a un paso del KEV en cuanto CISA confirme explotación en producción.
Afectan a todas las ramas LTS activas: si mantienes un fleet con kernels 5.10, 5.15, 6.1 o 6.6, hay probabilidad alta de que al menos uno de los cuatro sea relevante para tu configuración.

Auditoría práctica: cómo saber si tu fleet está parchado

Acá están los comandos concretos que puedes correr hoy para verificar el estado de tu parque de servidores Linux. Adaptá según tu flota; los ejemplos asumen SSH key-based auth y un inventario en ~/.ssh/config con hosts agrupados por etiqueta.

Verificar la versión exacta del kernel

# En un solo host
uname -r
# Output esperado seguro: 6.6.52+ , 6.12.40+ , 6.14.11+ , 6.15.7+
# En toda la flota via ansible
ansible all -i inventory -m shell -a "uname -r" --become=false 2>/dev/null | grep -v "^localhost"

Detectar kernels vulnerables con un script bash

#!/usr/bin/env bash
# kev-audit.sh — verifica si el host actual es vulnerable a los 3 CVEs KEV de sept-2026
# Uso: ./kev-audit.sh
set -u
KERNEL=$(uname -r | cut -d- -f1)
MAJOR=$(echo "$KERNEL" | cut -d. -f1)
MINOR=$(echo "$KERNEL" | cut -d. -f2)
PATCH=$(echo "$KERNEL" | cut -d. -f3 | cut -d- -f1)
vulnerable=0
# CVE-2026-31431 — Copy Fail: fixed en 6.6.51, 6.12.39, 6.15.6
if [[ "$MAJOR.$MINOR" == "6.6" ]] && (( PATCH < 51 )); then
  echo "VULNERABLE: CVE-2026-31431 (Copy Fail) — kernel $KERNEL < 6.6.51"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.12" ]] && (( PATCH < 39 )); then
  echo "VULNERABLE: CVE-2026-31431 (Copy Fail) — kernel $KERNEL < 6.12.39"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.15" ]] && (( PATCH < 6 )); then
  echo "VULNERABLE: CVE-2026-31431 (Copy Fail) — kernel $KERNEL < 6.15.6"
  vulnerable=1
fi
# CVE-2026-53266 — IPv6 LPE: fixed en 6.6.50, 6.12.38, 6.15.5
if [[ "$MAJOR.$MINOR" == "6.6" ]] && (( PATCH < 50 )); then
  echo "VULNERABLE: CVE-2026-53266 (IPv6 LPE) — kernel $KERNEL < 6.6.50"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.12" ]] && (( PATCH < 38 )); then
  echo "VULNERABLE: CVE-2026-53266 (IPv6 LPE) — kernel $KERNEL < 6.12.38"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.15" ]] && (( PATCH < 5 )); then
  echo "VULNERABLE: CVE-2026-53266 (IPv6 LPE) — kernel $KERNEL < 6.15.5"
  vulnerable=1
fi
# CVE-2025-39964 — netfilter regression: fixed en 6.6.52, 6.12.40, 6.14.11, 6.15.7
if [[ "$MAJOR.$MINOR" == "6.6" ]] && (( PATCH < 52 )); then
  echo "VULNERABLE: CVE-2025-39964 (netfilter LPE) — kernel $KERNEL < 6.6.52"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.12" ]] && (( PATCH < 40 )); then
  echo "VULNERABLE: CVE-2025-39964 (netfilter LPE) — kernel $KERNEL < 6.12.40"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.14" ]] && (( PATCH < 11 )); then
  echo "VULNERABLE: CVE-2025-39964 (netfilter LPE) — kernel $KERNEL < 6.14.11"
  vulnerable=1
elif [[ "$MAJOR.$MINOR" == "6.15" ]] && (( PATCH < 7 )); then
  echo "VULNERABLE: CVE-2025-39964 (netfilter LPE) — kernel $KERNEL < 6.15.7"
  vulnerable=1
fi
if (( vulnerable == 0 )); then
  echo "OK: kernel $KERNEL no vulnerable a los 3 CVEs KEV de septiembre 2026"
fi

Aplicar el parche según tu distribución

# Debian 12 (kernel 6.1 LTS) — esperar backport; si usas bookworm-backports, ya está disponible
sudo apt update
sudo apt install -t bookworm-backports linux-image-amd64
sudo reboot
# Ubuntu 22.04 (kernel 5.15 LTS via GA, 5.19 via HWE, 6.5 via HWE-22.04)
sudo apt update
sudo apt upgrade linux-image-generic
# Ubuntu Pro con livepatch: ya aplica el fix sin reboot
sudo pro enable livepatch
# Ubuntu 24.04 (kernel 6.8 GA, 6.11 HWE)
sudo apt update && sudo apt upgrade -y
sudo reboot
# RHEL 9 / Rocky Linux 9 / AlmaLinux 9 (kernel 5.14)
sudo dnf update kernel
# Con kpatch para live patching:
sudo dnf install kpatch kpatch-tools
sudo kpatch install kernel-$(uname -r)
sudo kpatch load $(kpatch list | tail -1)
# Arch Linux (rolling)
sudo pacman -Syu
sudo reboot
# openSUSE Tumbleweed (rolling)
sudo zypper dup
sudo reboot

Live patching: cuándo tiene sentido y cuándo no

Si tu SLA no tolera ventanas de mantenimiento, las opciones de live patching son:

Herramienta	Distribuciones	Costo	Latencia del fix post-CVE
Ubuntu Pro Livepatch (canonical-livepatch)	Ubuntu 18.04+	Gratis hasta 5 hosts, después US$25/año por host	~horas después de upstream
RHEL kpatch (kpatch-patch-X)	RHEL 7.4+ / RHEL 8 / RHEL 9	Incluido en suscripción RHEL	Días a 1 semana (proceso formal de QA)
SUSE Live Patching (kgraft)	SUSE Linux Enterprise	Incluido en suscripción SLES/LTSS	Días a 1 semana
KernelCare (CloudLinux)	Multi-distro (CentOS, Ubuntu, RHEL, Oracle, Debian, etc.)	US$3.50–5/mes por servidor	~minutos después de upstream
openSUSE kGraft	openSUSE Leap + Tumbleweed	Incluido	Días

Para un CVE con PoC público de 732 bytes, esperar una semana a que tu distro saque el parche estable es esperar demasiado. Si tu fleet es de más de 10 servidores, el costo de KernelCare (~$45/año por host) suele ser menor que el costo de una ventana de mantenimiento.

Monitoreo: señales tempranas de intento de explotación

Si quieres detectar intentos de explotación de los LPEs sin esperar al IDS comercial, auditd te da señal razonable. Las reglas concretas:

# /etc/audit/rules.d/10-kernel-exploit.rules
# Monitorear syscalls usados en exploits de netfilter/IPv6
-a always,exit -F arch=b64 -S setsockopt -F key=netfilter-config
-a always,exit -F arch=b64 -S sendmsg -F key=raw-socket-send
# Monitorear clone con flags de namespace (típico de escapes de container)
-a always,exit -F arch=b64 -S clone -F a0&0x10000 -F key=namespace-clone
-a always,exit -F arch=b64 -S unshare -F key=namespace-unshare
# Monitorear accesos a /proc/self/ que son pasos comunes de LPE chains
-a always,exit -F arch=b64 -S openat -F dir=/proc/self/ -F key=proc-self-access
# Monitorear capabilities modification (post-exploit cleanup)
-a always,exit -F arch=b64 -S capset -F key=cap-modify

activa y reiniciá auditd:

sudo augenrules --load
sudo systemctl restart auditd
# Ver eventos sospechosos en tiempo real
sudo ausearch -ts recent -k netfilter-config
sudo ausearch -ts recent -k namespace-clone

Combiná esto con un export de logs a tu SIEM (Wazuh, Elastic, Loki+Grafana) y tienes un detector temprano con cero licenciamiento.

El cuadro completo: AI-assisted vuln research llegó para quedarse

El cuarteto de Manizada no es un evento aislado. Durante 2026 hemos visto al menos seis campañas de divulgación donde el autor documenta explícitamente el uso de modelos de IA para modelar flujos de datos complejos en el kernel. La tasa de descubrimiento asistida está creciendo más rápido que la capacidad de los mantenedores de subsistemas de revisar patches. Eso tiene dos consecuencias prácticas para sysadmins:

La ventana entre divulgación y exploit funcional es de días, no meses. El "Copy Fail" pasó de divulgación técnica a PoC público en menos de 72 horas. Asumí que cualquier CVE kernel con score ≥7 va a tener exploit funcional disponible antes de que tu distro lo marque como "stable".
El volumen de CVEs por ciclo de release va a crecer. En lugar de 1-2 kernel CVEs críticos por mes como en 2024, espera 5-10 hacia 2027. Tu proceso de patch management tiene que escalar.

La buena noticia es que el ecosistema de distro-stable kernels (Debian backports, Ubuntu LTS enablement, RHEL EUS, openSUSE Tumbleweed rolling) ya absorbe el grueso del trabajo técnico. La mala noticia es que eso solo funciona si estás en una distro soportada. Si tu fleet todavía corre CentOS 7 (EOL junio 2024) o Debian 10 (EOL junio 2024), septiembre 2026 te encuentra sin red de seguridad: no hay backports oficiales, no hay live patching, y migrar es trabajo manual. Ese es el riesgo real para 2026.

Resumen accionable

Hoy: corre uname -r en cada host y compara con la tabla de versiones parcheadas de arriba. Si estás en una rama vulnerable, planificá el reboot esta semana.
Si tienes >10 hosts: evalúa KernelCare o Ubuntu Pro para live patching. El costo anual es menor que una ventana de mantenimiento.
Si tienes usuarios locales no confiables: el riesgo ya está materializado. Asumí que el PoC de "Copy Fail" puede correr en tu host y priorizá el parche por encima de casi todo.
Si solo tú operas el host: el riesgo es menor (los CVEs requieren ejecución local), pero no es cero: cualquier container con un proceso comprometido hereda el riesgo.
Auditd + SIEM: desplegá las reglas de arriba para tener detección temprana de intentos.

Preguntas frecuentes

¿Por qué CISA agrega 3 CVEs críticos del kernel Linux al KEV: lo que un sysadmin tiene que saber es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con CISA agrega 3 CVEs críticos?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con CISA agrega 3 CVEs críticos?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar CISA agrega 3 CVEs críticos y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a CISA agrega 3 CVEs críticos?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.