Laravel corrige un fallo crítico de autenticación en TokenGuard

Los mantenedores del framework publicaron el 19 de octubre el aviso GHSA-f9x3-7vq9-cph6, que describe un fallo crítico (CVSS 9.2) en TokenGuard, el guardián de autenticación por token integrado en Laravel. En bases MySQL o MariaDB, un atacante sin autenticar podía suplantar a cualquier usuario existente sin conocer su token de API. El parche, por su parte, se había publicado discretamente dos meses antes, en las versiones 12.68.0 y 13.29.0.

#Un parche publicado antes de su propia divulgación

Las versiones 12.68.0 y 13.29.0 salieron el 25 de agosto de 2026. En su momento, las notas de versión no dejaban entrever la gravedad de lo que acababan de corregir. No fue hasta el 19 de octubre, casi dos meses después, cuando el aviso GHSA-f9x3-7vq9-cph6 detalló el riesgo real, siguiendo un calendario de divulgación cada vez más habitual entre los mantenedores de frameworks: corregir en silencio, dar tiempo a los equipos para actualizar y documentar el riesgo públicamente después. La última versión mayor del framework, la versión 13.36, ya había reforzado la fiabilidad de los workers de colas; la 13.29, que corrige TokenGuard, queda unas versiones antes en la misma rama.

#El mecanismo del fallo

TokenGuard es el guardián de autenticación más simple que ofrece Laravel para proteger una API: compara el token enviado por el cliente con el almacenado para ese usuario. Antes del parche, la clase solo comprobaba que el token no estuviera vacío antes de pasarlo al proveedor de usuarios. Un atacante podía enviar un valor de credencial no textual, especialmente construido, que la consulta en base de datos interpretaba de forma inesperada en MySQL y MariaDB, llegando a hacer coincidir un registro de usuario no deseado.

// config/auth.php — configuración expuesta
'api' => [
    'driver'   => 'token',
    'provider' => 'users',
],

// Antes del parche: solo se comprobaba que no estuviera vacío
if (empty($token)) {
    return null;
}
$user = $provider->retrieveByCredentials(['api_token' => $token]);

// Desde 12.68.0 / 13.29.0: se rechazan los valores no textuales
if (empty($token) || ! is_string($token)) {
    return null;
}

#Quién está expuesto

Solo las aplicaciones que declaran un guardián con el driver token en config/auth.php están afectadas, y únicamente en MySQL o MariaDB. Laravel Sanctum y Laravel Passport registran sus propios drivers de guardián y no están cubiertos por este aviso.

Dos meses separan el parche silencioso de su divulgación pública, un plazo inusual para un fallo que permitía a un atacante sin autenticar hacerse pasar por cualquier usuario.

#Cómo reaccionar

La corrección consiste en actualizar la versión: ejecutar composer update laravel/framework hacia 12.68.0, 13.29.0 o una versión posterior. Los equipos pueden después revisar config/auth.php para localizar cualquier guardián configurado con el driver token, priorizando las aplicaciones alojadas en MySQL o MariaDB. Pasar regularmente composer audit, junto a otras herramientas de línea de comandos que forman parte de una rutina de desarrollo sólida, habría permitido detectar el aviso en cuanto se publicó. En términos más generales, este fallo recuerda que un token de API es en sí mismo una forma de secreto de aplicación, que merece el mismo rigor que las variables de entorno y credenciales de un proyecto.

#Lo que hay que recordar

• TokenGuard, el guardián de autenticación por token de Laravel, era vulnerable a la suplantación de cuentas en MySQL y MariaDB antes de las versiones 12.68.0 y 13.29.0.
• El parche salió el 25 de agosto de 2026, pero el aviso público no se publicó hasta el 19 de octubre.
• Sanctum y Passport no están afectados; solo lo están los guardianes que usan explícitamente el driver token.
• Una sola actualización de laravel/framework corrige también el segundo aviso sobre JSON:API.

#Para profundizar

Aviso de seguridad completo: GHSA-f9x3-7vq9-cph6 en GitHub.