IEEE Spectrum ran a piece this week on PHP2Shell, the pair of critical PHP flaws fixed on 21 October, and its argument is one I agree with: AI tools are now digging up bugs that have sat in old code for years, and the bill for all that old code is coming due. It got well over a thousand upvotes on Hacker News, which tells you plenty of developers recognised the feeling.
The patch itself is old news. If you run PHP and you're on a supported version, you should have updated a fortnight ago. The bit worth talking about is everyone who can't simply update, because their app is stuck on a version of PHP the project no longer fixes.
What PHP2Shell actually is
PHP's own advisory describes two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that "can allow unauthenticated remote code execution." In plain terms, someone on the internet, with no login, could get your server to run their code.
The first one comes from how PHP handles running out of memory. PHP used longjmp() to bail out of an out-of-memory error, which could leave internal request data half set up. Shutdown then tripped over it. Calif's write-up shows a multipart request with deeply nested field names can blow through the default 128 MiB memory_limit while staying under the default 8 MiB post_max_size. The second is request state surviving after the memory behind it has been freed. The fix replaces the longjmp() approach with a graceful "soft" out-of-memory and a hard exit at a higher threshold.
Two details matter for anyone running older software. Calif says the earliest affected path it found dates back to PHP 5.4.0, which came out in 2012. And PHP's advisory is blunt that updating to a patched release is the only complete mitigation. The configuration workarounds it lists (things like turning off session.upload_progress or changing memory_limit) reduce the risk. They don't remove it.
Who got a fix and who didn't
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you're on any of those branches, update, restart PHP-FPM or Apache, and you're done with this one.
For everyone else, PHP's advisory says "PHP 8.1 and older no longer receive updates from the PHP project." The security team did publish minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and long-term support vendors ship their own patched builds. That helps, but it means compiling PHP yourself or relying on a third party, and neither is a plan you want to still be running in two years.
There's also a date to put in the diary. PHP 8.2 reaches end of life on 31 December 2026, eight weeks from now. After that it gets no more security fixes either. So if you moved an app up to 8.2 a couple of years ago and called it job done, you're about to be in the same position as the 7.4 crowd.
Why old PHP apps get stuck
Nobody runs PHP 7.4 in 2026 because they like it. They run it because the app breaks on anything newer, and fixing that looks like a big, unglamorous job with no visible payoff.
The usual culprits are well known. Functions removed in PHP 8, stricter handling of types and nulls, old libraries that were never updated, and frameworks that stopped at a version that only supports older PHP. Each one is small. Together they add up to "we'll do it next quarter". We've written up what typically breaks when moving to PHP 8 if you want the detail.
That's the technical debt IEEE is talking about. It isn't really in PHP. It's in the apps sitting on top of it, and PHP2Shell is a good example of why it matters. A flaw that has been there since 2012 gets found, a fix ships, and the people who benefit are the ones who kept up.
AI cuts both ways here
Calif's write-up is open about how the bugs were found. The work was part of an audit sponsored by OpenAI, and the researcher describes asking an LLM for help and then having it "generalize the pattern" to find more. IEEE Spectrum's point, which I think is right, is that this won't be the last one.
If AI tools make finding bugs in old, widely used code cheaper, more of those bugs will be found, by the good guys and the bad. That includes the libraries your app pulls in and your own code. Being able to apply a fix quickly matters more than it used to.
The flip side is that the same tools make the upgrade job cheaper too. Working through an old codebase, finding every removed function and fixing the type errors is exactly the sort of grind AI coding tools are decent at, provided someone who understands the app is checking the results and there are tests to catch what it gets wrong.
What I'd do this week
- Find every PHP install you own. Run php -v on each server, and check containers and any old staging boxes too. The forgotten ones are the risk.
- If it's on 8.2 to 8.5, make sure it's on the fixed release and that PHP was restarted afterwards.
- If it's on 8.1 or older, find out whether your distribution or vendor has a patched build, apply the advisory's workarounds as a stopgap, and start planning the upgrade now rather than after the next one.
- If it's on 8.2, plan the move to 8.3 or 8.4 before 31 December.
- Check your logs. Patching closes the hole. It doesn't tell you whether anyone used it beforehand.
On the server side, I've written about updating and restarting PHP properly and what to look for in your logs over on my own site, which go into more of the commands.
If the app is the problem
If you've got a PHP app that nobody wants to touch, that's what our taking on existing software work is for. The sensible first step is usually our code audit: £250 + VAT, one system, and a plain-English report on what version it's on, what's holding it back and a fixed price for each fix. You can also see how we moved a whole estate onto supported PHP overnight.
Once it's on a supported version, keeping it there is the boring but important bit. Our Look after it service covers security updates, hosting and backups, from £355 a month + VAT, so the next PHP2Shell is a routine update rather than a scramble.
If you're not sure what your app is running on, drop us a line and we'll tell you.
Cheers, Rob
