Investigadores del MIT han reabierto uno de los capítulos más incómodos de la seguridad de los sistemas modernos. Bautizada como TONTOU —acrónimo de Time-of-Neutralization to Time-of-Use—, la técnica explota una ventana mínima para reenvenenar el predictor de bifurcaciones de la CPU después de que una mitigación de Spectre v2 neutraliza la amenaza, pero antes de que el kernel utilice la bifurcación. El resultado es inquietante: en un host AMD Zen 2 con Linux y las protecciones más recientes, los investigadores leyeron memoria del kernel a unos 5,47 bytes por segundo, con un 91,97 % de precisión, y localizaron /etc/shadow, que guarda los hashes de contraseña, en cinco de diez intentos.
Para entender el impacto, conviene recordar qué es Spectre v2, también conocido como Branch Target Injection (BTI). Los procesadores ejecutan instrucciones de forma especulativa, adivinando los destinos de las bifurcaciones indirectas mediante un buffer de predicción de ramas (BTB). Cuando la predicción falla, el estado arquitectónico se descarta, pero los efectos secundarios en la caché permanecen. Esas huellas temporales permiten reconstruir datos secretos que nunca deberían haberse leído.
Las defensas conocidas, como el eIBRS de Intel y el Safe RET de AMD, neutralizan el BTB: limpian o restringen los destinos especulativos en la transición entre el espacio de usuario y el kernel. Aquí entra TONTOU. La defensa neutraliza el predictor en un instante, pero el kernel solo consume la bifurcación unos ciclos después. En ese intervalo —en Zen 2, apenas dos instrucciones, seis bytes— el atacante inyecta una interrupción de temporizador y reenvenena el BTB antes de su uso.
El ataque se desarrolla en etapas: neutralización, redirección, envenenamiento y uso. La víctima redirige el flujo especulativo hacia un gadget que filtra datos por un canal lateral. Como muestran los autores en USENIX Security 2026, la técnica esquiva las premisas del Safe RET y del eIBRS por igual.
TONTOU no es un fenómeno aislado; es un eslabón de una larga cadena. Desde Spectre y Meltdown en 2018, la industria lidió con Retbleed, Inception y variantes del mismo principio: la especulación es demasiado eficiente para abandonarla, pero cada mitigación de software crea ventanas que los ataques explotan.
¿ qué las mitigaciones siguen siendo superadas? Porque el problema es estructural. Arreglar de verdad el microprocesador exigiría rediseñar la predicción de bifurcaciones, coste que los fabricantes se resisten a pagar. La solución recae en barreras de software, parches que cubren los flujos conocidos, pero no todos los posibles entre neutralización y uso.
Para los sistemas Linux y los entornos de nube, la gravedad es alta. El exploit requiere acceso local sin privilegios, pero en infraestructura compartida —contenedores, máquinas virtuales, servidores— ese es el escenario de riesgo. Filtrar hashes y claves de cifrado desde la memoria del kernel compromete el modelo de aislamiento. La CVE-2026-68480 ya ha recibido correcciones en los kernels 6.18.43, 6.6.149 y 6.1.181, y AMD reconoció el impacto en las microarquitecturas Zen 1 a 4.
La mitigación práctica es la receta de siempre: mantener el kernel actualizado, minimizar la exposición local y, donde el riesgo sea alto, aislar cargas de trabajo. La baja tasa de exfiltración todavía limita los ataques en tiempo real, pero la precisión y la localización de archivos concretos hacen real la amenaza.
La pregunta es provocadora: si cada defensa de Spectre v2 creó una nueva ventana, ¿estamos condenados a un interminable juego del gato y el ratón, o llegará el momento en que el rendimiento ceda y la industria rediseñe la predicción de bifurcaciones en la arquitectura?
Fuentes: BleepingComputer, The Hacker News, USENIX Security 2026 (MIT, Privacy Guides, LinuxCompatible
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
