Investigadores han presentado una nueva variante de ataque de la familia Spectre v2, denominada Branch Target Reuse (BTR), que afecta a procesadores Intel, AMD y Arm y permite, a través de motores JIT y del kernel de Linux, extraer secretos de la memoria, hasta el hash de la contraseña de root, en cuestión de minutos. Son vulnerables todos los entornos en los que código no confiable pueda ejecutar JIT o utilizar filtros/programas en el kernel (por ejemplo, cBPF), y la protección requiere actualizar el kernel de Linux (CVE-2026-64507, CVE-2026-64508), configurar barreras de hardware para el predictor de saltos y revisar la política de uso de JIT en entornos aislados.
Detalles técnicos del ataque Branch Target Reuse
El ataque BTR ha sido descrito por investigadores de VUSec y Scuola Superiore Sant’Anna y se analiza en detalle en la página del proyecto Branch Target Reuse. En esencia, es una evolución de Spectre v2: el atacante no solo envenena el predictor de saltos indirectos, sino que también aprovecha el hecho de que el estado del predictor vive más tiempo que el código máquina correspondiente en la memoria.
El mecanismo clave es el siguiente:
- los saltos indirectos (indirect branch) se almacenan en el predictor de saltos junto con el destino del salto;
- el JIT o el kernel liberan la página con el código y luego usan la misma dirección de memoria para nuevo código;
- el predictor sigue almacenando el destino «antiguo» del salto, que pertenece al código ya liberado;
- al ejecutar el nuevo código, el procesador puede saltar especulativamente al destino obsoleto y ejecutar un fragmento ventajoso para el atacante.
Los autores caracterizan esto como un «execute-after-free» especulativo para código: incluso después de liberar y reutilizar la memoria, la bifurcación sigue apuntando especulativamente al fragmento antiguo hasta que se limpie el predictor.
Explotación a través de cBPF en el kernel de Linux
Como escenario práctico, los investigadores demostraron el ataque sobre la compilación JIT del clásico BPF (cBPF) en el kernel de Linux. El motor JIT en el kernel genera código máquina de los filtros en memoria y puede luego liberar y reutilizar esas mismas páginas: condiciones ideales para BTR.
Se han desarrollado dos exploits de prueba de concepto para Linux:
- para la configuración por defecto del kernel;
- para la configuración con la protección constant blinding activada (dificulta el control directo de constantes en el código generado).
En la primera variante se explota una secuencia sencilla:
- el atacante carga un primer programa cBPF cuya tarea es «entrenar» el predictor de saltos con un patrón concreto de saltos indirectos;
- este programa se elimina, liberando la memoria con el código;
- en el mismo rango de direcciones se coloca un segundo programa cBPF, diseñado para filtrar datos a través de un canal lateral;
- el predictor de saltos sigue almacenando el destino del salto indirecto del primer programa, y la CPU ejecuta especulativamente un fragmento útil para el atacante en el segundo programa.
Esto basta para leer memoria arbitraria a una velocidad del orden de 8 bytes por segundo. En la demostración, los investigadores localizaban el proceso su y extraían de su memoria el hash de la contraseña de root, empleando para el ataque apenas unos minutos.
En la segunda variante del exploit, en un sistema con constant blinding activado, los investigadores codificaban instrucciones controladas en los desplazamientos de los saltos. Pese a la mayor complejidad, también lograban extraer el hash de la contraseña de root en menos de cinco minutos. En procesadores con microarquitecturas Raptor Cove y Lion Cove, el tiempo medio de ataque fue de unos tres y cinco minutos, respectivamente.
Los problemas relacionados del kernel de Linux han recibido los identificadores CVE-2026-64507 y CVE-2026-64508. La descripción de las vulnerabilidades está disponible tanto en la lista de correo de Linux CVE-2026-64507 y CVE-2026-64508, como en la base NVD: CVE-2026-64507 en NVD, CVE-2026-64508 en NVD.
Intentos de atacar SpiderMonkey y GraalVM
BTR también se probó contra motores JIT de más alto nivel:
- SpiderMonkey (motor JavaScript de Firefox): las predicciones obsoletas efectivamente «sobrevivían» a la reutilización de la memoria, lo que confirma la naturaleza fundamental del efecto. Sin embargo, no se logró crear un exploit completo a nivel de navegador: lo impiden mecanismos de protección adicionales y la compleja dinámica interna del navegador.
- Oracle GraalVM: los investigadores consiguieron eludir especulativamente el mecanismo de enmascaramiento de direcciones de memoria, diseñado precisamente para proteger la sandbox frente a ataques similares a Spectre. No obstante, no se llegó a un ataque funcional: la actividad en segundo plano de GraalVM limpiaba las entradas del predictor demasiado rápido.
La conclusión clave es que el efecto Branch Target Reuse se reproduce en todos los procesadores Intel, AMD y Arm probados y se manifiesta en distintos tipos de JIT, incluso cuando sus propias defensas internas son bastante agresivas.
La barrera de hardware Indirect Branch Predictor Barrier (IBPB), descrita en la guía de Intel Software Security Guidance: Indirect Branch Predictor Barrier, dificulta la explotación de BTR, pero a costa de una pérdida de rendimiento notable.
Contexto de la amenaza: el lugar de BTR en la familia Spectre
BTR no es un nuevo «agujero» en un producto concreto, sino una demostración de una limitación sistémica de las microarquitecturas modernas. Las técnicas de Spectre v2 se consideran por parte de los proveedores como «cerradas» desde hace años, gracias a una combinación de barreras, retpoline y modificaciones de compiladores. BTR muestra que, incluso con estas medidas, el predictor de saltos sigue mal sincronizado con el ciclo de vida del código en memoria.
Consecuencias importantes:
- cualquier plataforma donde código no confiable pueda iniciar la generación y descarga de código JIT es potencialmente vulnerable: navegadores, máquinas virtuales Java, .NET, GraalVM, motores de smart contracts, motores de expresiones regulares en bases de datos, etc.;
- el kernel del sistema operativo no es una excepción: el JIT en subsistemas de filtrado de paquetes (cBPF, eBPF) se convierte en otro canal de fuga de secretos entre procesos;
- las fronteras clásicas «proceso — espacio de direcciones» se debilitan: un atacante con pocos privilegios puede leer datos de un proceso con mayores privilegios o del propio kernel, sin recurrir a errores directos de acceso a memoria.
La investigación no aporta ejemplos de explotación en entornos reales ni vincula BTR con actores de amenazas u operaciones concretas, pero la experiencia con la evolución de Spectre y Meltdown muestra que, a medida que estas técnicas se simplifican y optimizan, ataques similares acaban entrando en el arsenal de grupos avanzados.
Evaluación del impacto en organizaciones e infraestructuras
El mayor riesgo de BTR se da en escenarios de uso compartido de recursos y aislamiento complejo:
- servidores de propósito general y virtualización, especialmente en entornos donde contenedores o máquinas virtuales de clientes puedan cargar sus propios filtros o programas en los subsistemas BPF del kernel;
- estaciones de trabajo de desarrolladores y sistemas con uso intensivo de GraalVM, JVM y otros JIT: mayor probabilidad de abuso local dentro de una misma máquina;
- navegadores corporativos: en despliegues masivos de Firefox, es importante la madurez del aislamiento de sitios, que reduce el valor de canales laterales entre sitios;
- sistemas con secretos de alta sensibilidad en memoria (claves de cifrado, tokens de acceso, contraseñas administrativas): incluso un canal de fuga lento de unos pocos bytes por segundo es peligroso.
Si no se toman medidas, las posibles consecuencias incluyen:
- extracción de hashes de contraseñas de cuentas privilegiadas y posterior descifrado offline de las contraseñas;
- robo de claves criptográficas, tokens de acceso y otros secretos de larga duración de procesos de aplicaciones o servicios;
- debilitamiento silencioso de los modelos de confianza «código con pocos privilegios — datos con altos privilegios», incluso dentro de sandbox y contenedores;
- riesgos regulatorios si la fuga afecta a datos sujetos a requisitos sectoriales o gubernamentales.
Recomendaciones prácticas de protección
1. Actualización del kernel de Linux
Los problemas descritos en CVE-2026-64507 y CVE-2026-64508 ya se han corregido en el kernel de Linux. Pasos recomendados:
- verificar que el distribuidor utilizado haya incorporado los parches para las CVE mencionadas;
- comprobar la presencia de estas vulnerabilidades en los boletines del proveedor y en NVD: CVE-2026-64507, CVE-2026-64508;
- priorizar la actualización de servidores donde los subsistemas BPF estén disponibles para usuarios sin privilegios.
Hasta aplicar la actualización, es razonable:
- limitar el derecho a cargar programas BPF únicamente a cuentas administrativas;
- evaluar la posibilidad de desactivar temporalmente el JIT para cBPF/eBPF en entornos de alta sensibilidad, si la carga de trabajo lo permite.
2. Uso de barreras de hardware del predictor
En segmentos de alto riesgo (servidores con múltiples niveles de confianza, sistemas de tratamiento de datos sensibles), considere activar mecanismos como IBPB. La guía de Intel sobre IBPB está disponible en el enlace Indirect Branch Predictor Barrier.
En la práctica:
- active IBPB solo para procesos pertenecientes a distintos dominios de confianza (por ejemplo, al cambiar de un cliente no confiable a un proceso que trabaje con datos sectoriales o gubernamentales);
- pruebe el impacto en el rendimiento bajo cargas de trabajo típicas antes de una activación masiva.
3. Gestión de JIT y aislamiento en espacio de usuario
- para navegadores Firefox, asegúrese de usar las últimas versiones con aislamiento de sitios completo, lo que reduce el valor de posibles canales laterales entre pestañas;
- en entornos con GraalVM y otras máquinas virtuales Java, instale las actualizaciones de Oracle y siga sus recomendaciones de protección frente a ataques tipo Spectre;
- revise la política de activación de JIT en escenarios donde sea aceptable desactivarlo (por ejemplo, instancias de servidor especializadas sin necesidad de máximo rendimiento en scripts).
4. Monitorización y medidas operativas
Aunque los ataques por canales laterales son difíciles de detectar directamente, es posible controlar indicios auxiliares:
- patrones inusuales de carga y descarga de programas BPF del kernel, especialmente desde usuarios sin privilegios;
- uso anómalo de utilidades de elevación de privilegios (como
su) en servidores de aplicaciones; - generación y actualización frecuente de un gran número de programas JIT en contextos no confiables.
En términos estratégicos, BTR es un motivo para reforzar la segmentación: es preferible almacenar los secretos más críticos en sistemas donde código no confiable (incluidos contenedores de clientes y runtimes con JIT) no se ejecute en absoluto.
BTR demuestra que la familia Spectre v2 sigue vigente incluso tras varias oleadas de defensas, y que los predictores de saltos de los procesadores modernos fundamentalmente no pueden seguir el ritmo de la dinámica del JIT y del kernel. En la práctica, ahora es importante: actualizar el kernel de Linux a versiones con correcciones para CVE-2026-64507 y CVE-2026-64508, activar en lo posible barreras de predictor de hardware para nodos críticos, limitar el uso de JIT y BPF en contextos no confiables y revisar la arquitectura de aislamiento allí donde distintos dominios de confianza coexisten en el mismo «hardware».
