An updated CMS can still be running on a vulnerable PHP runtime. For a business handling customer enquiries or orders, that leaves a security gap a successful plugin update cannot close.
The PHP project published fixes for two critical runtime vulnerabilities on 21 October 2026. The immediate job for a technical leader is to establish which systems use PHP, who patches those runtimes and what evidence confirms the fix reached the processes serving customers. PHP release notices
This article's advisory and package details were checked on 22 October 2026. Use the linked vendor notices for subsequent updates.
What the PHP advisories establish
The issues are tracked as CVE-2026-109618 and CVE-2026-109619, commonly called PHP2Shell. Both official advisories rate them Critical, CVSS v4.0 9.2. They can permit unauthenticated remote code execution under the required conditions. Their vectors also specify high attack complexity and additional attack requirements; exposure is not uniform across installations. OOM advisory, stale-state advisory
The first issue involves memory left incompletely initialised after an out-of-memory interruption and then consumed during cleanup. Its advisory confirms exploitation against Apache mod_php before application code runs. Updating a CMS cannot intercept a flaw reached before that CMS executes. CVE-2026-109618 scope
The second involves state that survives after request memory has been freed, then gets consumed by a subsequent request handled by the same worker. It requires reachable operations that leave and later consume that state. The advisory includes validated mod_php and session-related FPM paths, with application or configuration prerequisites. PHP-FPM should not be assumed immune. CVE-2026-109619 scope
These distinctions help an operator assess exposure. They are not a reason to delay an applicable patch while trying to prove an exploit will work on a particular site.
A CMS update leaves an ownership question
Consider a fictional SME whose marketing agency maintains its CMS and plugins while a managed hosting provider supplies PHP. The agency confirms that the CMS is current. Nobody has asked the host whether its PHP build contains both fixes or whether the updated workers are active.
That is an unresolved patch status, not evidence that this fictional company was attacked. I would ask for a named runtime owner and a service-specific confirmation before marking the work complete.
The diagram asks a practical question: which owner can provide evidence for each layer? A managed service may assign several responsibilities to one provider. In a container deployment, your own team may own the PHP image. The contract and deployment model determine the answer.
Check the upstream fix or the distribution backport
For the supported upstream PHP branches, the first releases containing both fixes are:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
Earlier releases within those branches require remediation. Follow the applicable upstream or package-vendor instructions; this list is not a universal package-version test. PHP's 21 October security releases
Distribution vendors can backport security fixes while retaining an older upstream version number. For example, Ubuntu's USN-8948-1, published on 21 October, lists patched PHP 8.3 packages at 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS, and PHP 8.1 packages at 8.1.2-1ubuntu2.28 for Ubuntu 22.04 LTS. An old-looking version prefix alone would misclassify these builds. Ubuntu package fixes
Those revisions apply to the specified Ubuntu releases and packages. They do not establish the status of a third-party repository, another distribution or a hosting provider's custom build. For older branches, confirm the vendor's maintenance coverage and access to its patched packages. Ubuntu's separate notice for older LTS releases, for example, identifies fixes requiring Ubuntu Pro. Older Ubuntu release coverage
Ask for the complete package revision or image build and the vendor advisory covering both CVEs. A backport needs evidence; so does a claim that an installation needs no update.
Verify the PHP serving web requests
A screenshot of php -v from a terminal does not identify every PHP runtime serving a website. The command-line interpreter can differ from the runtime selected for a virtual host, FPM pool or container. PHP's documentation distinguishes these interfaces and their configuration handling. PHP interface identification, configuration loading
I would use this verification checklist with the operator or hosting provider:
- Identify the service. Record each PHP-backed hostname and application, its host or container, and its runtime owner. Include secondary CMS installations and older sites still reachable by customers.
- Identify the web runtime. Confirm the interface, package or image build and relevant configuration actually serving that service. Match it to the vendor's fix notice, rather than relying on a general account-level version selector.
- Activate the fix. Follow vendor instructions for updates and any necessary service restart, worker replacement or container rollout. Installing a package or rebuilding an image is only part of the task if old processes remain in service.
- Verify the active deployment. Obtain evidence that all relevant serving instances use the fixed build, then check normal application behaviour. Record the verification time and any remaining exceptions.
- Name the follow-up owner. Someone should track an unresolved host response, failed rollout or unsupported package until it has an agreed disposition.
Use private administrative evidence or a provider support response. Avoid publishing a diagnostic page exposing configuration details just to collect a version string. The useful record links the service, fixed build, activation and accountable person.
Separate a vulnerability from a confirmed compromise
In its 21 October report, Cloudflare says it observed attack traffic targeting customers and attackers changing payloads to try to evade protections. That is vendor-reported attack activity. It does not establish that a particular business was successfully compromised. Cloudflare also advises patching PHP despite WAF protection. Cloudflare's report
The PHP Foundation said it had not identified functional circulating exploits at release/public disclosure. That was a time-bounded observation, not a continuing assurance that exploitation was absent. It should not override later evidence or the project's direction to update. PHP Foundation disclosure account
Keep three findings distinct in your own status report: the installation is vulnerable or its patch status is unknown; suspicious requests or behaviour were observed; evidence confirms unauthorised activity. Each needs its own supporting evidence and next action.
If there are signs of compromise, preserve relevant logs and involve the incident-response owner to investigate and contain the affected service. Patching closes the vulnerability; it does not establish that earlier access or changes have been removed. Agree recovery decisions, including any credential changes, against what the investigation finds.
Close the patch task with evidence
The PHP advisories say a complete fix requires the patched runtime. WAF rules and configuration controls can be useful additional defences, but they do not replace that fix. Temporary configuration measures have limitations; they need an operator who understands the deployment. Official mitigation guidance
For the fictional SME, a useful handover would identify the affected website, the host's patched PHP package, confirmation that it is active, the application's post-update checks and any separate security investigation still open.
If responsibilities are unclear across an agency, hosting provider and internal team, an architecture review can help establish those boundaries. The immediate decision is still specific: who will verify the PHP build serving each site, and what evidence will they return?