,
,
,
Context – 21 October 2026: Security patches have been released for CVE-2026-109618 and CVE-2026-109619. All affected PHP environments under our management have now been patched. We also checked which PHP installations were actually in use and whether running processes were using the repaired code. This matters when several PHP versions run side by side, or an older version receives the fixes through a supplier patch (backport).
A website can be completely up to date and still be vulnerable. When the flaw is in PHP itself, updating the CMS or its plug-ins will not fix it. On 21 October 2026, two serious PHP vulnerabilities were disclosed. Several organisations took websites offline as a precaution while administrators and suppliers worked on the patches.
Our immediate concern was what this meant for our own systems. Through ASK-Solutions, the working name of Stichting IRADIS, we manage web environments for our own activities and for initiatives we support technically. These include different applications and PHP versions. When a security notice like this arrives, checking only the server's default PHP version is not enough.
PHP handles requests on the server side of websites and applications. It generates pages, processes forms and runs the code behind a CMS or a custom-built website. A flaw at that level can affect applications that are otherwise well maintained.
The vulnerabilities are CVE-2026-109618 and CVE-2026-109619. The first concerns PHP's behaviour when it runs short of available memory. With the second, internal state from an earlier request may, under certain conditions, persist after the memory it relied on has been freed. Both can allow an invalid memory state to be exploited.
The exact risk depends on how PHP is configured. The PHP security announcement identifies Apache with mod_php as a configuration where unauthenticated remote code execution has been demonstrated, before the application's own code even runs. That makes these flaws serious. It does not mean every PHP installation can be attacked in precisely the same way, but affected web-facing installations still need patching.
Our systems do not necessarily use the same PHP branch everywhere. One application may already be running a recent version, while another still depends on an older one. Several PHP installations can also be present on a single server. Updating the default package alone would not have been sufficient.
We reviewed the relevant installations, established which fixes were available and applied the required patches for both vulnerabilities. We then checked the PHP processes that were actually running. An update installed on disk only helps a running service once that service is using the updated code. Long-running workers are a particular reason not to skip this step.
That work is complete: the affected PHP environments under our management have been patched. This is the status of the incident within our infrastructure.
On 21 October, the PHP project released fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older branches no longer receive regular releases from the project in the same way. Even so, an older version can receive security fixes through a Linux distribution or a supplier offering long-term support.
For one of our PHP 8.1 installations, we verified that the supplier's patch already included both fixes. The installation still identifies itself as PHP 8.1. That version number alone therefore cannot tell you whether these particular vulnerabilities are still present. You need to check where the installed package came from and which patches it contains.
The reverse applies too: having a newer version on disk says little about which runtime a website is actually using. With parallel installations, PHP workers and older applications, these are separate questions. Temporary configuration changes are no substitute for the security patches either.
Three checks matter here: which PHP versions are installed, whether their packages contain fixes for both CVEs, and which code the active processes are using. The answers do not automatically line up.
This is also why temporarily taking a website offline can be a sensible precaution. It limits exposure when a vulnerable service cannot yet be updated. By itself, it says nothing about whether a breach occurred. Equally, installing a patch does not establish whether a vulnerability was exploited beforehand. That would require separate investigation.
For our affected PHP installations, the fixes have been applied and the running environments checked. CMS updates are a separate matter. They may still be needed to address vulnerabilities in the CMS or its extensions, but they cannot repair a flaw in PHP itself.
The discovery attracted extra attention because AI tools were involved in the security research. OpenAI describes how researchers from Calif and Wiz worked with the PHP maintainers and others on analysis and remediation ahead of disclosure. The PHP project developed and published the patches.
For us, the interesting part is not just how the flaws were found. Someone needs to reproduce the problem, review and test a fix, make packages available and ultimately apply them to the right systems. Open source allows different parties to contribute to that work. It also makes it possible for repairs to reach software that has been in use for years.
Everyone can see when a website gets a new design. Visitors generally notice nothing when its PHP runtime is updated. That is the idea, although it says little about how much work is involved.
For the web environments we manage, this maintenance is part of ordinary technical work. Not every application can simply move to another PHP branch. Sometimes a supplier patch for an older version is the appropriate solution; sometimes a service needs restarting, or we need to establish which installation is serving a particular site. The circumstances of the environment matter more than the version number on its own.
The two PHP vulnerabilities disclosed on 21 October have been fixed in our affected environments. This patching round is complete. The regular maintenance continues, even when nothing appears to change on the surface.
Copyright © 2026, ASK-Solutions
