CloudLinux ha publicado el estado de la vulnerabilidad conocida como BTR, una variante de Spectre v2 (CVE-2026-64507 y CVE-2026-64508) que permite a un usuario local no privilegiado leer fragmentos de la memoria del kernel. Según la nota técnica, la explotación no concede acceso root directo, pero puede exponer datos sensibles en memoria que luego deben crackearse fuera del servidor.
Qué es BTR y cómo funciona
BTR (Branch Target Reuse) afecta al compilador just‑in‑time (JIT) del sistema de filtros BPF del kernel Linux. El JIT traduce pequeños programas de filtro (usados por seccomp y sockets) a código máquina y reutiliza páginas de memoria ejecutable para albergar múltiples filtros.
El exploit publicado aprovecha que el procesador mantiene predicciones de salto indirecto incluso después de que la memoria JIT haya sido reutilizada. Un atacante local entrena esa predicción con un programa controlado, libera el programa y fuerza que otro filtro ocupe la misma ranura. La predicción especulativa ejecuta código antiguo o manipulado que deja huellas en la caché del procesador; midiendo tiempos de acceso el atacante recupera datos de memoria del kernel.
Qué cambia y a quién afecta
CloudLinux indica que todas sus versiones excepto CloudLinux 7 compilan los filtros BPF a código nativo por defecto, por lo que son potencialmente afectadas. En CloudLinux 7h y CloudLinux 8 el análisis del código muestra que el ataque publicado no funciona en las implementaciones de esos kernels, y por tanto no requieren la actualización; CloudLinux 7 en general no está afectado porque interpreta los filtros en lugar de compilarlos.
La posibilidad real de explotación también depende del microprocesador: los investigadores demostraron pruebas de concepto en dos microarquitecturas Intel, y la eficacia varía según la familia de CPU. CloudLinux advierte que no existe una manera fiable de determinar desde la configuración del servidor si un equipo concreto es vulnerable, por lo que recomienda tratar como expuestas las versiones afectadas hasta que se instale un kernel corregido.
Estado de la corrección y distribución
No hay un parche propio de CloudLinux independiente del kernel: la corrección upstream consta de dos cambios (de ahí los dos CVE). Uno añade un gancho que permite limpiar las predicciones de salto indirecto antes de reutilizar la memoria JIT; el otro habilita ese gancho en x86, emitiendo una barrera de predicción (IBPB) en todos los núcleos cuando se reutiliza memoria JIT. El arreglo para otras arquitecturas (por ejemplo ARM) no viene nombrado en las correcciones publicadas.
CloudLinux distribuye la solución mediante los kernels de sus proveedores: Red Hat/AlmaLinux para las ramas que los siguen, y Canonical para CloudLinux para Ubuntu 22.04. Red Hat ya clasificó algunos kernels como no afectados (por ejemplo RHEL 8 según su nota), pero para las ramas listadas como afectadas la corrección llegará cuando Red Hat/AlmaLinux/Canonical publiquen sus kernels corregidos y CloudLinux los incorpore a sus flujos habituales.
Qué deben hacer administradores y responsables de sitios
- Tratar como expuestos todos los servidores que ejecuten CloudLinux 8 LTS, 9, 9 LTS, 10 y CloudLinux para Ubuntu 22.04 hasta que el kernel corregido esté instalado, independientemente del procesador.
- Supervisar las páginas de estado y avisos de CloudLinux y de los proveedores de kernel (Red Hat, AlmaLinux, Canonical) para conocer la disponibilidad del parche.
- Una vez disponible, aplicar la actualización de kernel indicada por su flujo (y por KernelCare si se usa: KernelCare seguirá los parches de los proveedores y podrá livepatchear sin reinicio cuando entregue la corrección).
- Si usa KernelCare, comprobar los CVE aplicables con kcarectl –patch-info para verificar que el livepatch contiene las correcciones para CVE-2026-64507 y CVE-2026-64508.
- Reforzar la segregación de procesos: recordar que cualquier proceso local —por ejemplo un worker PHP detrás de un plugin WordPress comprometido— podría iniciar el ataque, así que minimizar la ejecución de código no fiable en el mismo host es buena práctica.
Impacto práctico
La explotación demostrada recupera datos específicos del kernel (por ejemplo el hash de la contraseña de root de un proceso su en ejecución) en minutos, pero la extracción masiva de memoria no es práctica porque la tasa de lectura es muy baja. Aun así, la capacidad de leer valores críticos en memoria convierte a esta vulnerabilidad en una amenaza relevante para entornos de hosting compartido y servidores con cuentas de usuarios no confiables.
CloudLinux mantendrá la entrada en su página de estado y actualizará cada flujo cuando el kernel parcheado esté disponible; hasta entonces la recomendación es vigilar las versiones de kernel y aplicar la actualización del proveedor tan pronto como sea liberada.
Lee también:
- FBI anuncia un nuevo arresto relacionado con el presunto grupo ShinyHunters tras la filtración del portal de empleo
- Campaña GhostAction inyecta flujos maliciosos en repositorios GitHub para robar credenciales
Fuente: CloudLinux
