Laravel ha corregido un fallo crítico en TokenGuard, su sistema integrado de autenticación por token para APIs, que permite a un atacante sin credenciales entrar como cualquier usuario existente cuando la aplicación usa MySQL o MariaDB. El aviso de seguridad GHSA-f9x3-7vq9-cph6, publicado el 19 de octubre, le asigna una puntuación CVSS 4.0 de 9,2 sobre 10. Afecta a las versiones de laravel/framework anteriores a la 12.68.0 y a la 13.29.0, que son las que incluyen la corrección.
Las claves del fallo de autenticación de Laravel en 30 segundos
- El fallo está en TokenGuard, el guard de tipo token que Laravel incluye para autenticar APIs con un token guardado en la base de datos.
- Enviando una credencial que no es una cadena de texto, un atacante puede autenticarse como otro usuario con MySQL o MariaDB.
- Está corregido en Laravel 12.68.0 y 13.29.0; Laravel 11 y anteriores ya no reciben parches.
- Sanctum y Passport usan sus propios guards y no aparecen en el aviso.
Según el aviso del propio equipo de Laravel, cuando una aplicación usa el guard estándar basado en token, un atacante puede enviar un valor de credencial manipulado que no es una cadena de texto. Ese valor se gestiona mal durante la búsqueda del usuario, y la consulta a la base de datos acaba coincidiendo con un registro que no corresponde, en lugar de fallar. El resultado es una suplantación de identidad completa en cualquier ruta protegida por ese guard, sin necesidad de conocer el token de la víctima. El fallo lo comunicó un investigador que firma en GitHub como KIKOmanasijev. El aviso de GitHub no asigna CVE, aunque otras bases de datos de vulnerabilidades lo registran como CVE-2026-114509.
Por qué la base de datos acaba aceptando un token falso
El análisis técnico publicado por la empresa de seguridad Corgea explica el origen. TokenGuard solo comprobaba que el token recibido no estuviera vacío, pero no que fuera una cadena de texto. Si el cliente envía, por ejemplo, un array en lugar de un texto, el valor que llega a la consulta SQL acaba siendo un número. MySQL y MariaDB, al comparar una columna de texto con un número, convierten el texto a número, y un token que empieza por una letra se interpreta como cero. Así, la condición se cumple con el primer usuario cuyo token encaje, y el atacante queda autenticado como él.
Hay condiciones para que el ataque funcione. Según Corgea, hace falta usar el guard token con los tokens guardados sin hash ('hash' => false) y una base de datos MySQL o MariaDB. Si los tokens se guardan con hash, PHP 8 lanza un error al intentar calcular el hash de un array y el ataque no prospera. La corrección añade una comprobación explícita de que el token sea una cadena antes de usarlo. Laravel publicó en paralelo otro aviso que afecta a las aplicaciones que usan sus recursos JSON:API, en el que el parámetro include podía llegar a vaciar tablas relacionadas, corregido en las versiones 12.68.0 y 13.27.0.
Qué hacer si tu aplicación usa Laravel
Lo primero es comprobar si la aplicación usa ese guard. Basta con revisar el fichero config/auth.php y buscar algún guard con 'driver' => 'token', a menudo heredado de versiones antiguas para una API concreta. Laravel Sanctum y Laravel Passport, las opciones más habituales hoy para autenticar APIs, tienen sus propios guards y no figuran entre los componentes afectados. En cualquier caso, lo recomendable es actualizar a Laravel 12.68.0 o 13.29.0 o posterior con Composer y desplegar de nuevo, porque esas versiones corrigen también el fallo de JSON:API.
El problema es mayor para quien sigue en versiones antiguas. Laravel 11 dejó de recibir parches de seguridad en marzo de 2026 y Laravel 10, en febrero de 2025, así que no hay versión corregida para ellas. En esos casos, las alternativas son migrar a una versión con soporte, sustituir el guard de token por Sanctum, lo que obliga a revisar cómo se autentican los clientes de la API, o, como medida temporal, rechazar antes de llegar al guard cualquier token que no sea una cadena de texto. Activar el almacenamiento de tokens con hash también corta este vector, aunque obliga a regenerar los tokens existentes. Es otro aviso para quienes mantienen aplicaciones PHP, después de los fallos críticos de PHP2Shell de este mismo mes.
Preguntas frecuentes
¿Qué versiones de Laravel corrigen el fallo de TokenGuard?
Laravel 12.68.0 y 13.29.0 o posteriores. Las versiones anteriores de las ramas 12 y 13 son vulnerables, y Laravel 11 y anteriores no tienen parche.
¿Afecta a Laravel Sanctum o Passport?
El aviso solo menciona el guard de token integrado. Sanctum y Passport usan sus propios guards, pero conviene revisar que no quede ningún guard de token antiguo configurado en la aplicación.
¿Afecta a todas las bases de datos?
No. El aviso habla de determinadas configuraciones de MySQL y MariaDB, por cómo comparan valores de distinto tipo.
¿Cómo sé si mi aplicación usa TokenGuard?
Revisando config/auth.php: si algún guard tiene 'driver' => 'token', la aplicación lo usa.
Fuentes:
