CISA incorporó el 18 de septiembre de 2026 tres vulnerabilidades del kernel de Linux a su catálogo de vulnerabilidades explotadas conocidas, con fecha límite del 21 de septiembre para las agencias federales estadounidenses. Red Hat actualizó sus avisos el 19 de septiembre y confirmó la existencia de exploits públicos conocidos.
Es el tipo de boletín que en México casi nadie atiende, por dos razones que conviene desarmar: "eso es de agencias federales gringas" y "son fallos locales, no remotos".
Las tres, en orden de gravedad
| CVE | CVSS | Qué es |
|---|---|---|
| CVE-2025-39682 | 9.8 | Comprobación inadecuada de condiciones inusuales en la ruta de recepción de TLS. Puede provocar divulgación de memoria o denegación de servicio. |
| CVE-2026-53266 | 8.8 | Escritura fuera de límites en la ruta de reescritura de ARP con SNAT de ebtables (filtrado de red). Puede derivar en comportamiento inesperado, denegación de servicio o escalada local de privilegios. |
| CVE-2025-39964 | 7.8 | Condición de carrera que afecta a los sockets AF_ALG. Puede tumbar el sistema o corromper resultados de operaciones criptográficas. |
No se han publicado detalles de cómo se están explotando en la vida real. Lo que sí está confirmado es que se explotan.
Dónde te toca, aunque creas que no usas Linux
Es el punto ciego más común en empresas medianas mexicanas. "Nosotros somos Windows" casi nunca es cierto del todo:
- El hipervisor. Proxmox corre sobre Debian; buena parte de la virtualización on-premise es Linux por debajo.
- El NAS de respaldos. Synology, QNAP y compañía son Linux con otra cara.
- Contenedores. Cada host de Docker o Kubernetes es una máquina Linux, y los contenedores comparten el kernel del anfitrión. Es el escenario donde una escalada local pesa más.
- Servidores de aplicación y bases de datos. El ERP, el sitio web, PostgreSQL, el servidor de archivos.
- Appliances de red. Firewalls, balanceadores, controladores de Wi-Fi.
Si hay virtualización, respaldos en red o cualquier sistema de negocio auto-hospedado, hay Linux — y hay kernel que parchar.
La parte que de verdad cuesta: el reinicio
Actualizar el kernel es un comando. Hacerlo efectivo es otra cosa.
Un kernel actualizado en disco pero no cargado en memoria no protege nada. Y en la práctica, los servidores de una PyME se reinician poco, precisamente porque sostienen algo que no puede parar.
El procedimiento sano no tiene misterio, pero sí orden:
- Inventario. Qué máquinas Linux hay, qué distribución y qué versión de kernel. Si esa lista no existe, ese es el primer trabajo.
- Respaldo verificado antes de tocar nada. Verificado significa que restauró en una prueba, no que el reporte salió verde.
- Actualizar desde los repositorios de la distribución. No compilar a mano, no bajar paquetes sueltos.
- Reiniciar en ventana de mantenimiento, empezando por lo menos crítico.
- Documentar qué máquinas no pueden reiniciarse. Esa lista es el hallazgo más valioso del ejercicio: no es un problema de parcheo, es un problema de arquitectura, y se resuelve con redundancia.
El patrón del mes, otra vez
Windows con casi mil vulnerabilidades, Cisco ISE con 10.0, la consola RMM de los proveedores de TI, el séptimo 0-day de Chrome y ahora el kernel de Linux.
La conclusión no es que todo está roto. Es que el descubrimiento de vulnerabilidades se aceleró de forma permanente, y ninguna empresa mediana puede leer y evaluar cada boletín.
Lo que sí puede es tener cuatro cosas, ninguna cara: un inventario actualizado, una ventana de parcheo con vía rápida para lo crítico, la superficie de exposición reducida al mínimo y respaldos que restauran. Con eso, cada boletín deja de ser una emergencia y pasa a ser trabajo programado.
Infraestructura gestionada
¿Quién parcha tus servidores, y cuándo?
Inventario, ventanas de mantenimiento, respaldo verificado y parcheo gestionado de tu infraestructura Linux y Windows.
