Laravel publicó el aviso crítico GHSA-f9x3-7vq9-cph6 sobre un bypass de autenticación en TokenGuard. La prioridad es revisar cómo autentica tu API y qué versión está desplegada, no asumir que cualquier aplicación con Laravel está expuesta.
Fuentes revisadas el 19 de octubre de 2026. El aviso tiene una puntuación CVSS 4.0 de 9.2 y todavía figura sin CVE asignado. Describe suplantación de usuarios sin su token válido bajo ciertas configuraciones MySQL/MariaDB. No ofrece un recuento de víctimas. Aviso oficial de Laravel.
Qué significa el fallo para tu aplicación
Un guard decide cómo reconocer al usuario de una petición. El nombre de un guard, como api, no identifica necesariamente su implementación: hay que revisar su driver. Laravel distingue la autenticación por sesión de las soluciones API Sanctum y Passport. No son nombres intercambiables con el TokenGuard incorporado. Documentación de autenticación.
El problema consiste en aceptar una credencial de tipo inadecuado durante una búsqueda de autenticación. Una consulta puede terminar asociando la petición a una cuenta que no corresponde. Esto no significa que un atacante obtenga automáticamente acceso root al servidor ni que todas las rutas de la aplicación queden abiertas.
Ilustración generada con IA, no evidencia de un ataque. 1: entrada de autenticación. 2: comprobación insuficiente. 3: identidad asociada incorrectamente.
Ejemplo hipotético: una API de facturación reconoce por error una solicitud como perteneciente a otro cliente. Si la ruta permite consultar sus facturas, puede exponerlas; si permite modificarlas, el impacto puede ser mayor. Lo determinan las operaciones y permisos disponibles, no solo la presencia de Laravel.
Versiones corregidas: Laravel 12.68.0 y 13.29.0
| Rama | Versiones anteriores al arreglo | Mínimo corregido indicado |
|---|---|---|
| Laravel 12.x | 12.x anterior a 12.68.0 | 12.68.0 |
| Laravel 13.x | 13.x anterior a 13.29.0 | 13.29.0 |
Son mínimos para este aviso, no una recomendación de detener futuras actualizaciones. El aviso no proporciona aquí una versión corregida para ramas anteriores: no las des por protegidas ni instales una versión mayor sin revisar compatibilidad.
La publicación del aviso no es la fecha del lanzamiento del parche. Las páginas de Laravel 12.68.0 y Laravel 13.29.0 muestran lanzamientos del 25 de agosto. Por eso una aplicación ya actualizada puede incorporar la corrección antes de conocer esta alerta.
Qué comprobamos en el código oficial
Revisamos TokenGuard.php en ambas versiones señaladas. En user(), la búsqueda exige un token de tipo string no vacío; validate() también rechaza credenciales que no cumplen esa condición. Es una comprobación de tipos antes de consultar al proveedor de usuarios, no un cambio de contraseña ni un parche del sistema operativo. Código 12.68.0 · Código 13.29.0.
Método y límite: inspección estática de esos dos archivos el 19 de octubre. No ejecutamos un exploit, no probamos configuraciones de bases de datos y no auditamos aplicaciones de clientes.
Cómo revisar si necesitas actuar
Trabaja en el proyecto correcto: un mismo VPS puede alojar varias aplicaciones con dependencias distintas.
1. Compara lo instalado con lo registrado
composer show laravel/framework
composer show laravel/framework --locked
composer audit --locked
show informa de lo instalado; --locked consulta composer.lock. Si difieren, investiga el despliegue. audit ayuda a encontrar avisos conocidos, pero una salida sin alertas no analiza tus rutas ni garantiza ausencia de vulnerabilidades. Referencia de comandos de Composer.
2. Revisa el guard efectivo y las rutas
Abre config/auth.php y busca guards cuyo driver sea token. Revisa también registros personalizados y la configuración efectiva desplegada; el archivo editado puede no coincidir con una configuración cacheada.
Tu proyecto Laravel, en un VPS de TERAMONT
Elige recursos para tu aplicación y planifica sus despliegues. Mantener Laravel y sus dependencias al día sigue siendo parte de administrar tu proyecto.
php artisan route:list -vv
Localiza qué middleware protege cada endpoint y resuelve su guard. auth:api por sí solo no demuestra uso de TokenGuard; tampoco lo demuestra que la URL empiece por /api. El listado detallado ayuda a expandir grupos de middleware. No publiques su salida si contiene rutas internas. Listado de rutas en Laravel.
3. Usa una decisión, no una conclusión automática
- Versión anterior al arreglo y driver token: prioriza la actualización y revisa la configuración de base de datos con el equipo responsable.
- Solo Sanctum, Passport o sesión en las rutas revisadas: no has identificado la ruta de código descrita aquí. Comprueba que no quede otro guard token en endpoints secundarios.
- Versión corregida en el repositorio, pero despliegue sin confirmar: comprueba cada instancia que atiende tráfico; el lockfile por sí solo no acredita lo ejecutado.
Cómo actualizar con un despliegue verificable
Primero prepara una copia recuperable y una rama de trabajo. En desarrollo o staging, revisa las restricciones de composer.json y simula la actualización:
composer update laravel/framework --with-all-dependencies --dry-run
Comprueba que el resultado alcanza el mínimo de tu rama. La opción de dependencias puede cambiar otros paquetes: revisa el conjunto antes de continuar. Si hay un bloqueo de compatibilidad, resuélvelo; no desactives controles de seguridad ni ignores requisitos de PHP para forzar la instalación.
Una vez revisado, aplica en ese entorno y ejecuta las pruebas del proyecto:
composer update laravel/framework --with-all-dependencies
php artisan test
Guarda y revisa el cambio de composer.lock. Despliega ese artefacto probado mediante tu proceso habitual. La documentación de Laravel indica que los procesos de larga duración deben recargarse para usar el código nuevo: comprueba especialmente Octane y workers, además de cualquier política de OPcache de tu entorno. Reconstruye la configuración cacheada si la modificaste. Guía oficial de despliegue.
Pruebas de aceptación recomendadas
En staging, con cuentas de prueba y operaciones de solo lectura, comprueba que una petición sin credenciales o con token inválido sea rechazada, que un token válido conserve la identidad esperada y que un usuario no pueda acceder a recursos ajenos. Añade casos que rechacen tipos de credencial inesperados. Son propuestas de prueba, no resultados que afirmemos haber obtenido en tu aplicación.
Qué hacer mientras actualizas y si sospechas un incidente
Si no puedes desplegar inmediatamente, considera restringir temporalmente los endpoints afectados a una red privada o deshabilitarlos, evaluando el impacto sobre clientes e integraciones. Es contención operativa, no una corrección oficial equivalente. Rotar tokens o cambiar contraseñas no sustituye arreglar una comprobación de autenticación.
Conserva logs y revisa acciones sensibles, identidades y patrones de acceso anómalos. No empieces a registrar tokens completos para investigar. Si confirmas suplantación, revisa las acciones realizadas y revoca las credenciales o sesiones comprometidas según tu plan de respuesta. La ausencia de registros sospechosos no demuestra que nunca hubiera acceso indebido.
Si usas un VPS: quién debe aplicar el parche
Aquí se actualiza Laravel dentro de la aplicación. Actualizar Debian, PHP o el kernel del host no reemplaza esa tarea. En un VPS autoadministrado corresponde al responsable del proyecto; si contrataste administración de aplicaciones, pide confirmación del despliegue y sus pruebas.
Puedes alojar tu proyecto en un VPS Hosting de TERAMONT, pero cambiar de proveedor no corrige automáticamente tus dependencias. Elige recursos para tu carga y mantén una rutina de actualización y verificación. Si estás empezando, consulta qué es un VPS y qué responsabilidades implica.
