El 11 de noviembre de 2026, Laravel publicó dos avisos de seguridad sobre URL firmadas temporales, las que genera temporarySignedRoute() y valida el middleware signed. En ambos casos, una URL creada para valer por un tiempo limitado podía aceptarse después del plazo, como si no expirara. Están afectadas las versiones anteriores a 12.72.0 y las 13.x anteriores a 13.41.0. Las dos correcciones salieron el 10 de noviembre, en las versiones 12.72.0 y 13.41.0 del paquete laravel/framework.
Los dos avisos tienen severidad moderada (CVSS 4.8), sin CVE asignado por ahora. La nota es moderada porque cada fallo depende de una condición concreta, descrita abajo. Para quien usa este tipo de enlace para liberar una descarga, aceptar una invitación o confirmar una acción sin iniciar sesión, la consecuencia práctica es la misma: el plazo de validez deja de estar garantizado.
Los dos fallos
El primero (GHSA-v5ch-g375-82r6) tiene que ver con el límite max_input_vars de PHP. Cuando la URL trae parámetros suficientes para superar ese límite, PHP descarta expires de la query ya interpretada. La firma, sin embargo, se sigue comprobando contra la query string sin procesar, que todavía contiene el campo. Resultado: la firma coincide y la comprobación de plazo entiende que la URL no expira. El propio aviso dice que la explotación exige una línea de petición larga y que las configuraciones por defecto de nginx y Apache ya rechazan una URL de ese tamaño.
El segundo (GHSA-6rv8-qj5v-p8ch) depende del código de la aplicación. Si esta pasa a temporarySignedRoute() o signedRoute() parámetros con clave numérica que vienen del usuario, como el array de la query de la petición, Laravel añadía esos valores a la URL sin codificarlos. Así, quien controla la entrada puede insertar un segundo campo expires, que queda cubierto por la firma y pasa a ser el valor leído en la validación.
Quién debe revisarlo ahora
Cualquier aplicación Laravel 12 o 13 que emita URL firmadas temporales debe actualizar. El riesgo mayor está en dos perfiles: quien genera estos enlaces reenviando arrays de la petición, y quien opera detrás de un servidor o proxy configurado para aceptar URL mucho más largas que lo habitual.
El caso más delicado es el de las aplicaciones en Laravel 11 o anterior. El rango afectado en los avisos es "por debajo de 12.72.0", y la política de soporte de Laravel cerró las correcciones de seguridad de Laravel 11 el 12 de marzo de 2026 (las de Laravel 10 terminaron en febrero de 2025). No habrá parche para esas líneas. Para ellas, el aviso se suma a la cuenta de una migración aplazada, el mismo problema que traté en una versión con soporte también exige decidir cuándo migrar: la fecha de fin de soporte ya pasó y no hay corrección que esperar del proyecto.
Qué hacer
Actualizar laravel/framework a 12.72.0 o 13.41.0 (o posterior) y desplegar. También conviene buscar en el código las llamadas a temporarySignedRoute() y signedRoute() que reciben algo como $request->query() o $request->all(). El aviso recomienda pasar solo parámetros elegidos de forma explícita, con clave de texto, incluso después de actualizar.
Si todavía no se puede actualizar, el aviso del primer fallo documenta dos paliativos: limitar el tamaño de la URL en el servidor web o, sin acceso a esa configuración, poner antes de signed un middleware que rechace la petición cuando la query sin procesar tenga más pares que max_input_vars o cuando expires aparezca en ella y falte en la interpretada. En Laravel 11, ese es el camino hasta la migración.
En la línea 12.x hay un cuidado más. La corrección del segundo fallo empezó a codificar también los valores EncodedParameter, que deberían salir sin cambios. La issue #62416 informa que, en 12.72.0, q=000001 pasó a generarse como q%3D000001. Si la aplicación usa EncodedParameter en redirecciones o rutas, pruebe esos flujos antes de publicar.
Lo que todavía no se sabe
La corrección de la regresión de EncodedParameter se incorporó a la rama 12.x el 11 de noviembre, junto con una protección adicional que rechaza expires en forma de array, pero hasta el 12 de noviembre no había una versión 12.x posterior a 12.72.0 con esos cambios. Los avisos tampoco dicen si hubo explotación conocida, ni si una URL generada antes de la actualización con un expires duplicado pasa a rechazarse después. Por último, el blog de Laravel aún no ha publicado una nota sobre el tema; la información oficial está en los avisos del repositorio.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
Referencias
- GHSA-v5ch-g375-82r6: Temporary signed URL expiration bypass
- GHSA-6rv8-qj5v-p8ch: Temporary signed URL expiration bypass via unencoded numeric-keyed route parameters
- Laravel framework v12.72.0 (notas de la versión)
- Issue #62416: v12.72.0 breaks query strings, again
- Laravel: política de soporte de versiones
