Two critical PHP vulnerabilities have prompted an urgent update recommendation from the PHP project. For business owners, the important question is straightforward: has the PHP software actually serving your website received the fixes?
The PHP project’s security advisory, published on 21 October 2026, identifies vulnerabilities that can allow an unauthenticated attacker to execute code on an affected server. That means some attacks do not require a website account or administrator password.
This article explains the issues, the fixed versions and the checks worth making with your hosting provider. Information is current as at 23 October 2026.
What are the latest PHP security vulnerabilities?
The October advisory covers two separate problems in how PHP handles memory and internal state during web requests. Both have a critical severity rating of 9.2 under CVSS v4.0, according to the linked PHP security advisories.
CVE-2026-109618: unsafe handling of out-of-memory conditions
The official advisory for CVE-2026-109618 describes a failure in PHP’s handling of out-of-memory conditions. Under particular circumstances, processing can stop while internal request data is only partly initialised. Cleanup code may then treat that invalid state as usable data.
The researchers demonstrated unauthenticated remote code execution against Apache configurations using mod_php, including a path that runs before application code starts. Other exposure depends on the server interface, application behaviour and runtime configuration.
For website owners, that distinction matters: an application does not necessarily need to contain its own vulnerable plugin or custom feature for the underlying PHP runtime to be exposed.
CVE-2026-109619: stale state between requests
The official advisory for CVE-2026-109619 concerns internal state left behind after the memory it refers to has been freed. A later request reaching the same worker can use that stale state before normal initialisation resets it.
Confirmed attack paths include remote code execution against both mod_php and PHP-FPM under the conditions described in the advisory. PHP-FPM is therefore not a blanket exemption.
Successful exploitation can execute code with the web worker’s permissions. That is serious, but it should not be confused with an automatic guarantee of root or administrator access.
Which PHP installations are at risk?
The PHP project’s umbrella advisory says PHP installations serving web requests should be considered at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk deployment.
That does not mean every installation is equally easy to exploit. The technical advisories describe prerequisites and configuration-dependent attack paths. It does mean that “my server uses a different PHP handler” is not an adequate reason to skip the update.
These are PHP runtime vulnerabilities, not vulnerabilities limited to one content management system.
Which PHP versions contain the fixes?
The PHP project’s 21 October release announcements identify these fixed upstream releases:
| PHP branch | Fixed upstream release |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
These are the October security-update targets, not a recommendation to move every application immediately to a different PHP branch.
A security update within a supported branch and a migration to a newer branch are different changes. My recommendation is to address the security exposure promptly, then plan and test any broader compatibility changes separately.
A lower version number does not always mean an unpatched server
Some operating-system vendors backport security fixes into their existing PHP packages without changing the upstream-looking version number to match PHP’s newest release.
For example, Ubuntu’s security notice USN-8948-1 lists fixes for both vulnerabilities in packages including 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS.
That package’s base version looks older than PHP 8.3.36, but the complete package revision identifies the vendor’s patched build.
Ask your provider for either the fixed upstream release or the full vendor package revision and the advisory confirming that both CVEs are addressed. A dashboard that displays only “PHP 8.3” or “PHP 8.4” does not answer that question.
Are a firewall or configuration changes enough?
The PHP release announcement is explicit: there are no complete mitigations, and updating is the only safe choice.
The project documents temporary measures that reduce exposure to particular attack paths. It also warns that those measures do not make an installation safe.
Treat a firewall rule or configuration adjustment as a temporary control, not evidence that the underlying vulnerability has been fixed. Avoid copying emergency PHP settings into production without understanding their effect on memory use, uploads and application behaviour.
What should a website owner ask their hosting provider?
Request a specific answer rather than a general assurance that security is taken seriously:
- Have both CVE-2026-109618 and CVE-2026-109619 been addressed?
- Which PHP release or full vendor package revision is serving my website?
- If the fix is backported, which vendor advisory confirms it?
- Have the running web workers been restarted or replaced as required?
- Have important website functions been checked after the update?
For an online business, I would include sign-in, enquiries, checkout, uploads and scheduled integrations in those functional checks.
The SenseICT hosting procurement guide can help clarify who is responsible for runtime updates, application maintenance and recovery. Those responsibilities should be explicit before an urgent security release arrives.
PHP 8.2 also needs an upgrade plan
The immediate patch is not the only date to watch. According to PHP’s supported versions schedule, PHP 8.2 reaches the end of upstream security support on 31 December 2026.
PHP 8.3 receives security fixes through December 2027, PHP 8.4 through December 2028 and PHP 8.5 through December 2029. Operating-system or commercial extended support is a separate arrangement, not an extension of PHP’s own support commitment.
If your application still depends on PHP 8.2, patch it now and plan its migration rather than leaving both jobs until the end of December.
Patch the runtime, then keep the rest in view
Addressing these vulnerabilities is important, but it is one part of website maintenance. Keep application security and recovery arrangements on the agenda too.
The WordPress security checklist covers the application side, while the small-business recovery checklist helps turn backups and access arrangements into a testable recovery process.
If you are unsure who maintains your PHP runtime, or your provider cannot identify the installed fix, contact Matt at SenseICT. I can help you establish what is running, who owns the update process and what needs attention.
