Last week was a busy one for anyone who runs a Laravel app. On Monday, Laravel published a critical advisory for its token-based API guard. On Wednesday, the PHP project shipped emergency releases for two critical remote code execution bugs. Both are rated 9.2, and both affect the kind of stack I build on every day: Laravel, PHP-FPM and MySQL.
If you only read the headlines, it is easy to think "we ran an update, we're fine". That is not quite true for either fix. Here is what happened, why it matters even if your app is mostly an API for an AI agent, and the checklist I would run on every Laravel server this week.
What happened
The Laravel token guard bypass. As Laravel News reported, advisory GHSA-f9x3-7vq9-cph6 covers Illuminate\Auth\TokenGuard, the class behind the token guard driver in config/auth.php. On MySQL and MariaDB, an unauthenticated attacker could send a specially crafted, non-string token and log in as an existing user without knowing their API token. The fix adds an is_string() check before the database lookup. Sanctum and Passport register their own guard drivers and are not listed in the advisory. A second, medium-severity advisory the same day let a read-only request through JSON:API resources trigger a destructive operation on a related table.
The detail I find most useful: the patched versions, Laravel 12.68.0 and 13.29.0, were released on 25 August. The advisory went public in October. Apps that had simply stayed current were already safe for almost two months.
The PHP remote code execution bugs. On 21 October the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix CVE-2026-109618 (out-of-memory handling leaving request data half-initialised) and CVE-2026-109619 (request state surviving after its memory is freed). PHP says every install serving web requests is at risk, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed, and that the risk is highest for mod_php, where a demonstrated exploit works from an unauthenticated request before any application code runs. Its own words: "There are no complete mitigations, updating is the only safe choice."
In an interview with Laravel News, Volker Dusch of the PHP Foundation explained that the bugs surfaced in an audit by the security firm Calif, after the PHP Foundation got PHP into OpenAI's Patch the Planet programme. He also noted that an embargo was broken hours before release and that anyone can now turn a patch into an exploit much faster than before.
Why "we updated" is not the same as "we're patched"
Three details from the official guidance catch people out.
- Automatic updates may skip PHP. Laravel's Forge advisory says plainly that Forge's automatic security updates do not patch PHP, because PHP comes from a separate package repository. You have to update each server yourself.
- Long-running processes keep the old PHP. Upgrading the package restarts PHP-FPM, but queue workers, Horizon, Octane and Reverb keep running the old binary until you restart them. In a lot of the business systems I work on, the queue is where the real work happens: bookings, invoices, notifications, webhook handling.
- Old versions don't show the fix. For PHP 8.1 and earlier there is no new release, only backported package revisions, so php -v prints the same number before and after. You have to check the package revision instead, and really you should move to a supported version.
Why this matters for AI agents too
More and more of the Laravel apps I see now have a second kind of client: an AI agent or connector calling the API with a token. A Claude or ChatGPT connector, a WhatsApp bot, an internal automation. Token-authenticated routes are exactly where a guard bypass hurts most, because they are built to be called without a person signing in. I wrote about scoping that access in my guide to opening MCP write access safely, and the same rule applies here: an agent's token should only reach what that agent needs, so one weak guard doesn't expose everything.
The agent on my own website runs on Laravel with a read-only MCP endpoint, and the Fone Doctors platform I lead runs on Laravel and MySQL. That is why I treat framework and runtime patches as part of the agent work, not a separate chore.
The checklist I would run this week
- Find your guards. Search config/auth.php for any guard using the token driver. Apps on MySQL or MariaDB with that guard go first.
- Update the framework. Get laravel/framework to 12.68.0 or 13.29.0 or later, then run composer audit to catch anything else with a published advisory.
- Update PHP on every server. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, including PHP versions installed but not in use. On Forge, use Update PHP per server; on Vapor, redeploy.
- Restart the background. Run php artisan queue:restart, terminate Horizon and reload Octane so nothing is still running the old binary.
- Verify, don't assume. Check both php -v and php-fpm -v for the version you upgraded, or the package revision on older versions.
- Plan the leftovers. PHP 8.1 and older are end of life, and PHP says 8.2 stops getting security fixes on 31 December 2026. Put the upgrade on the calendar now.
My take
The cheapest security work is staying current. The Laravel fix was sitting there for two months before anyone needed to panic, and teams that update little and often were already covered when the Laravel advisory landed. The second lesson is to know your whole runtime: web workers, queue workers and every agent token that can reach your API.
If you run a Laravel platform and aren't sure what your servers, workers and API tokens look like right now, have a look at how I work with businesses on Laravel systems and AI agents, or book a call with me and we will go through your stack together. If you would rather write it down first, send me a message about your Laravel setup.
Mubashir HussainForward deployed engineer