El parche del kernel es un reinicio, y el reinicio borra la prueba

Hoy, viernes, el catálogo de vulnerabilidades explotadas de CISA ha crecido en dos líneas. Las dos dicen Linux, las dos dicen Kernel y las dos vencen el lunes. Una de ellas lleva once meses en tu escáner con un 3,3 sobre 10, en el color que nadie mira.

El 3,3 es real y está en la ficha oficial. El NVD publicó CVE-2025-39964 el 13 de octubre de 2025 con el vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L: local, sin impacto en confidencialidad ni en integridad, y una disponibilidad «baja». Dicho en claro: un usuario del sistema puede corromper unos datos. Trescientos cuarenta días después, CISA dice que alguien lo está usando de verdad.

En la misma página hay una segunda puntuación, la del CNA que asignó el CVE —el propio proyecto del kernel—: 7,8, con C:H/I:H/A:H. Cuatro puntos y medio de diferencia sobre el mismo fallo, en la misma ficha, sin que ninguno de los dos se haya equivocado.

Dos números para tres preguntas

El NVD puntúa lo que el parche dice que arregla, y el mensaje del arreglo es seco: «Issuing two writes to the same af_alg socket is bogus as the data will be interleaved in an unpredictable fashion. Furthermore, concurrent writes may create inconsistencies in the internal socket state.» Datos entremezclados: disponibilidad baja, cero confidencialidad, cero integridad. El CNA del kernel puntúa otra cosa: qué llega a ser una carrera que deja inconsistente el estado interno de un socket cuando alguien se sienta a trabajársela.

Ninguna de las dos cifras responde a la tercera pregunta, que es la única que aprieta un viernes por la tarde: ¿lo está usando alguien? Esa la contesta el catálogo de CISA, y la contesta con una fecha de alta y un plazo. Hoy 18, vence el 21.

Opinión: si tu cola de parcheo se ordena por la puntuación que trae el escáner, este fallo llevaba once meses en la página cuatro. No es culpa del escáner. Es lo que pasa cuando se le pide a una sola cifra que conteste tres preguntas distintas —qué rompe, hasta dónde llega y quién lo está usando— y solo sabe contestar la primera.

El otro vive en el puente por el que pasan tus máquinas

CVE-2026-53266 se publicó el 25 de junio y ha tardado 85 días en entrar en el catálogo. Es una escritura fuera de rango (CWE-787) en el objetivo SNAT de ebtables, el cortafuegos del puente Ethernet. El mensaje del commit: la reescritura de la dirección de origen Ethernet está protegida a propósito detrás de skb_ensure_writable(skb, 0). Lo que no estaba protegido es la reescritura opcional de la dirección hardware del emisor dentro de la cabecera ARP —la que activa la opción --snat-arp—, que escribe con skb_store_bits() en un desplazamiento relativo a skb->data.

Y ahí está el problema, con las palabras del propio parche: «If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it.» El arreglo consiste en asegurarse de que el rango es escribible antes de escribir en él. El CNA del kernel le pone 8,8 con S:C, alcance cambiado: el daño no se queda dentro del componente que tiene el fallo. Cuando el destino de la escritura es la página de un fichero que alguien importó con splice, esa letra deja de ser teórica.

Si administras Proxmox VE, la palabra ebtables te suena, y no de lejos: el cortafuegos del clúster trae la opción ebtables a 1 por defecto en /etc/pve/firewall/cluster.fw, y el cortafuegos basado en nftables sigue marcado en la documentación de la 9.2 como technology preview, con el aviso de que no es apto para producción. El que corre por defecto es el de siempre.

La parte honesta: las reglas que escribe el cortafuegos de Proxmox no son reglas de SNAT en la tabla nat, que es el único sitio donde vive el objetivo vulnerable. Que tu nodo tenga ebtables activo no significa que esté ejecutando ese código. Significa que el módulo está en el kernel que arrancas, y que quien pueda crear reglas de puente —con CAP_NET_ADMIN en su propio espacio de nombres de red, y con el módulo cargado o cargable desde ahí— podría alcanzar ese objetivo aunque tú no lo uses jamás. No lo hemos reproducido. Se comprueba con ebtables -t nat -L. Y si hoy no puedes reiniciar, hay salidas provisionales que no tocan el kernel arrancado: impedir que ese módulo se cargue, o cerrar los espacios de nombres de usuario no privilegiados con user.max_user_namespaces. Las dos rompen cosas en según qué cargas, así que se prueban antes.

«Local», en un hipervisor, no significa lo que parece

Los dos vectores empiezan igual: AV:L, acceso local. En un portátil eso significa que alguien tiene que estar dentro. En un host con invitados significa otra cosa: «local» es el conjunto de todos los que comparten ese kernel. Y ahí la diferencia entre un contenedor y una máquina virtual deja de ser una preferencia de despliegue.

En un contenedor LXC no hay un kernel invitado: hay el tuyo. Una escalada local dentro de ese contenedor se juega contra el mismo binario que arranca el nodo. Una VM con KVM sí tiene su propio kernel, que también es Linux y que también puede estar en rango: ahí el mismo fallo es lo que el CNA puntúa al poner PR:L junto a C:H/I:H/A:H, y eso, traducido, es pasar de «tengo ejecución dentro de tu aplicación web» a «soy root en esa máquina». Y AF_ALG, por cierto, es la cara en espacio de usuario de la API criptográfica del kernel: un socket que cualquier proceso local puede abrir. El PR:L del vector lo dice sin adornos.

Que eso se convierta en avería depende de a quién le has dado una shell, y eso sí es una decisión tuya, tomada hace meses, probablemente sin pensar que algún día se leería así.

Qué rama lo arregla, y por qué la tuya puede no estar en la lista

Las versiones corregidas de CVE-2026-53266, leídas de los rangos de la ficha: 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 y 7.0.13. Léela otra vez y busca una 6.17. No está. La 6.17 no es una rama con mantenimiento largo, así que el arreglo aparece en la 6.18.36 y no en una 6.17.x: quien arranque una 6.17 no se pone al día actualizando dentro de su rama, sino cambiando de rama o dependiendo de que su distribución le retroporte el parche.

Con CVE-2025-39964 pasa lo contrario, y por una vez es buena noticia: el arreglo entró en 6.17-rc7, de modo que las versiones corregidas son 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49 y 6.16.9, y cualquier kernel 6.17 o posterior ya lo lleva de fábrica. Llevado a Proxmox VE, depende de la versión y esto importa: la 9.1 trae 6.17.2 por defecto y la 9.2 la serie 7.0, así que ahí el del 3,3 ya está cerrado; en la 9.0 (6.14) y en la 8.x (6.8) no lo está, y esas están en rango de los dos. Del de 8,8 no se libra ninguna quedándose dentro de su rama: en 6.17 no hay arreglo de serie, y en la 7.0 hay que estar en 7.0.13 o por encima. En Debian, el paquete linux cierra los dos en 6.1.187-1 (bookworm) y 6.12.107-1 (trixie).

Con un matiz que ya contamos entero en su día y que aquí solo se recuerda: un nodo Proxmox no arranca el kernel de Debian, así que el número que sale en el boletín de Debian no es el número que tienes que comparar. Lo que manda es lo que devuelvan uname -r y pveversion -v en tu máquina, esta tarde, no el de la noticia.

¿Recoges primero o parcheas primero?

Las dos entradas de hoy traen la marca de triaje forense. En el JSON del catálogo —versión 2026.09.18, 1.715 entradas— la llevan 57, y conviene mirar de dónde sale ese 57: ninguna entrada anterior al 1 de julio de 2026 la tiene, porque el campo no existía. De las 85 altas posteriores a esa fecha, 57 la llevan y 28 no. O sea que no es una marca rara: es lo que CISA pone en dos de cada tres cosas que da de alta desde el verano.

La guía de implantación que acompaña a esa marca dice esto: «Do not alter or remediate systems prior to evidence/artifact collection when possible.» Y reparte los pasos en el reloj: delimitar el alcance en las dos primeras horas desde el alta, recoger las pruebas entre las 2 y las 24 horas, y parchear también entre las 2 y las 24 horas, pero después de recogerlas.

Ahora junta las dos cosas. El arreglo de un fallo del kernel es un reinicio. Y un reinicio se lleva por delante la memoria, la tabla de procesos, los sockets abiertos, los módulos tal como estaban cargados, el contenido de /proc, lo que hubiera en tmpfs y cualquier cosa que nunca llegara a tocar el disco. La acción que te quita el problema es también la que borra media respuesta a «¿han entrado?». Media, porque el diario persistente, la auditoría y lo que hayas mandado fuera sobreviven al reinicio. Lo que no sobrevive es lo que solo existía en RAM, que suele ser justo lo que querrías mirar.

La directiva obliga a las agencias federales de Estados Unidos; a ti no te obliga nadie. Pero el catálogo lo usa todo el mundo, incluidas las auditorías que te pasan a ti, y el dilema es idéntico con directiva o sin ella. Con el dilema se puede vivir. Con resolverlo a las tres de la mañana, quien esté de guardia, sin nada escrito y con un plazo encima, se vive bastante peor.

El orden que seguimos nosotros

1. ¿Me toca? uname -r en cada host, pveversion -v en los nodos Proxmox, dpkg -l 'linux-image-*' en Debian. Se compara con las versiones corregidas de arriba y con el paquete de tu distribución. Nunca con el titular.
2. ¿Quién comparte kernel? qm list y pct list dicen cuántos invitados llevan su propio kernel y cuántos usan el tuyo. A mano se añade lo que no sale ahí: quién tiene shell en el host, qué proceso ejecuta código de terceros, qué runner de integración continua compila lo que le manden.
3. Si estás en rango, mirar antes de tocar. Siguiendo el orden de volatilidad de la RFC 3227 (2002), aunque saltándonos su primer escalón, que es la memoria: procesos y el binario real detrás de cada uno (ps -ef, ls -l /proc/*/exe), sockets y de quién son (ss -tunap), módulos cargados (lsmod) y el diario del sistema copiado fuera de la máquina. Esto no es un análisis forense —uno de verdad empieza por volcar la memoria en caliente y lo hace quien sabe hacerlo—, pero es la diferencia entre tener algo y no tener nada.
4. Y entonces sí, el reinicio rodado. ha-manager crm-command node-maintenance enable <nodo>, que mueve los servicios gestionados por HA y los devuelve al desactivarlo; ceph osd set noout si hay Ceph, para que el clúster no se ponga a rebalancear por un nodo que vuelve en cinco minutos; actualizar, reiniciar, y comprobar que el nodo ha vuelto, que hay quórum y que ceph -s da HEALTH_OK antes de tocar el siguiente. Uno cada vez, aunque el plazo apriete.
5. Apuntar la hora de cada paso. Si dentro de un mes alguien pregunta qué se hizo, cuándo y quién lo decidió, esa lista es la respuesta. Y si no la hay, la respuesta es que no se sabe.

Mover un contenedor es pararlo

La migración en vivo es una función de las máquinas virtuales. La documentación de Proxmox lo dice de pasada, en la página de contenedores, hablando de los «Application Containers» de tipo OCI que acaba de estrenar en vista previa: «While running lightweight "Application Containers" directly offers significant advantages over a full VM, for use cases demanding maximum isolation and the ability to live-migrate, nesting containers inside a Proxmox QEMU VM remains a recommended practice.» Un contenedor se mueve parándolo.

Ahí aparece una simetría desagradable: los invitados más expuestos a un fallo local del kernel —los que comparten el tuyo— son exactamente los que no se pueden mover sin pararlos. La aritmética es esa, y se planifica en una hoja antes de que llegue el viernes. A la lista se suman las VMs con dispositivos PCI en passthrough y las que tienen el disco en almacenamiento local, que tampoco viajan en caliente. Cada una de esas es un minuto de parada que se decide en una reunión, no a las tres de la mañana.

Y si el clúster no tiene sitio para funcionar con un nodo menos, el reinicio rodado se convierte en un apagado a plazos. Es la misma historia que contamos sobre la redundancia que no sobrevive al procedimiento y sobre lo que hace el clúster cuando le falta un nodo: el hierro estaba, el margen también, y el procedimiento se los comió.

Cuándo no haríamos nada este fin de semana

Los dos fallos son locales. Si en esos hosts no hay contenedores de terceros, ni shell para nadie de fuera, ni un runner que compile lo que le manden, ni clientes distintos compartiendo la misma máquina, la cadena necesita un primer punto de apoyo que puede que no exista. Entonces no quemes una ventana de sábado: programa el reinicio rodado para la ventana normal, con el procedimiento delante y con quien toca despierto.

Dos cosas sí las haríamos hoy: comprobar si estás en rango, y mirar el registro. Lo segundo no lo pide ningún plazo. Lo pide el reinicio del lunes, que ya no te dejará hacerlo.

Y una declaración de parte, porque toca: vendemos guardia 24/7. Cuando te decimos que no hace falta llamar a nadie un sábado, estamos diciendo justo lo contrario de lo que nos conviene. Léelo con la ceja levantada, y decide tú.

Dos líneas nuevas en una lista, un plazo que cae en lunes y una tecla que arregla y borra a la vez. Nada de eso se decide bien a las once de la noche: se decide en marzo, cuando no pasa nada y alguien se sienta a escribir el procedimiento.

Lo que no afirmamos

No hemos reproducido ninguno de los dos fallos ni tenemos exploit de ninguno: CISA dice que hay explotación conocida y no publica cómo, así que no describimos una cadena de ataque que no hemos visto. El 3,3 del NVD no nos parece mal calculado: mide una pregunta distinta de la que aprieta. Tampoco hemos evaluado a fondo las mitigaciones provisionales que mencionamos, así que van como lo que son, un apaño para ganar horas. No sabemos qué paquete concreto de Proxmox lleva hoy el arreglo de CVE-2026-53266 —el número que hay que mirar es el de tu nodo, no el de una nota—. La lectura de ebtables en un nodo Proxmox es nuestra y va acotada arriba: el módulo está, el objetivo vulnerable no lo usa el cortafuegos del producto. La directiva BOD 26-04 obliga a agencias federales de Estados Unidos y no a una empresa española. Y el punto 3 de nuestro orden no es un análisis forense: es recoger cuatro cosas antes de que el reinicio se las lleve. Un detalle que no sabemos explicar y no vamos a esconder: en esas mismas fichas del NVD, la evaluación SSVC que firma CISA el 18 de septiembre marca exploitation: none, el mismo día del alta en el catálogo de explotados. El plazo manda igual, pero ahí está.

Nota de fuentes

Todo consultado el 18 de septiembre de 2026, sobre las fuentes primarias y no sobre coberturas de segunda mano. Uno: el fichero JSON del catálogo de vulnerabilidades explotadas de CISA, descargado esta tarde (versión 2026.09.18, publicada a las 13:49 UTC, 1.715 entradas): de ahí salen las dos altas de hoy, sus plazos al 21 de septiembre, la marca de triaje forense y el recuento propio: 57 entradas la llevan, todas del 1 de julio de 2026 en adelante, sobre 85 altas en ese periodo. Dos: la API del NVD para CVE-2025-39964 y CVE-2026-53266: fechas de publicación, los vectores CVSS con su origen —en CVE-2025-39964, el primario del NIST (3,3) y el del CNA del kernel (7,8); en CVE-2026-53266 solo el del CNA (8,8), porque el NVD no ha publicado evaluación primaria—, las clases CWE-362 y CWE-787, que en la ficha firma CISA-ADP y no el NVD, y los rangos de versiones afectadas de donde salen las listas de versiones corregidas. Tres: los mensajes de los dos parches del kernel, citados tal cual. Cuatro: el rastreador de seguridad de Debian para las dos fichas (paquete linux, versiones corregidas por publicación y la nota de que el arreglo de af_alg entró en 6.17-rc7). Cinco: la guía de implantación de la BOD 26-04 de CISA, de donde sale la frase sobre no remediar antes de recoger y los tramos horarios de los pasos. Seis: la documentación de Proxmox VE —capítulo del cortafuegos (opción ebtables y estado del cortafuegos nftables), capítulo de contenedores (la frase sobre migración en vivo) y capítulo de HA (el comando de modo mantenimiento)— y la página Roadmap para los kernels por defecto de la 9.1 y la 9.2. Siete: el manual de ebtables para la opción --snat-arp, y la RFC 3227 para el orden de volatilidad. Lo que es opinión nuestra y va marcado como tal en el cuerpo: que una sola cifra no puede contestar tres preguntas; la lectura de «local» en un host con invitados; la simetría entre lo más expuesto y lo que no se puede mover en caliente; el orden de cinco pasos; y los casos en los que no haríamos nada este fin de semana.

Imagen de portada: fotografía de un servidor de dos zócalos con sus bancos de memoria, de 极客湾Geekerwan (Wikimedia Commons, CC BY 3.0), recortada por nosotros. Los textos y la marca los añadimos encima.