PHP2Shell: critical PHP vulnerabilities and what to do now

WAYF’s view: patch the exposed system immediately. Then fix whatever makes safe updates difficult. A supported PHP website may need a security update and a better maintenance arrangement. A site held back by unsupported dependencies or costly customisations deserves an upgrade or migration assessment once the immediate exposure is addressed. Starting a rebuild while leaving the current site vulnerable would put that sequence backwards.

PHP released fixes on 21 October 2026 for CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. They can allow remote code execution without authentication. This article reflects primary sources checked on 22 October 2026; use the current PHP advisory for subsequent corrections and releases.

Which PHP versions contain the fixes?

PHP branch	Security release containing both fixes
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

These are the fixed upstream releases, not a requirement to jump to a different major branch during an emergency. Use the appropriate fixed release, a later vendor-confirmed fixed release, or a distribution package with the fixes backported. Have the provider identify the exact package and advisory: the version number alone may not establish its patch status. PHP’s advisory covers older releases and emergency backports too; those do not restore an unsupported branch’s normal maintenance lifecycle.

This affects the runtime, including PHP-FPM

PHP lists web-serving installations including Apache mod_php, PHP-FPM, CGI, FrankenPHP and LiteSpeed in scope. Using FPM does not establish that a site is unaffected.

CVE-2026-109618 concerns cleanup after memory exhaustion interrupts partially initialised request data. Its demonstrated pre-application exploit was on mod_php. FPM exits a worker after startup failure, avoiding that particular sequence; the advisory identifies possible later, application-stage exposure but reports no complete demonstrated FPM exploit for this CVE.

CVE-2026-109619 concerns internal state surviving after the memory it references has been freed. This separate advisory includes a validated session-related execution path on FPM, with application-dependent conditions. A site’s configuration and application affect exploitability; a generic claim that FPM is safe is insufficient.

For WordPress, Drupal and other PHP-based sites, the host or platform operator must address PHP itself. Updating a plugin or the CMS alone does not install the runtime fix. Cloudflare makes this distinction in its response to PHP2Shell.

Exploit attempts were reported before disclosure

Amazon Threat Intelligence reports an attempt against its MadPot honeypots on 17 October, four days before public disclosure, with further attempts on 21 October. AWS explicitly says it is unclear whether the early attempts would have succeeded against real-world systems. It describes exploitation activity broadening after disclosure.

Cloudflare separately reports attack traffic targeting customers and attempts to alter payloads to evade protections. These observations establish urgency. They do not establish that your website, or any particular customer, was compromised.

What to ask your host or agency today

ENISA and European security agencies call for an inventory, coordination with providers and urgent updates, prioritising internet-facing systems. Their scope includes products that bundle PHP even when their public interface does not reveal it.

Ask your host or agency:

1. Where does PHP run? Cover the main site, admin, APIs, microsites, public staging sites and bundled products. Record who operates each one.
2. Which fix applies to each installation? Ask for the upstream release or distribution/vendor advisory and exact package build. If the provider manages PHP, get its confirmation for your service rather than assuming a general announcement covers it.
3. Has the fixed runtime reached every serving instance? Request the deployment time, worker restart or replacement evidence, and confirmation that old containers or nodes no longer serve traffic. Checking the command-line PHP executable alone may check a different runtime.
4. Does the website still complete its important jobs? Verify login, publishing, uploads, search and forms, plus payments or CRM handoffs where applicable. A homepage loading successfully is a narrower test.
5. Who is assessing possible earlier compromise? Keep that decision separate from patch completion. Record the evidence reviewed, remaining gaps and the responsible security contact.

If patching is blocked, escalate immediately. The UK NCSC guidance addresses temporary mitigation and taking affected systems offline where necessary. Have the responsible engineer assess the current vendor guidance and service impact. Avoid applying isolated configuration snippets as though they were a complete remedy.

A WAF is an additional layer

Cloudflare has deployed managed protections and still tells customers to patch PHP. Confirm the relevant rules are active for your plan and that traffic reaches them. A blocked request does not prove that the origin is patched, and WAF coverage does not establish that no earlier compromise occurred.

Where compromise is suspected, involve a qualified incident-response provider to coordinate containment, evidence preservation and investigation. A patch addresses the vulnerability; it does not remove an intruder’s access or establish that the system is clean. If prompt patching or effective temporary mitigation is not possible, consider isolating the affected service in line with NCSC’s guidance rather than waiting for a longer review.

After the immediate fix, make the support decision

Ask what delayed the update: an unclear hosting boundary, an incompatible extension, missing deployment access, or the absence of a safe release process. Each has a different remedy. A platform migration earns its cost when it also resolves persistent publishing, integration or maintainability problems.

Our PHP website maintenance guide compares repair, ongoing support, upgrade and migration, with a downloadable handover checklist. It includes the evidence to request before accepting either a patch job or a longer-term proposal.

WAYF can assess application compatibility, scope upgrade and deployment work with your host, and plan ongoing website engineering or a CMS migration. Incident response and forensics require a separately qualified provider. This article is source-based guidance; we have not independently reproduced these exploits or certified any installation as remediated.