On November 11, 2026, Laravel published two security advisories about temporary signed URLs, the ones generated by temporarySignedRoute() and checked by the signed middleware. In both cases, a URL meant to be valid for a limited time could be accepted after its deadline, as if it never expired. Affected versions are everything below 12.72.0 and 13.x below 13.41.0. Both fixes shipped on November 10 in versions 12.72.0 and 13.41.0 of the laravel/framework package.
Both advisories are rated moderate (CVSS 4.8), with no CVE assigned so far. The rating is moderate because each flaw depends on a specific condition, described below. If you use these links to release a download, accept an invitation or confirm an action without login, the practical consequence is the same: the expiry is no longer guaranteed.
The two flaws
The first (GHSA-v5ch-g375-82r6) involves PHP's max_input_vars limit. When a URL carries enough parameters to exceed that limit, PHP drops expires from the parsed query. The signature, however, is still checked against the raw query string, which still contains the field. The result: the signature matches, and the expiry check concludes the URL never expires. The advisory itself says exploitation requires a long request line and that default nginx and Apache settings already reject a URL of that size.
The second (GHSA-6rv8-qj5v-p8ch) depends on application code. If the app passes numeric-keyed parameters that come from the user, such as the request's query array, to temporarySignedRoute() or signedRoute(), Laravel appended those values to the URL without encoding them. Whoever controls that input can then insert a second expires field, which is covered by the signature and becomes the value read during validation.
Who needs to look now
Any Laravel 12 or 13 application that issues temporary signed URLs should upgrade. The higher risk sits with two profiles: apps that build these links by forwarding request arrays, and apps running behind a server or proxy configured to accept URLs much longer than the default.
The trickiest case is applications on Laravel 11 or older. The affected range in the advisories is "below 12.72.0", and Laravel's support policy ended security fixes for Laravel 11 on March 12, 2026 (Laravel 10's ended in February 2025). There will be no patch for those lines. For them, the advisory adds to the bill of a postponed migration, the same problem I discussed in a supported version still calls for a migration decision: the end-of-support date has passed and no fix will come from the project.
What to do
Upgrade laravel/framework to 12.72.0 or 13.41.0 (or later) and deploy. It is also worth searching the code for calls to temporarySignedRoute() and signedRoute() that receive something like $request->query() or $request->all(). The advisory recommends passing only explicitly chosen, string-keyed parameters, even after upgrading.
If you cannot upgrade yet, the first advisory documents two mitigations: limit URL length at the web server or, without access to that setting, add a middleware before signed that rejects the request when the raw query has more pairs than max_input_vars or when expires appears in the raw query but is missing from the parsed one. On Laravel 11, that is the path until the migration.
On the 12.x line there is one more caveat. The fix for the second flaw also started encoding EncodedParameter values, which are supposed to pass through unchanged. Issue #62416 reports that on 12.72.0, q=000001 began to be generated as q%3D000001. If the app uses EncodedParameter in redirects or routes, test those flows before shipping.
What is still unknown
The fix for the EncodedParameter regression was merged into the 12.x branch on November 11, together with an extra guard that rejects an expires value in array form, but as of November 12 no 12.x release after 12.72.0 included those changes. The advisories also do not say whether there has been known exploitation, or whether a URL generated before the upgrade with a duplicated expires is rejected afterwards. Finally, the Laravel blog has not published a note on the subject; the official information is in the repository advisories.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
