On 21 October 2026 at 14:00 UTC the PHP project published a security release fixing two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619 (CVSS 4.0: 9.2). The flaws are in session handling and the opcache, and a crafted request can lead to remote code execution – a site takeover. Every PHP branch down to 5.x is affected.
The PHP project only patches the versions it still supports: 8.2, 8.3, 8.4 and 8.5. Sites on PHP 8.1, 7.4, 7.0 or 5.6 get no fix from upstream. And there are plenty of them: shops and systems written years ago that would cost more to rewrite than they are worth, but still make money.
Here is what we did that day and why we could do it fast.
Timeline
| Time (21 Oct, CEST) | What happened |
|---|---|
| 13:30 | The security release is announced for 16:00. Decision: we do not leave the older versions behind – we patch them ourselves. |
| 15:15 | Every older PHP version rebuilt on security-backport branches – a base ready for the new fixes. |
| 16:00 | The PHP project publishes the fixes. |
| about 18:00 | New builds of every version we offer, 5.3 to 8.5, built and checked in our test environment. |
| about 19:00 | The new builds run across our entire hosting. |
Less than three hours passed between the fixes going public and the last site being patched. Customers had nothing to change, request or switch.
What exactly we did
Supported versions (8.2–8.5) moved to the releases of that day: 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
Unsupported versions (5.3, 5.5, 5.6, 7.0, 7.4, 8.0, 8.1) are seven branches the PHP project no longer patches. For them:
- we carried the fixes back to the older code (a backport), building on the community-maintained security branches for old PHP (php-src-backports – thank you!);
- for 7.4 and 8.1 we compared the result with the minimal fixes prepared within the PHP project itself;
- in total, more than 12 thousand lines of changes across seven branches.
Every version, before rollout, was built from scratch and started in our test environment. In case the builds ran late, we had a PHP configuration workaround ready that blocked the attack path. It was not needed.
After the rollout our vulnerability scanner learned to recognise fixes carried back to older branches, so it reports what is really in our builds, not just a version number. That also shows us older critical bugs the community branches do not cover – and we are patching those ourselves now.
Why we could move this fast
Three decisions we made long before:
- We build PHP ourselves. We do not wait for the operating system’s distribution to ship a package – and for old versions it never would. Every PHP version we offer comes from our own recipe, so a new fix is a new build, not a request to someone else.
- Every customer has their own container. Different customers’ sites do not share one environment, and a new PHP build reaches the containers as a new image – the same one checked in testing beforehand.
- A rollout is one operation. Moving the whole hosting to a new image is done from our panel, container by container, checking that each one came back healthy.
What this means for you
If your site runs with us – on any PHP version we offer, from 5.3 to 8.5 – it is already patched against both vulnerabilities. You do not need to do anything.
If you can, move to a newer PHP version anyway: you get fixes from the project itself, better performance and support for newer libraries. But if your application needs an older PHP, you do not have to choose between running and being secure – we keep the older versions maintained and patched.
Looking for hosting for an older application that others tell you to move off? See our hosting – PHP 5.3 to 8.5, every version we offer with security fixes.