Laravel corrige una vulnerabilidad crítica de autenticación en TokenGuard (GHSA-f9x3-7vq9-cph6)

El 19 de octubre de 2026, el equipo de Laravel publicó el aviso de seguridad GHSA-f9x3-7vq9-cph6, una vulnerabilidad crítica en el guard de autenticación basado en tokens, conocido como TokenGuard.

Según el aviso, un atacante sin credenciales puede enviar un valor especialmente construido que no es un texto. La aplicación lo procesa de forma incorrecta durante la consulta de autenticación y puede terminar coincidiendo con un usuario distinto. El resultado es que el atacante actúa como ese usuario sin conocer su token.

La falla ya está corregida. La solución es actualizar laravel/framework a una versión que incluya el parche.

Resumen rápido

• Aviso: GHSA-f9x3-7vq9-cph6, publicado el 19 de octubre de 2026.
• Severidad: crítica, con una puntuación CVSS v4 de 9.2.
• Al momento de escribir este artículo, el aviso no tiene un CVE asignado.
• Componente afectado: el TokenGuard integrado de Laravel.
• Afecta a aplicaciones que usan MySQL o MariaDB, bajo ciertas configuraciones de base de datos.
• El atacante no necesita estar autenticado ni requiere interacción de ningún usuario.
• Versiones corregidas: 12.68.0 y 13.29.0.
• El aviso no ofrece una solución temporal: la única corrección indicada es actualizar.

¿Qué es TokenGuard?

En Laravel, un guard define cómo se identifica a la persona que hace una petición. El TokenGuard es el guard integrado que identifica al usuario a partir de un token enviado en la petición.

No debe confundirse con otros paquetes de autenticación que tienen su propio mecanismo. El aviso habla del TokenGuard estándar del framework y no menciona Sanctum ni Passport. Por eso lo correcto es revisar qué guards usa tu aplicación y no asumir nada.

¿Qué impacto puede tener?

Cualquier ruta protegida por el guard afectado podría quedar expuesta. Si un atacante consigue actuar como otro usuario, puede acceder a los datos de esa cuenta y ejecutar las acciones que esa cuenta tenga permitidas.

Es importante entender el alcance: se trata de una falla dentro de la aplicación. No implica acceso al servidor ni permisos de administrador del sistema operativo.

Versiones afectadas y corregidas

El aviso solo menciona estas dos ramas. Si tu proyecto usa una versión más antigua, consulta el aviso oficial antes de dar el tema por cerrado.

¿Cómo saber si tengo que actuar?

1. Revisar la versión instalada

bash
composer show laravel/framework
php artisan --version

Compara el resultado con la tabla anterior.

2. Revisar los guards configurados

Abre config/auth.php y busca guards con el driver token:

php
'guards' => [
    'api' => [
        'driver' => 'token',
        'provider' => 'users',
    ],
],

3. Revisar las rutas protegidas

Busca rutas que usen ese guard, por ejemplo con auth:api.

4. Revisar la base de datos

El aviso indica que el problema afecta a aplicaciones con MySQL o MariaDB.

Cómo interpretar el resultado

text
Versión afectada + guard token + MySQL/MariaDB
        ↓
Prioridad alta: actualizar de inmediato

Versión afectada, sin guard token
        ↓
Actualizar igualmente en la próxima ventana de despliegue

Aunque no uses el guard afectado, conviene actualizar: las versiones corregidas también traen otras correcciones de seguridad y mantenimiento.

Cómo mitigarla

La única mitigación indicada por el aviso es actualizar el framework.

1. Actualizar Laravel

bash
composer update laravel/framework --with-dependencies

Confirma después la versión instalada:

bash
php artisan --version

2. Probar antes de desplegar

Ejecuta tu suite de pruebas y revisa especialmente el inicio de sesión y las rutas protegidas.

3. Desplegar con las versiones fijadas

Sube el composer.lock actualizado y en el servidor instala exactamente esas versiones:

bash
composer install --no-dev --optimize-autoloader

No ejecutes composer update directamente en producción.

4. Limpiar y regenerar cachés

bash
php artisan config:clear && php artisan config:cache
php artisan route:clear && php artisan route:cache
php artisan view:clear && php artisan view:cache
php artisan queue:restart

El comando queue:restart es importante: los procesos de cola que ya están en ejecución siguen usando el código anterior hasta que se reinician. Si tu servidor usa OPcache con la revalidación desactivada, reinicia también PHP-FPM.

Pruebas de aceptación sugeridas

Después de actualizar, comprueba en un entorno de pruebas que:

• Una petición sin token a una ruta protegida responde 401.
• Un token válido sigue funcionando con normalidad.
• Un token inválido responde 401.
• Enviar el token como arreglo u objeto en lugar de texto no autentica a ningún usuario.

Si sospechas que ya fue explotada

• Revisa los registros de acceso en busca de peticiones extrañas a rutas protegidas.
• Revisa la actividad reciente de las cuentas con más privilegios.
• Rota los tokens de acceso de las cuentas sensibles.
• Que sepamos, el aviso no incluye indicadores de compromiso, por lo que la revisión debe ser general.

¿Afecta a mi VPS o servidor?

La vulnerabilidad está en el código de Laravel que se ejecuta dentro de tu aplicación. No es una falla del sistema operativo, por lo que actualizar los paquetes del servidor no la corrige. Hay que actualizar las dependencias de la aplicación.

Conclusión

GHSA-f9x3-7vq9-cph6 es una vulnerabilidad crítica que permite suplantar a otro usuario en aplicaciones que usan el TokenGuard integrado de Laravel con MySQL o MariaDB. Está corregida en 12.68.0 y 13.29.0.

Los pasos son sencillos: revisa tu versión, comprueba si usas un guard de tipo token, actualiza, prueba y despliega limpiando cachés y reiniciando las colas.

Como el aviso no ofrece una solución temporal, esperar solo prolonga la exposición.

Nota: Este artículo se basa en el aviso oficial GHSA-f9x3-7vq9-cph6, publicado por el equipo de Laravel el 19 de octubre de 2026 y reportado por KIKOmanasijev. Los detalles pueden actualizarse con el tiempo. Antes de actuar, consulta el aviso original: https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6