Una nueva vulnerabilidad en OVSwrap para Linux permite a los usuarios locales obtener privilegios de root en sistemas con la configuración predeterminada

La versión resumida

Ir a la versión completa ↓

En qué consiste: CVE-2026-64531, también conocido como OVSwrap, es una vulnerabilidad de escalada de privilegios locales en el núcleo de Linux, situada en la ruta de validación de acciones de Open vSwitch. Un campo de longitud de 16 bits se desborda cuando el núcleo construye una acción anidada de tamaño excesivo, y el analizador reanuda la lectura dentro de los bytes controlados por el atacante, que a continuación se procesan como acciones legítimas de Open vSwitch. Ir a esta sección →

Impacto: Un usuario local sin privilegios puede filtrar punteros del núcleo, leer la memoria del núcleo y realizar una escritura dirigida. La prueba de concepto pública encadena estas acciones en una ruta completa de corrupción de credenciales que escribe una entrada en el archivo «sudoers» y abre un shell de root. Incluye desplazamientos precalculados para aproximadamente 800 compilaciones del núcleo x86-64. Ir a esta sección →

Gravedad: Con una puntuación de gravedad de 7,8, considérese esto como una prioridad alta. Para aprovechar esta vulnerabilidad solo se necesita una cuenta local normal y nada más: no se requiere configuración de Open vSwitch, ni que ovs-vswitchd esté en ejecución, ni un puente OVS, ni CAP_NET_ADMIN en el espacio de nombres inicial, ni un contenedor con privilegios. La orden «unshare -Urn» proporciona la capacidad dentro de un espacio de nombres creado por el atacante. Ir a esta sección →

Quiénes se ven afectados: Cualquier núcleo afectado en el que se permitan espacios de nombres de usuario sin privilegios y en el que el módulo openvswitch esté disponible para su carga. Esa es la configuración predeterminada en la mayoría de las distribuciones. Ámbito de aplicación confirmado por nuestro propio análisis de retroportabilidad: Enterprise Linux 9.7 y versiones posteriores, Enterprise Linux 10.1 y versiones posteriores, Debian 12 y 13, Ubuntu 22.04 y 24.04, y Amazon Linux 2023. Ir a esta sección →

Estado: No se trata de una vulnerabilidad «zero-day». Se notificó de forma privada el 19 de junio de 2026 y se corrigió en las ramas estables el 24 de julio. El registro CVE y el anuncio de CVE para Linux se hicieron públicos el 27 de julio, seguidos del informe completo y un exploit funcional el 28 de julio. No hay constancia pública de que se haya explotado en la red. Ir a esta sección →

Haz esto ahora mismo: aplica un kernel fijo del proveedor y reinicia el sistema, o implementa el parche en vivo de KernelCare sin necesidad de reinicio (que ya se ha implementado automáticamente para los usuarios de varias distribuciones). Si el host no utiliza Open vSwitch, bloquea el módulo mientras tanto. Una cosa que debes omitir: «apparmor_restrict_unprivileged_userns» y los parámetros de refuerzo de seguridad relacionados de Debian y Ubuntu para «userns» no detienen esta cadena. Nuestro equipo del kernel los ha probado. Ir a esta sección →

Comprobar si el módulo está cargado no es la prueba adecuada. Comprueba si está presente en el disco para el núcleo en ejecución:

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

Si eso muestra una ruta, el servidor queda expuesto hasta que se aplique el parche al núcleo o se bloquee el módulo, independientemente de si ya se ha cargado o no.

La mayoría de los servidores expuestos a OVSwrap nunca han ejecutado Open vSwitch a sabiendas. Esa es la parte que pilla desprevenidos a los equipos.

OVS se asocia habitualmente con las redes definidas por software: OpenStack, OVN, CNI de Kubernetes y plataformas de virtualización. Si no utilizas ninguna de estas tecnologías, lo más lógico es suponer que esta CVE no te afecta. Sin embargo, el código vulnerable se incluye como módulo cargable en el paquete estándar del núcleo de casi todas las distribuciones principales, y el núcleo lo carga bajo demanda cuando algún componente lo solicita.

Un usuario sin privilegios lo solicita. Crea un espacio de nombres de usuario y de red privado, que le concede el permiso CAP_NET_ADMIN dentro de ese espacio de nombres, y eso basta para instalar los flujos de Open vSwitch a través de la interfaz Netlink. La solicitud carga automáticamente el módulo en el núcleo del host. Sin intervención del administrador, sin archivo de configuración, sin daemon.

Por lo tanto, «no utilizamos Open vSwitch» no es una afirmación sobre la vulnerabilidad. Es una afirmación sobre si bloquear el módulo provocará algún fallo, lo cual es una cuestión diferente y más útil.

El momento en que se produjo es otro aspecto a tener en cuenta. La confirmación 3f1f75536668 se incorporó a la rama estable cuatro días antes de que se hiciera público el exploit, por lo que es posible que las flotas que utilizan ciclos de actualización rápidos del kernel estable ya estén protegidas. Esos cuatro días son también el intervalo total entre el momento en que «la corrección estaba disponible» y el momento en que «el exploit funcionaba con los desplazamientos para 800 compilaciones».

Las acciones de Open vSwitch se transmiten como atributos de Netlink. Cada una de ellas comienza con un encabezado «struct nlattr» que contiene un campo «nla_len» de 16 bits, que puede representar un máximo de 65 535 bytes.

Cuando OVS valida un flujo, desglosa las acciones anidadas en un flujo de acciones interno que genera el propio núcleo. OVS_ACTION_ATTR_CLONE es el que nos interesa en este caso, ya que envuelve otra lista de acciones y, por lo tanto, puede anidarse. El código vulnerable nunca verificaba que un atributo anidado generado siguiera cabiendo dentro del campo de longitud de 16 bits.

[Attacker enters a private user and network namespace]
|
v
[Attacker gains CAP_NET_ADMIN inside that namespace]
|
v
[Attacker installs a flow packing hundreds of conntrack
actions inside a CLONE wrapper]
|
v
[Generated nested action stream exceeds 65,535 bytes]
|
v
[Length is stored in the 16-bit nla_len field and wraps
to a small value]
|
v
[Parser resumes mid-stream, inside attacker-controlled data]
|
v
[Forged action headers are parsed as real OVS actions]
|
v
[Kernel read and constrained write primitives]
|
v
[Host-process credentials corrupted, root shell]

El exploit agrupa cientos de acciones «conntrack» dentro de un contenedor «CLONE». A medida que OVS las expande, el flujo generado supera la capacidad de «nla_len», el valor se trunca y se reinicia a un valor pequeño, y el analizador se detiene en un desplazamiento incorrecto. Se reanuda a mitad del flujo, en los bytes que el atacante ha elegido, dispuestos de tal forma que parezcan encabezados de acción válidos. El núcleo los procesa como acciones auténticas.

Los requisitos de accesibilidad son los únicos límites reales: x86-64, una ruta de datos del núcleo OVS con soporte para conntrack y FTP-helper, y que se permita la creación de espacios de nombres sin privilegios. Un núcleo de distribución x86-64 estándar con contenedores sin root habilitados cumple estos tres requisitos.

Las acciones forjadas son el origen de las primitivas.

Las acciones SET en un túnel falso provocan una fuga de puntero del núcleo y una lectura de la memoria del núcleo. Una ruta de limpieza independiente del destino del túnel da lugar a una escritura restringida, en forma de una disminución selectiva del recuento de referencias de 32 bits.

Un simple decremento de 32 bits parece demasiado insignificante como para tener importancia, y por sí solo lo es. Pero es el conjunto de medidas que lo rodean lo que lo hace suficiente. Antes de acceder al espacio de nombres, el exploit crea una bifurcación de un proceso que permanece en el lado del host. A continuación, dirige el decremento hacia las credenciales de ese proceso y, una vez que el proceso obtiene privilegios, escribe una entrada en la configuración de sudoers e inicia un shell de root.

El resultado es una escalada de privilegios fiable, en lugar de un fallo del sistema. Si a esto le sumamos los desplazamientos precalculados para unas 800 compilaciones del núcleo, el esfuerzo necesario para reproducir esto en un sistema compatible es prácticamente nulo.

Hay dos condiciones que determinan si un host es vulnerable, y ambas son valores predeterminados en casi todos los casos: se permiten los espacios de nombres de usuario sin privilegios, y openvswitch se encuentra en el paquete estándar del núcleo sin ninguna restricción de carga automática que lo impida. Las distribuciones mantienen habilitados los espacios de nombres porque Podman sin privilegios de root, Docker sin privilegios de root, Bubblewrap, Flatpak, unshare(1) sin privilegios y el entorno aislado de Chromium dependen de ellos.

El ataque publicado no requiere:

• Un proceso «ovs-vswitchd» en ejecución
• Un puente Open vSwitch ya existente
• Cualquier configuración previa de Open vSwitch
• CAP_NET_ADMIN en el espacio de nombres del host
• Un contenedor privilegiado
• El módulo que debe cargarse antes de que comience el ataque

Esto significa que la superficie de ataque es más amplia que en el caso de los hosts que ejecutan OVS de forma activa: incluye sistemas afectados en los que el módulo simplemente está disponible para que un usuario sin privilegios lo active, y las pruebas realizadas por el investigador revelaron que esto se aplica a la mayoría de las distribuciones probadas en su configuración predeterminada.

Imagina dónde acaba todo esto. Un ejecutor de compilaciones compartido que ejecuta lo último que se ha publicado en una solicitud de fusión. Un nodo multitenant en el que el código del cliente se ejecuta bajo una cuenta normal. Una estación de trabajo de desarrollador con contenedores sin privilegios de root y unos cuantos cientos de dependencias que nadie ha leído. En cada caso, el atacante ya dispone de la cuenta local, y el módulo que necesita está a solo una solicitud Netlink de cargarse por sí mismo.

La decisión respecto a cada anfitrión es breve:

• Si el host no utiliza OVS y ningún componente del mismo depende de puentes basados en OVS, bloquea el módulo. De este modo se elimina la ruta de código vulnerable, en lugar de bloquear únicamente una vía de acceso a ella.
• Si el host utiliza OVS, ya sea un nodo OVN o OpenStack Neutron, un clúster de Kubernetes que ejecute ovn-kubernetes o Antrea, o un host libvirt u oVirt con puentes basados en OVS, no modifiques el módulo. Deniega los espacios de nombres de usuarios sin privilegios o, en su lugar, aplica el parche.

El fallo es antiguo, pero la ventana de vulnerabilidad no lo es

Hay dos fechas que son importantes, y si se confunden, se obtiene una respuesta errónea en la clasificación de pacientes.

La asignación insegura al campo de longitud de 16 bits tiene aproximadamente 13 años de antigüedad. Durante la mayor parte de ese tiempo, un límite condicional independiente restringía el flujo de acciones generado a 32 KiB, lo que impedía que una acción llegara a ser lo suficientemente grande como para sobrepasar el valor de nla_len. El límite se eliminó en marzo de 2025, y eso fue lo que hizo que el error latente se pudiera explotar.

En términos generales, la ventana de vulnerabilidad se abre en torno a la versión 6.14 de Linux. Las ramas de largo plazo más antiguas se volvieron vulnerables cuando se les aplicó retroactivamente la eliminación del límite, no cuando se produjo el error original.

Rangos de estabilidad publicados:

• Del 5.15.180 al 5.15.211
• Del 6.1.132 al 6.1.177
• Del 6.6.84 al 6.6.144
• Del 6.18.0 al 6.18.39
• Del 7.1.0 al 7.1.4

Versiones con las primeras correcciones notificadas: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 y 7.1.5.

Los núcleos de los proveedores se desvían del código original en ambas direcciones, por lo que los rangos anteriores son un punto de partida más que una respuesta definitiva. Algunos núcleos 5.14 derivados de RHEL incorporan el cambio de habilitación y se ven afectados a pesar de situarse por debajo de todos los rangos de la tabla. Algunos núcleos SUSE 6.12 mantuvieron el límite anterior y no se ven afectados a pesar de situarse dentro de uno de ellos.

Las distribuciones empresariales también retroaplican cambios individuales sin adoptar una versión de origen, por lo que un núcleo cuya versión quede fuera del intervalo publicado puede seguir conteniendo la combinación vulnerable. Este intervalo se introdujo directamente en la línea de desarrollo 6.14 y, posteriormente, se amplió a las ramas antiguas de mantenimiento a largo plazo a medida que se les iba retroaplicando ese cambio. Consulta el aviso o el estado del parche correspondiente al núcleo de la distribución concreta.

La confirmación a1e64addf3ff, «net: openvswitch: eliminar la comprobación de longitud de las acciones que presentaban un comportamiento anómalo», eliminó ese límite en marzo de 2025 porque provocaba fallos impredecibles, ya que las acciones de OVS pueden aumentar o reducirse al convertirse a su formato interno. La eliminación de la comprobación de longitud total fue una medida razonable. El efecto secundario fue que ya nada impedía que un atributo anidado concreto superara los 65 535 bytes.

Nuestro análisis del núcleo ha confirmado la ruta vulnerable en las siguientes familias de plataformas compatibles:

• Enterprise Linux 9.7 y versiones posteriores
• Enterprise Linux 10.1 y versiones posteriores
• Debian 12 (solo las versiones 6.1.132-1 y posteriores) y Debian 13
• Ubuntu 22.04 LTS y Ubuntu 24.04 LTS
• Amazon Linux 2023

El ámbito de Enterprise Linux abarca los núcleos correspondientes de RHEL, AlmaLinux, Rocky Linux y CloudLinux, ya que comparten el código afectado. CloudLinux 9 utiliza el núcleo de AlmaLinux 9 y CloudLinux 10, el de AlmaLinux 10, por lo que ambos heredan directamente la vulnerabilidad.

La cobertura es específica para cada versión y cada variante. No se debe deducir que una variante adyacente sea vulnerable o haya sido corregida por el mero hecho de que otra versión de la misma distribución aparezca en la lista.

Hay dos cuestiones que aún están en el aire y no están claras. Ni Enterprise Linux 8 ni CloudLinux 8 —que utiliza su propia línea de kernels, distinta de la de AlmaLinux 8— han sido confirmados en ningún sentido, al igual que Ubuntu 20.04 y las ramas más antiguas de Debian y Ubuntu con soporte a largo plazo. La pregunta que se plantea para todas ellas es si han incorporado la retrocompatibilidad de la eliminación del límite.

Una suposición sobre el endurecimiento de seguridad que conviene descartar desde el principio: el investigador señala que ni SELinux ni AppArmor bloquearon ninguna fase del exploit durante las pruebas, salvo la política de espacio de nombres de usuario de AppArmor, que impidió la creación de espacios de nombres en algunas versiones de Ubuntu, como se explica más adelante. El modo de aplicación no altera el resultado en este caso.

Por qué las restricciones habituales en el espacio de nombres de usuario pueden no ser de ayuda

Esta es la parte que más probabilidades tiene de costarle a alguien el fin de semana.

Las versiones recientes de Ubuntu incluyen una política de AppArmor que restringe la creación de espacios de nombres por parte de usuarios sin privilegios, controlada por el parámetro `kernel.apparmor_restrict_unprivileged_userns`. Es la primera opción a la que recurren la mayoría de los equipos, y bloquea efectivamente la ruta sencilla `unshare -Urn`: en Ubuntu 24.04 y 26.04, el intento directo falla con la política predeterminada activada.

No es una medida de mitigación en la que debas confiar. Una forma de eludir AppArmor, documentada públicamente, anula la política en la versión 24.04, y en la 26.04 el exploit funciona en cuanto se desactiva la restricción. Nuestro propio equipo del núcleo llegó a la ruta vulnerable con esas opciones de refuerzo de seguridad de Debian y Ubuntu activadas. Considera la política como un badén en el camino hacia un parche.

Denegar directamente la creación de un espacio de nombres rompe la cadena publicada, ya que el atacante ya no puede acceder a CAP_NET_ADMIN mediante «unshare -Urn». El control que lleva a cabo esta acción es el de nivel superior:

# /etc/sysctl.d/99-ovswrap.conf
user.max_user_namespaces = 0

sudo sysctl --system

Utiliza «user.max_user_namespaces» en lugar de «kernel.unprivileged_userns_clone». Este último es un parche derivado de la familia Debian que ha quedado obsoleto y que no existe en absoluto en Enterprise Linux; en Ubuntu, donde ambos pueden estar presentes, configurar únicamente el parámetro «unprivileged_userns_clone» puede dejar una vía residual para la creación de espacios de nombres, dependiendo de la versión del núcleo.

Comprueba el valor que se ha aplicado realmente, ya que un archivo de distribución situado en /usr/lib/sysctl.d/ que se ejecute posteriormente prevalecerá sin avisar:

sysctl user.max_user_namespaces

El coste de la compatibilidad es real. Las herramientas de contenedores sin privilegios de root dejan de funcionar, la función `unshare(1)` sin privilegios deja de funcionar y el entorno aislado de Chromium deja de funcionar. En un entorno convencional de servidores de alojamiento o de bases de datos, nadie se da cuenta. En las estaciones de trabajo de los desarrolladores y en los servidores de compilación de contenedores, se nota en cuestión de minutos.

¿Hay alguna solución alternativa?

La medida de mitigación temporal adecuada depende de si el servidor utiliza realmente Open vSwitch. Ninguna de las dos opciones sustituye a la solución definitiva.

1. Desactiva el módulo Open vSwitch. Se recomienda hacerlo en cualquier servidor que no utilice OVS, es decir, en la mayoría de los parques de servidores de alojamiento. Comprueba primero con el comando «lsmod | grep openvswitch» que no haya ningún proceso «ovs-vswitchd» en ejecución. A continuación:

# /etc/modprobe.d/99-ovswrap.conf
blacklist openvswitch
install openvswitch /bin/false

La línea «install» es la que realiza la tarea. Una entrada en la lista negra por sí sola no impide que el propio núcleo solicite el módulo bajo demanda, que es precisamente la vía que utiliza este exploit, por lo que limitarse a incluirlo en la lista negra no supone una medida de mitigación en este caso. Ten en cuenta que el usuario root aún puede anular una directiva «install» con «modprobe –ignore-install», y que los módulos que se cargan de forma forzada a través del initramfs no están sujetos a ninguna de las dos directivas.

La regla solo bloquea las cargas futuras. Si el módulo ya se encuentra en memoria, detén cualquier proceso que dependa de él y descárgalo; esto tampoco requiere reiniciar el sistema:

sudo modprobe -r openvswitch

El archivo del módulo permanece en el disco y «modinfo openvswitch» sigue mostrando resultados después. Esto es lo esperado. La regla deja de cargarse; no se elimina nada.

No apliques esto en nodos de computación y de red de OVN o OpenStack Neutron, en clústeres de Kubernetes que utilicen ovn-kubernetes o Antrea, ni en hosts de libvirt y oVirt con puentes basados en OVS. Si bloqueas el módulo en esos entornos, se interrumpirá el funcionamiento de la red.

2. Deniega los espacios de nombres de usuario sin privilegios. Utiliza el parámetro sysctl «user.max_user_namespaces» mencionado anteriormente. Funciona independientemente del estado del módulo, lo que lo convierte en la opción de reserva para los hosts que realmente ejecutan OVS, a costa del fallo en las herramientas «rootless» ya descrito. Pruébalo primero con tus cargas de trabajo.
3. Manéjese con precaución con el mecanismo de protección BPF de terceros. El repositorio público de exploits incluye un mecanismo de protección de emergencia basado en BPF. No lo hemos probado. Revíselo y valídelo en sistemas representativos antes de utilizarlo en producción, y no lo considere equivalente a una corrección del proveedor.

Tras aplicar el parche, elimina la restricción del espacio de nombres si ya no es necesaria:

sudo rm -f /etc/sysctl.d/99-ovswrap.conf

El bloque del módulo puede quedarse. No está vinculado a ninguna versión del núcleo, sobrevive a las actualizaciones y los reinicios, y en un host que no utilice Open vSwitch mantiene cerrada una parte de la superficie de ataque. Documenta esto para que la próxima persona sepa por qué falla la red si ese host llegara a necesitar OVS, y elimínalo entonces con el comando `rm /etc/modprobe.d/99-ovswrap.conf`.

La corrección en el repositorio original es la confirmación 3f1f75536668, «net: openvswitch: rechazar atributos de acciones anidadas de tamaño excesivo».

Añade una validación que rechaza una acción anidada generada cuyo tamaño no pueda representarse de forma segura en nla_len. En lugar de permitir que un valor de tamaño excesivo se trunque a 16 bits, el núcleo detiene la acción no válida durante la validación, antes de que el flujo mal formado llegue a la ruta de datos.

El cambio se produce en la ruta de validación, en lugar de en la ruta rápida de datos. No requiere ninguna migración de estructuras de datos del núcleo ni ningún estado persistente por tarea, lo que lo hace adecuado para la aplicación de parches sin necesidad de reiniciar el sistema.

Aplicar parches y verificar el núcleo en ejecución

La instalación de un paquete del núcleo actualizado no aplica el parche al núcleo que se está ejecutando en memoria. Para realizar una actualización convencional: instala el paquete corregido correspondiente exactamente a tu distribución y versión, reinicia el sistema y comprueba que se está ejecutando el núcleo corregido.

uname -r

Compáralo con el aviso correspondiente del proveedor, no con el paquete más reciente que tengas en el disco. Y no des por sentado que un núcleo compilado después del 24 de julio de 2026 incluya la corrección. Los números de versión de las distribuciones no se corresponden con las versiones originales; la vulnerabilidad llegó a estas ramas mediante una adaptación retrospectiva, y la corrección se adaptó retrospectivamente en momentos distintos.

Parcheo sin reinicio

KernelCare aplica la misma lógica de validación de «upstream» al núcleo activo. Una vez aplicado el parche, OVS rechaza las acciones anidadas generadas que superan el tamaño máximo antes de que la longitud pueda rebobinarse, sin necesidad de desactivar Open vSwitch, modificar la política del módulo ni reiniciar la carga de trabajo. Se trata de un error exclusivo del núcleo, sin ningún componente de biblioteca del espacio de usuario que haya que localizar.

La mayoría de las implementaciones descargan automáticamente los nuevos parches en segundo plano a intervalos fijos, normalmente cada cuatro horas. Para descargarlos bajo demanda desde el canal de producción:

kcarectl --update

En caso de que un parche aún se encuentre en fase de pruebas para tu familia de kernels:

kcarectl --update --prefix test

A continuación, comprueba si el CVE aparece en la información del parche instalado:

kcarectl --patch-info | grep 'CVE-2026-64531'

Comprueba que el parche esté disponible para la versión exacta del núcleo que se está ejecutando antes de eliminar cualquier medida de mitigación temporal. Si aún no se ha implementado la corrección para tu familia, mantén activo el bloqueo del módulo o la restricción del espacio de nombres.

Detección y análisis de incidentes

No hay ningún indicador claro, así que considera todo lo que aquí se expone como una pista más que como una prueba.

La señal más útil es el propio módulo. En un servidor en el que no se utilice Open vSwitch de forma legítima, la aparición de «openvswitch» en «lsmod» ya es de por sí anómala, y merece la pena investigar los registros de auditoría de carga de módulos o las entradas del diario relacionadas con él. Esa señal desaparece una vez que se implementa el bloque «modprobe», así que compruébalo antes de aplicarlo.

A continuación, comprueba qué hace el PoC publicado con su acceso de root:

sudo stat /etc/sudoers /etc/passwd /etc/shadow
sudo find /etc/sudoers.d -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n'

Las entradas inesperadas en el archivo «sudoers» o los archivos nuevos en la carpeta «/etc/sudoers.d/» son vestigios de la prueba de concepto publicada, aunque un atacante con privilegios de root podría saltarse ese paso por completo. Busca también cuentas nuevas o a las que se les hayan concedido privilegios recientemente, claves SSH inexplicables y casos de obtención de privilegios sin que haya ningún evento correspondiente de «sudo», inicio de sesión o autenticación, ya que las credenciales corrompidas mediante una escritura en el núcleo no dejan rastro de autenticación.

Otras pistas relacionadas con el comportamiento: procesos sin privilegios que crean espacios de nombres de usuario y de red cuando ninguna carga de trabajo suele hacerlo; un proceso que se ejecuta con credenciales de root, pero que no se inició como root y no tiene antecesores con setuid; y advertencias del núcleo u «oops» procedentes de la ruta de validación de flujos de OVS, que pueden producirse cuando los intentos fallan.

Todavía no hemos reproducido internamente la prueba de concepto pública en entornos restringidos o en contenedores, así que no des por sentado que el aislamiento por usuario o por contenedor lo contiene sin haber probado esa ruta de llamada al sistema en tu propia configuración.

No. El problema se notificó de forma privada el 19 de junio de 2026; la corrección se incorporó a las ramas estables el 24 de julio, bajo un embargo coordinado; y el informe y la demostración de concepto (PoC) se publicaron el 28 de julio. En la divulgación no se afirma en ningún momento que se haya producido una explotación en el mundo real antes de que existiera una corrección.

Eso no significa que sea una prioridad baja. Una vez que se hizo público el exploit, los atacantes obtuvieron una vía comprobada para pasar de una cuenta local normal a privilegios de root, además de los desplazamientos para una amplia colección de compilaciones del núcleo. Una ventaja de cuatro días solo beneficia a las flotas que ya estaban aplicando rápidamente los parches a los núcleos estables.

Por qué es importante el CVE-2026-64531

Hay tres detalles que hacen que esto se considere fácilmente como algo rutinario, y los tres son engañosos.

Requiere acceso local, por lo que parece un problema de segunda fase, salvo que el acceso local es algo de lo que ya disponen los inquilinos, los ejecutores de CI y las dependencias no fiables. Requiere Open vSwitch, por lo que parece un problema de red específico, salvo que el módulo se carga automáticamente cuando se solicita. Y requiere un espacio de nombres de usuario sin privilegios, por lo que parece algo que ya cubren las medidas de refuerzo existentes, salvo que el refuerzo específico en el que confían la mayoría de los equipos de Debian y Ubuntu en este caso no funciona.

El historial de versiones nos ofrece otra lección. Un cambio que eliminó un límite de tamaño en marzo de 2025 convirtió una asignación inactiva desde hacía una década en una escalada de privilegios activa, y llegó a las ramas a largo plazo como una adaptación hacia atrás ordinaria, en lugar de como una versión oficial. Una cola de clasificación basada únicamente en los números de versión de upstream habría considerado que esos núcleos quedaban fuera del periodo de aplicación.

En el caso de los sistemas parcheados de forma convencional, instala la actualización del proveedor y comprueba que el host arranca con ella. En las flotas en las que los reinicios de emergencia suponen un riesgo operativo, KernelCare cierra la ruta de validación vulnerable en el kernel en ejecución sin desconectar los sistemas. En cualquier caso, la solución más económica hoy en día es bloquear el módulo en todos los hosts que no utilicen OVS: es reversible, tiene un impacto mínimo y elimina la ruta de código en lugar de intentar sortearla.

Consigue KernelCare hoy mismo →

Cronología

Referencias

• Asim Manizada, OVSwrap disclosure, oss-security, 28 de julio de 2026, y el servidor espejo de seclists
• Documento técnico sobre OVSwrap: https://heyitsas.im/posts/ovswrap
• Prueba de concepto pública de OVSwrap y protección BPF: https://github.com/manizada/OVSwrap
• Corrección de Linux en el código fuente 3f1f75536668, «net: openvswitch: rechazar atributos de acciones anidadas de tamaño excesivo»
• Anuncio de Linux sobre el CVE-2026-64531
• Entrada de CVE, CVE-2026-64531
• Avisos de seguridad aplicables a RHEL, AlmaLinux, Rocky Linux, CloudLinux, Debian, Ubuntu y Amazon Linux