# Laravel 11 ya no recibe parches: la falla de autenticación de octubre y cómo migrar

> Seguridad Laravel: CVE-2026-114509 deja entrar como otro usuario sin token y Laravel 11 no tendrá parche. Cómo revisar tu composer.lock y migrar a 12 o 13.

Autor: Samuel Hinojosa (CEO & Founder, WITS) · Actualizada: 2026-10-25 · https://security.wits.mx/guias/laravel-11-sin-parches/

## ¿Qué falla de seguridad de Laravel salió en octubre de 2026?

El 19 de octubre de 2026 Laravel publicó CVE-2026-114509, una falla crítica (CVSS 9.2) en el TokenGuard: alguien sin cuenta puede entrar como otro usuario sin conocer su token. Afecta a versiones anteriores a 12.68.0 y a 13.x antes de 13.29.0 con MySQL o MariaDB. Laravel 11 no tendrá parche.

Según el [aviso oficial GHSA-f9x3-7vq9-cph6](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6), el atacante manda una credencial que no es texto. Al buscar al usuario en la base de datos, ese valor se maneja mal y la consulta encuentra el registro de otra persona. El resultado es tomar la cuenta de cualquier usuario en las rutas protegidas por ese guard. El aviso no da medidas temporales: la única corrección es actualizar.

> **¿Ya se está explotando?** Al 25 de octubre de 2026 no hay reportes de explotación y la falla no está en el catálogo de vulnerabilidades explotadas de CISA. Eso no la hace menos urgente: el aviso es público y explica el tipo de valor que dispara el error.

No fue la única. Esta es la lista de avisos de octubre que importan a un proyecto Laravel típico:

| Aviso | Paquete | Gravedad | Afectadas | Corregida en |
|---|---|---|---|---|
| CVE-2026-114509, entrar como otro usuario (TokenGuard) | laravel/framework | crítica, CVSS 9.2 | antes de 12.68.0 y 13.x antes de 13.29.0, con MySQL o MariaDB | 12.68.0 · 13.29.0 |
| CVE-2026-114508, una ruta de lectura puede borrar datos de una tabla relacionada | laravel/framework | media, CVSS 6.5 | desde 12.45.0 y antes de 13.27.0 | 12.68.0 · 13.27.0 |
| GHSA-mhf7-xp6r-6qrc, saltarse «#[Authorize]» | livewire/livewire | media, CVSS 6.5 | desde 4.3.0 y antes de 4.4.8 (3.x no está afectada) | 4.4.8 |
| CVE-2026-108082, una cabecera «Cache-Control» consume CPU (ReDoS) | symfony/http-foundation | sin calificación oficial | 5.4, 6.4, 7.4 y 8.x antes de las versiones corregidas | 5.4.54 · 6.4.48 · 7.4.21 · 8.1.9 |

La segunda falla, según el [aviso GHSA-5wcm-3v2w-8362](https://github.com/laravel/framework/security/advisories/GHSA-5wcm-3v2w-8362), permite que una petición a una ruta de solo lectura vacíe una tabla relacionada, sin permisos de escritura. La de [Livewire](https://github.com/advisories/GHSA-mhf7-xp6r-6qrc) deja ejecutar acciones protegidas con «#[Authorize]» sobre registros ajenos, por ejemplo borrar el comentario de otro usuario. La de [Symfony](https://symfony.com/blog/cve-2026-108082-redos-in-headerutils-split-reachable-through-the-cache-control-request-header) llega a Laravel porque usa ese componente para leer cada petición: una cabecera hecha a propósito gasta casi un segundo de CPU. Ojo: Symfony avisa que la primera versión corregida tenía un error, así que en 6.4, 7.4 y 8.1 hay que llegar a 6.4.48, 7.4.21 u 8.1.9.

## ¿Por qué Laravel 11 no va a recibir el parche?

Porque su soporte terminó. Laravel da 18 meses de correcciones y 2 años de parches de seguridad a cada versión mayor. Laravel 11 salió el 12 de marzo de 2024 y su soporte de seguridad terminó el 12 de marzo de 2026, según la [política de soporte de Laravel](https://laravel.com/docs/12.x/releases). El aviso del TokenGuard cubre todas las versiones anteriores a 12.68.0 y solo publica arreglo para 12 y 13.

| Versión | PHP soportado | Correcciones hasta | Seguridad hasta |
|---|---|---|---|
| Laravel 10 | 8.1 a 8.3 | 6-ago-2024 | 4-feb-2025 |
| Laravel 11 | 8.2 a 8.4 | 3-sep-2025 | 12-mar-2026 |
| Laravel 12 | 8.2 a 8.5 | 13-ago-2026 | 24-feb-2027 |
| Laravel 13 | 8.3 a 8.5 | tercer trimestre de 2027 | primer trimestre de 2028 |

Hay una segunda fecha que pega a los mismos proyectos: PHP 8.2 deja de recibir parches el 31 de diciembre de 2026, según la [tabla de versiones de PHP](https://www.php.net/supported-versions.php). Muchos sistemas en Laravel 11 corren en PHP 8.2. Si es tu caso, conviene planear juntos el cambio de framework y el de PHP. Lo explicamos en [cómo actualizar PHP a 8.4 sin romper producción](https://security.wits.mx/guias/actualizar-php-8-4/).

## ¿Cómo reviso si mi proyecto Laravel está afectado?

Todo está en el archivo «composer.lock», que dice la versión exacta instalada de cada paquete. Revísalo en el servidor de producción, no solo en tu máquina, porque a veces no coinciden.

```
composer show laravel/framework livewire/livewire symfony/http-foundation
composer audit                 # cruza composer.lock con la base de avisos de seguridad
php artisan about              # versión de Laravel, PHP y drivers en uso
grep -n "'driver'" config/auth.php   # ¿algún guard usa el driver 'token'?
```

1. Laravel: si «laravel/framework» está en 11.x o antes, o en 12.x antes de 12.68.0, o en 13.x antes de 13.29.0, estás en el rango del TokenGuard.
2. Configuración: la falla aplica cuando tienes un guard con el driver «token» (el TokenGuard integrado) y tu base de datos es MySQL o MariaDB. Si tu API usa otro mecanismo, el riesgo de esta falla en particular baja, pero el resto de los avisos sigue aplicando.
3. Livewire: si usas la versión 4 entre 4.3.0 y 4.4.7 y tus componentes tienen «#[Authorize]», actualiza a 4.4.8. Mientras tanto, «$this->authorize()» dentro del método no está afectado.
4. Symfony: revisa la versión de «symfony/http-foundation» contra la tabla de arriba.
5. Resto del servidor: la versión de PHP también cuenta. Si corre en una versión afectada por [PHP2Shell](https://security.wits.mx/guias/php2shell-cve-2026-109618/), atiende eso primero.

> **Si no tienes acceso al servidor** Pídele a quien mantiene el sistema el archivo «composer.lock» de producción. Con ese archivo se puede saber qué versiones corren sin entrar al servidor ni ver el código. Desde fuera, el [chequeo gratis](https://security.wits.mx/chequeo-php/) te dice si tu dominio anuncia una versión de PHP vulnerable.

## ¿Cómo migrar de Laravel 11 a 12 y a 13 sin romper la API?

La buena noticia: los saltos de Laravel recientes son chicos. La [guía oficial de 11 a 12](https://laravel.com/docs/12.x/upgrade) estima 5 minutos y la [de 12 a 13](https://laravel.com/docs/13.x/upgrade) 10 minutos para una aplicación limpia. En un sistema real con paquetes de terceros y código de años toma más, pero sigue siendo de días, no de meses. Así lo hacemos por etapas:

1. Sube primero a Laravel 12.68.0 o posterior. Es el paso más corto que cierra el TokenGuard y el borrado de datos, y Laravel 12 tiene parches de seguridad hasta el 24 de febrero de 2027. En «composer.json»: «laravel/framework» a «^12.0», «phpunit/phpunit» a «^11.0» y «pestphp/pest» a «^3.0». Laravel 12 exige Carbon 3.
2. Revisa los cambios de 11 a 12 que suelen pegar: «HasUuids» ahora genera UUID versión 7, la regla «image» ya no acepta SVG por defecto y el disco «local» apunta a «storage/app/private» si no lo defines.
3. Corre las pruebas y un recorrido manual de la API en un ambiente de pruebas: login, emisión de tokens, permisos por rol y las rutas que exponen datos.
4. Publica por etapas y deja listo el regreso: la versión anterior desplegada en paralelo o un despliegue que se revierte en minutos.
5. Después planea Laravel 13. Pide PHP 8.3 o superior, así que va de la mano con dejar PHP 8.2. Los cambios de mayor impacto son la protección CSRF renombrada a «PreventRequestForgery» (ahora valida el origen con la cabecera «Sec-Fetch-Site») y las dependencias: «laravel/tinker» a «^3.0», «phpunit/phpunit» a «^12.0» y «pestphp/pest» a «^4.0».
6. En Laravel 13, decide con cuidado los valores nuevos de seguridad: «serializable_classes» en caché y sesiones en «json». Cambiar la sesión de «php» a «json» cierra la sesión de todos tus usuarios, así que hazlo en una ventana planeada.

Una vez al día con el framework, la seguridad de Laravel se mantiene con poco: «composer audit» en cada despliegue, alertas de tus paquetes y actualizaciones menores cada mes. Publicamos las fallas relevantes de la semana en [alertas](https://security.wits.mx/alertas/).

> **¿Lo revisamos contigo?** Security OS revisa tu «composer.lock», tu configuración de autenticación y la versión de PHP del servidor, con permisos de solo lectura. Te entrega qué falla aplica y cuál no, prepara la actualización a Laravel 12 o 13 por etapas con su plan de regreso y deja evidencia antes y después. Ningún cambio llega a producción sin tu autorización.

Cuéntanos qué versión de Laravel y de PHP usas y dónde está alojado. Si puedes, ten a la mano el composer.lock de producción. [Revisar mi proyecto Laravel](https://security.wits.mx/guias/laravel-11-sin-parches/#contacto)

## Preguntas frecuentes

**¿Qué es CVE-2026-114509?**

Es una falla crítica (CVSS 9.2) en el TokenGuard de Laravel, publicada el 19 de octubre de 2026. Con MySQL o MariaDB, un atacante sin cuenta puede entrar como otro usuario sin conocer su token.

**¿Laravel 11 va a recibir parche para el TokenGuard?**

No. Laravel 11 dejó de recibir parches de seguridad el 12 de marzo de 2026 y el aviso solo publica arreglo para 12.68.0 y 13.29.0. La salida es actualizar a Laravel 12 o 13.

**¿Cómo sé qué versión de Laravel tengo?**

Con «php artisan about» o «composer show laravel/framework» en el servidor. También aparece en el archivo composer.lock, buscando el paquete laravel/framework.

**¿Me afecta si uso PostgreSQL o Sanctum?**

El aviso menciona como afectadas las configuraciones con MySQL y MariaDB y el TokenGuard integrado. Si usas otra base de datos u otro mecanismo de tokens, esta falla en particular no te aplica según el aviso, pero conviene actualizar igual por las otras fallas de octubre.

**¿Ya se está explotando la falla de Laravel?**

Al 25 de octubre de 2026 no hay reportes de explotación y no está en el catálogo KEV de CISA. El aviso es público, así que lo prudente es actualizar ya.

**¿Cuánto tarda migrar de Laravel 11 a 12?**

Laravel estima 5 minutos para una aplicación sin cambios raros. En un sistema real con paquetes de terceros suele ser cuestión de días, sobre todo por las pruebas.

**¿Laravel 13 funciona con PHP 8.2?**

No. Laravel 13 pide PHP 8.3 o superior. Como PHP 8.2 pierde soporte el 31 de diciembre de 2026, conviene planear los dos cambios juntos.

## Fuentes

- [GHSA-f9x3-7vq9-cph6 (CVE-2026-114509): Token-based API guard Auth Bypass](https://github.com/laravel/framework/security/advisories/GHSA-f9x3-7vq9-cph6)
- [GHSA-5wcm-3v2w-8362 (CVE-2026-114508): Unauthorized Data Destruction](https://github.com/laravel/framework/security/advisories/GHSA-5wcm-3v2w-8362)
- [GHSA-mhf7-xp6r-6qrc: Livewire, bypass de #[Authorize]](https://github.com/advisories/GHSA-mhf7-xp6r-6qrc)
- [Symfony: CVE-2026-108082, ReDoS en HeaderUtils::split()](https://symfony.com/blog/cve-2026-108082-redos-in-headerutils-split-reachable-through-the-cache-control-request-header)
- [Symfony: avisos de seguridad](https://symfony.com/blog/category/security-advisories)
- [Laravel: notas de versión y política de soporte](https://laravel.com/docs/12.x/releases)
- [Laravel: guía de actualización de 11.x a 12.0](https://laravel.com/docs/12.x/upgrade)
- [Laravel: guía de actualización de 12.x a 13.0](https://laravel.com/docs/13.x/upgrade)
- [PHP: Supported Versions](https://www.php.net/supported-versions.php)