14:00 UTC on October 21. That was when the PHP security team had scheduled an emergency release for two separate vulnerabilities, each scored 9.2 on CVSS. Earlier that same day, Laravel had shipped 12.68.0 and 13.29.0 to close a hole in the API token guard that let an attacker authenticate as someone else's account on MySQL and MariaDB. So for anyone running a Laravel API on a MySQL box, the to-do list was one framework bump and one runtime bump, both critical, before the coffee went cold.

It's been eight days. I'd honestly like to see the distribution of how long it took each of you to get both into production, because I suspect it splits into two groups with almost nothing in between. One group merged a composer update, watched CI go green, rebuilt the image with the new PHP point release and went home. The other group is still in a ticket thread asking who owns the staging environment.

The difference between those groups isn't diligence. Everyone read the same advisory. Nobody I know shrugged at an authentication bypass. What separates them is whether the test suite is something the team actually believes. If a green run means "we're fine", a minor framework bump is a fifteen-minute job. If a green run means "probably fine, but remember the time the cron jobs broke", the same bump takes a week, because now a human has to click through the app by hand, and humans are busy, and that's how a patched vulnerability stays live in your stack for days after the fix is public.

The best counter-argument deserves a fair hearing: rushing is how you break production, and a patch you didn't stage is a gamble of its own. Point releases do sometimes change behaviour. Ops people who insist on a soak period in staging have scars that justify it, and I'm not going to pretend a two-line diff in composer.lock is risk-free. But look at what the soak period is really for. It's a substitute for confidence you didn't build into the suite. Staging catches the things your tests don't cover, so the slower your rollout, the more it's telling you about gaps in coverage and not about the patch.

Which makes the least glamorous link in that day's news roundup the most useful one. Rob Allen wrote up how to find your slowest PHPUnit tests by having PHPUnit write a JUnit XML log with --log-junit, so you get per-test timings to sort, and noted that PHPUnit 13 can produce Open Test Reporting output for the same purpose. It sounds like housekeeping. It's actually security work. A pipeline that takes forty minutes gets run less often, gets skipped under pressure, and nobody gets around to adding the regression test that would have made patch day boring.

There's a second, quieter lesson in the Laravel bug itself, which only hit MySQL and MariaDB setups. If your CI runs everything against SQLite in memory because it's fast, you would have had a green suite on a database that wasn't affected, while production ran one that was. Speed matters, but it has to be speed on your real stack. A containerised MySQL in the pipeline costs you some seconds; a database-specific auth bypass you can't reproduce in tests costs you far more than that.

None of this is a dig at the ecosystem. Laravel's maintainers shipped fixes for two major lines quickly, the PHP team announced the release window ahead of time so we could plan around it, and that's what a mature project looks like. The bottleneck on October 21 wasn't upstream. It was the space between "a fix exists" and "my servers run it", and that space belongs to us. Go devs like to brag about shipping a single static binary; we get to brag about a composer update and a base image bump, as long as we can trust the result.

So here's what I'd actually like to know, in the comments: what's the wall-clock time from advisory to production on your main PHP app, measured honestly on October 21, and which single thing in your pipeline would you fix first to cut it in half?