A PHP update normally doesn’t deserve a blog post.
This one did.
On 21 October, the PHP project released emergency security updates addressing two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619.
Both were rated Critical and could, under the right conditions, allow unauthenticated remote code execution.
In simpler terms: someone doesn’t necessarily need an account, admin password or access to your website’s backend. A specially crafted request could potentially exploit PHP itself and make the server execute code it was never supposed to execute.
That is considerably more serious than a website simply going offline.
Depending on the server configuration and permissions involved, remote code execution can potentially give an attacker the ability to interfere with an application, access data available to it, modify files or use the compromised environment as a way into something else.
The interesting part was where the bugs lived
These weren’t vulnerabilities in WordPress, WooCommerce or a particular plugin.
They existed deeper down, inside PHP itself.
One vulnerability involved how PHP handles memory when it runs out during the processing of a request. Under particular conditions, partially initialised data could later be treated as valid.
The second involved internal state from one request remaining after the memory behind it had already been released, potentially allowing a later request handled by the same PHP worker to interact with that stale information.
You don’t need to understand memory management to understand the consequence: normal-looking web requests could potentially reach a part of PHP they should never have been able to control.
And because PHP sits underneath a very large part of the web, this was something we took seriously.
What we did at Rocketeer
The environments we manage aren’t all the same.
They range from telecommunications platforms and high-traffic ecommerce stores to hospitality websites, corporate platforms and smaller business-critical applications.
Simply pushing the same PHP update everywhere wasn’t something we were comfortable doing.
We first reviewed the versions and configurations running across the environments under our management and identified where action was required.
We also pulled the patched PHP releases into our own test environments and spent some time with them ourselves.
That meant running them against the types of setups we actually manage, checking application compatibility and looking for unexpected behaviour before progressing through production environments.
Then came the less exciting, but more important part.
We rolled the patched PHP versions through the affected environments and tested the applications sitting on top of them.
For an ecommerce site, that isn’t just checking whether the homepage opens.
It means checking things such as:
- checkout and payment flows
- customer sessions and logins
- APIs and external integrations
- background and scheduled jobs
- uploads and forms
- caching
- database connectivity
- PHP workers and error logs
- server resource behaviour
For other platforms, the checks are different. The principle isn’t.
A patch isn’t successfully deployed just because PHP starts again. The application has to continue doing its job.
Once those checks were completed, we continued watching logs, traffic and application behaviour for anything unusual.
Why we are writing about it
Most of this work is invisible.
When a vulnerability like this appears, the ideal customer experience is actually quite boring.
The website continues to work.
Orders continue to come in.
Bookings continue to go through.
Applications continue responding.
And nobody outside the technical team has to spend their day thinking about PHP memory corruption.
That’s part of what managing technology means to us.
Not simply building something and handing it over, but continuing to understand the infrastructure underneath it, responding when something changes and doing the work required to keep it running.
Sometimes that means building something new.
Sometimes it means spending a night testing a PHP patch that we hope our customers never have to think about.
That’s the Rocketeer side of keeping the web running.
