PHP2Shell is the name being used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Security fixes were released on 21 October 2026. If your business website runs PHP, the immediate task is to get its hosting runtime patched, not to wait for a WordPress plugin update.
The PHP project’s security advisory confirms the fixed releases. This is a serious server-software issue, but it is not proof that every affected website has been hacked. Establish exposure, apply the appropriate fix and investigate suspicious evidence separately.
PHP2Shell: what happened on 21 October?
The PHP project released emergency updates after advance notice of two critical flaws. Both received a CVSS v4.0 severity score of 9.2. The issues can permit unauthenticated remote code execution: an attacker may be able to run code without first logging into the application, under the conditions described in the maintainers’ advisories.
The NSA’s PHP advisory is genuine. It advises organisations that cannot update immediately to take systems offline until the risk can be mitigated. That is a hosting and incident-response decision, not an instruction to delete WordPress or click an unverified emergency link.
Earlier notices said that patches were coming. They are now available. When reading an alert, check whether it describes the pre-release situation or the released fixes.
Which PHP versions fix the vulnerabilities?
The following are the upstream security releases announced for this incident. Your hosting provider may instead supply a documented distribution backport, with a different package version.
| PHP branch | Fixed upstream release | Owner decision |
|---|---|---|
| 8.5 | 8.5.12 | Ask for the patched build serving your website. |
| 8.4 | 8.4.27 | Confirm the patch, not just the branch selector. |
| 8.3 | 8.3.36 | Verify every relevant site and worker pool. |
| 8.2 | 8.2.35 | Patch now and plan the supported-branch transition. |
| 8.1 and older | No normal upstream release for these branches | Obtain verified vendor coverage or plan a supported upgrade with the host. |
CERT-EU’s advisory also covers end-of-life branches and the exceptional source backports. Those backports are not an invitation for an ordinary site owner to compile PHP on a live server. Ask the party responsible for the server to identify its supported patch route.
What do CVE-2026-109618 and CVE-2026-109619 do?
CVE-2026-109618: out-of-memory corruption
The maintainers’ out-of-memory advisory describes PHP being interrupted while internal request data is only partly initialised. Cleanup can then use that invalid state. This is a flaw in how the runtime handles failure, not simply a website that needs a larger hosting plan.
The confirmed application-independent attack path involves Apache’s mod_php. The advisory also describes susceptibility in other serving arrangements, with different conditions. Do not treat PHP-FPM, LiteSpeed or a familiar hosting brand as an automatic exemption.
CVE-2026-109619: stale request state
The stale-global-state advisory describes a worker retaining references to memory that belonged to an earlier request. A later request can encounter that stale state before normal initialisation replaces it. The confirmed paths involve particular error, configuration and session behaviour.
For a business owner, the important distinction is that changing a page password does not replace the interpreter beneath the application. The server operator needs to remediate the runtime.
Are WordPress and WooCommerce websites affected?
WordPress runs on PHP, so its hosting environment needs assessment. The WordPress project’s incident notice says these are not WordPress-specific vulnerabilities and that no WordPress release is required or planned to fix them. A dashboard showing current core and plugin versions is therefore not enough.
This applies to business sites, shops, membership sites and other PHP applications. Inventory the actual installations you own: the main domain, subdomains, staging, old campaigns and separate applications can have different runtime assignments. A successful patch on one domain does not establish the status of the others.
Use our WordPress PHP security update checklist for the dashboard checks and the specific evidence to request from a managed host. Keep this article as the incident reference rather than trying to interpret a patch from a homepage response header.
Does Cloudflare protection mean I can wait?
Cloudflare reports deploying WAF protections against php2shell and observing attack traffic. That is a useful additional defence, not proof that your own origin, hostname and traffic paths are covered. An origin reachable outside the protected path still needs attention.
Do not turn off protection to test exposure, and do not run public exploit scripts against production. Ask the host to confirm patch status directly. A blocked request, a clean malware scan and a working homepage answer different questions; none substitutes for that confirmation.
What should a website owner do now?
- Identify the responsible operator. On managed hosting, contact the provider. On a self-managed VPS, assign a server administrator. A WordPress administrator login may not include permission to update PHP packages.
- Request a patch result for the named site. Ask which running web runtime and package now contain both fixes, and whether old workers have been replaced. A plan to update later is not a completed change.
- Agree on containment if patching is blocked. Have the operator assess restricting access or taking the affected application offline. A WordPress maintenance-page plugin is not equivalent to preventing requests from reaching PHP.
- Verify the business journey after patching. Check uncached pages, administration, forms and the applicable shop or booking flow. If a runtime change causes errors, follow the PHP-update recovery guide without blindly restoring an unpatched version.
- Preserve suspicious evidence. Unexpected administrators, changed files or unexplained redirects deserve investigation. Keep relevant logs and backups before cleanup rather than deleting everything unfamiliar.
Partial configuration mitigations in the technical advisories have important limits. In particular, changing memory limits without server-level resource controls can introduce availability problems. Ordinary owners should not paste a generic php.ini recipe into production and call the server safe.
Patched is not the same as investigated
A patch closes the identified vulnerability paths. It does not remove an account, file or persistence mechanism an attacker may already have created. Conversely, merely running an affected version does not establish that an attacker succeeded. Keep the patch decision and the compromise investigation as separate work items.
If you have signs of an intrusion, review Webless’s hacked WordPress site recovery service. For an otherwise functioning site, ask the host about PHP first and use WordPress maintenance to coordinate application checks. Do not send passwords, recovery links or raw private logs in the initial enquiry.