PHP2Shell explained: the October 2026 PHP vulnerabilities

Your website loads. The checkout works. Someone in the team chat says, “PHP security issue. Are we affected?”

That is an excellent moment to replace optimism with an inventory. Optimism is lovely. It is a terrible asset-management system.

The short answer: PHP2Shell is the name used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. NHS England lists both at 9.2 on CVSS v4, the severity-scoring system, and warns that successful exploitation can allow remote code execution or access to sensitive process memory. Start by checking the PHP runtime behind each website, then apply a supported fix. NHS England advisory.

This guide covers the issue making news on 22 October 2026, with sources checked on 23 October 2026. It is a researched explanation, not a claim that I discovered the bugs, reproduced the exploits, or inspected your server. The operational checklist below is my suggested way to organise the response.

What happened on 21–22 October?

PHP's security team announced an emergency release in advance on 20 October. Its official archive records the security advisory and stable releases on 21 October, so the story did not begin on the 22nd. There is a small date wrinkle: the PHP 8.5.12 changelog is headed 22 October. I am using the dated release announcement for the release timeline, rather than quietly pretending those pages agree. PHP announcement archive, PHP 8 changelog.

The disruption was real, but disruption and compromise are different claims. South East London Integrated Care System's 22 October notice said some websites had been taken offline while fixes were applied and that it was assessing effects with suppliers. That is evidence of a precautionary response, not evidence that every affected organisation lost data. South East London ICS notice.

Cloudflare separately reported attack traffic targeting these vulnerabilities and deployed WAF protections. That supports saying exploitation attempts were observed. It does not give us a verified worldwide count of successful compromises. Cloudflare's first-party report.

So, yes: act urgently. No: a screenshot of an unavailable website is not a forensic report.

What is actually broken?

The flaws concern PHP's handling of memory and request state. They are in the runtime (the software executing PHP applications), not merely in an individual WordPress plugin.

A worker is a process that handles requests. It may serve one request, finish, and handle another. The problem is what can remain behind when a request ends badly.

CVE-2026-109618: unsafe state after an out-of-memory error

PHP can interrupt a request when memory allocation fails. In affected paths, some internal data may be reachable before it has been fully initialised. Cleanup can then use that unfinished data as though it were valid.

The official advisory documents unauthenticated remote code execution against Apache's mod_php, including a path before application code starts. It treats other server interfaces with more nuance: for this CVE, source analysis supports PHP-FPM susceptibility, but the advisory does not report a complete FPM exploit. “Not demonstrated here” is not “safe.” PHP's CVE-2026-109618 advisory.

CVE-2026-109619: a later request encounters stale state

Some PHP state can retain references to memory belonging to a finished request. If that memory has been released and a later operation uses the old reference, PHP can operate on something that is no longer valid. This is called a use-after-free.

The second advisory describes several paths with different prerequisites. It includes a validated PHP-FPM session-related path that depends on a suitable application operation. That is why “we use FPM, not Apache's PHP module” is not enough to close the ticket. PHP's CVE-2026-109619 advisory.

If you want a rough analogy: the first bug can trust paperwork that was never completed; the second can trust paperwork after the desk has been cleared and reassigned. The analogy explains the mistake. The advisories explain the engineering.

Which PHP versions need updating?

For the stable branches covered by the emergency release, use this branch-by-branch reference. These are the first fixed upstream versions for this incident, not a recommendation to stay on them forever. NHS England's affected-version and remediation table.

PHP's announcement also includes web-serving installations using FPM, CGI, FrankenPHP and LiteSpeed in its risk assessment. PHP 8.1 and earlier are outside normal upstream support; the team supplied exceptional minimal source backports for 7.4, 8.0 and 8.1. Those do not restore ongoing support. Distribution or long-term-support vendors may supply their own backports, so obtain the vendor's advisory and exact fixed package revision rather than judging only the upstream-looking version number. PHP's update guidance.

A source patch on GitHub is also not evidence that your host installed it. The gap between those two events is where a surprising amount of production risk likes to live.

Does this affect WordPress, Drupal, Joomla or custom PHP?

Wiz reported demonstrations against WordPress, Drupal and Joomla deployments, along with disclosure of sensitive worker memory. Its research emphasises that these are examples of impact: the underlying issue is in PHP, not a required flaw in those CMSs. Exploit behaviour depends on the deployment. Do not read the demonstration list as either an exhaustive list of affected products or a statement that every installation has been compromised. Wiz Research's technical report.

Updating the CMS and plugins remains sensible maintenance, but it does not by itself replace the PHP runtime update. Cloudflare makes the same distinction in its remediation guidance. A managed host may own that runtime; a self-managed team may own it directly. Cloudflare guidance.

My suggested ownership check:

This is an accountability table, not a claim that all providers patch in the same way. “Our infrastructure team is aware” is a beginning. It is not the evidence column.

How to check PHP without checking the wrong PHP

These are read-only inventory commands for a machine you administer:

php -v
php --ini
php -r 'printf("PHP=%s SAPI=%s\n", PHP_VERSION, PHP_SAPI);'

The PHP manual documents the version and configuration options, while PHP_VERSION and PHP_SAPI identify the version and server interface of the executing build. In a shell, the last command normally identifies the command-line interface. PHP CLI options, PHP predefined constants.

That tells you about the binary you just ran. It is not proof about every website on the machine.

My verification workflow is to match four pieces of evidence:

1. The website: hostname, environment and responsible person.
2. The serving runtime: its web-server configuration, PHP pool or container, and package/image identity.
3. The fix: the upstream release or a vendor advisory explicitly covering both CVEs.
4. The running replacement: confirmation that requests now reach the updated processes, not just an updated file on disk.

Ask your administrator to check the web runtime through existing authenticated diagnostics or the hosting panel. Do not leave a public phpinfo() page behind as a souvenir of the incident.

Repeat the check for staging sites, old subdomains and secondary replicas. A green result from one machine is one green result. It does not magically spread through the fleet by positive thinking.

The same ownership discipline matters in a monorepo: one repository can organise many applications, but it should not tempt you to treat every deployed runtime as one thing.

A practical patch-and-verify checklist

The following is an operational template, not a universal shell script. Package names, service names and deployment controls vary; use your host or distribution's supported update procedure.

1. Write down the scope before changing it

Make a small incident sheet with hostname, owner, runtime, package or image identifier, current status and the next action. Include public applications first, then supporting environments.

Keep “unknown” as a real status. It is more useful than a green tick based on a guess.

2. Prepare recovery, then apply the supported fix

Confirm backups and the recovery procedure. Check that the update is for the correct operating-system release and PHP branch. For containers, rebuild from the fixed base and redeploy; do not stop at changing the Dockerfile.

Test the parts of your application that matter: login, checkout, file uploads, administrative actions and background processing, as applicable. Avoid turning an emergency runtime update into an unplanned application rewrite.

If a rollback is necessary, record whether it would restore a vulnerable runtime. A rollback can restore service and reopen exposure at the same time; that trade-off needs an owner.

3. Verify the processes serving traffic

Replace or restart the relevant workers using your platform's procedure. Check every pool and replica. Record the new runtime evidence beside the original inventory entry.

Do not use the word “done” to mean “the package manager exited successfully.” That is a useful milestone, not the finish line.

4. Review exposure and communicate separately

Keep two status fields: patch deployment and security investigation. They answer different questions. A team can finish the first while still working on the second.

Write a short update containing what changed, what remains unknown, who owns the remaining work and when the next update will arrive. People can work with uncertainty that is named. They struggle with reassurance that expires five minutes later.

What if an immediate update is not possible?

NHS England recommends a local risk assessment and considering taking vulnerable systems offline until they can be patched. Treat that as a decision for the service owner and security team, with the business consequences understood. NHS remediation advice.

PHP's advisories describe temporary controls, but their scope matters:

• For the out-of-memory flaw, PHP describes administratively enforcing memory_limit=-1 alongside request and resource controls. This is not a blanket “make memory unlimited” tip: underlying allocation failures remain possible, and resource containment matters. Read the full procedure with the administrator before changing it. OOM advisory.
• For particular stale-state paths, controls include disabling session upload progress and, on PHP 8.5, fatal-error backtraces, followed by worker restarts. These do not cover every variant. Hiding errors does not remove the underlying unsafe access. Stale-state advisory.

I would keep the complete official procedures open during any temporary mitigation, rather than paste a shortened configuration recipe into production. This is one of those occasions when the footnotes are doing actual work.

Is a WAF enough?

No. Cloudflare says its protections add a defensive layer and still instructs customers to patch PHP. Its report also explains why detection needed both request and response signals, rather than only simple request matching. Cloudflare's protection details.

My suggested questions for any WAF provider are: does the relevant protection apply to our plan, is it enabled in blocking mode, does all affected traffic pass through it, and what evidence shows that it is operating?

Keep the WAF and runtime-update tickets separate. A firewall rule is useful. It is not a ceremonial pardon for an old runtime.

Likewise, offline-friendly application design can improve continuity during a network interruption. It does not remediate a vulnerable origin server. Availability and security deserve separate checks.

What should you investigate after patching?

Wiz recommends watching for unusual multipart traffic alongside memory-limit errors or repeated HTTP 500 responses, abnormal session-cookie responses and unexplained PHP worker churn. Its report notes that relevant activity can happen below the application layer, leaving limited application-log context. These are investigation leads, not automatic proof of compromise. Wiz's detection discussion.

My practical response is to preserve relevant logs and deployment records, establish the exposure window, and involve incident-response specialists if evidence suggests intrusion. Decide credential rotation, restoration and notification steps from that investigation rather than from a generic checklist alone.

Most importantly, installing a patch answers “have we addressed this vulnerability in the running software?” It does not, by itself, answer “what happened before we patched?”

Where does AI fit into this story?

Wiz describes using AI tools during its research and exploit-development work. That is a documented research claim, not a reason to assume every attack was autonomous or every future bug is equally exploitable. Wiz Research.

The lesson I take from it is operational: make the path from advisory to inventory to verified deployment shorter. Buying another dashboard is optional; knowing who patches the server is rather less optional. The Node.js security release the same week teaches the same lesson for JavaScript runtimes.

It is the same distinction I make in AI that ships, not AI that demos: convincing output is useful only when the result can be checked. Here, the check is a running system with documented remediation, not a confidently written status message.

A message you can send your hosting provider

Use this as a starting point and replace the brackets. It asks for evidence without asking the support team to write a novel.

We are reviewing PHP2Shell, CVE-2026-109618 and CVE-2026-109619, for [domains/accounts]. Please confirm the PHP runtime and exact package revision serving these sites; the upstream or vendor advisory showing both fixes; whether all relevant workers and replicas have been restarted or replaced; and the completion time. If remediation is pending, please state the temporary protection, its limitations, the owner and the next update time. Please also distinguish patch completion from any investigation into earlier exposure.

Keep the reply with your incident record. Future you deserves better than searching six chat threads for “I think we fixed that.”

What a useful verification record looks like

Suppose you operate three PHP sites. This is a fictional record to show the method, not a report about any real organisation:

The middle row is the easy one to overstate. “The package manager finished” and “the processes serving visitors use the fixed runtime” are different claims. Keep both visible until the evidence connects them.

Record who checked, when, which host or container was inspected, and which vendor advisory supports the conclusion. Keep sensitive host details in the internal record, not a public support ticket. Track patch verification separately from incident investigation: a successful update does not answer whether earlier exposure was exploited.

This evidence habit also applies to the wider web stack. Security work becomes easier to hand over when the next person can see what was checked and what remains unknown, without decoding “all good” in a chat thread.

Frequently asked questions

Does a working website mean it is safe?

No. A successful page load demonstrates availability for that request. Use runtime and patch evidence to assess remediation; use an investigation to assess possible earlier compromise.

Is PHP-FPM unaffected?

Do not assume that. The official advisories distinguish exploit paths and prerequisites. The stale-state advisory includes a validated FPM path; the OOM advisory makes a narrower claim about demonstrated exploitation. Check your configuration and patch status rather than relying on the server-interface label. OOM advisory, stale-state advisory.

Do I need to rewrite the site in another language?

A language migration is not an emergency patch strategy. First establish a supported, remediated deployment. Evaluate any longer-term migration on its own merits, with time for testing. The server is having a difficult week; it does not also need a surprise identity crisis.

Can I test by running a public exploit against production?

I would use version, vendor and deployment evidence first. If deeper validation is necessary, arrange authorised testing in an isolated environment with the right expertise. A test that disrupts the service is a poor way to reassure its users.

Can I say there was no breach once the update is installed?

Only if the evidence from your investigation supports that statement. “Patched” and “no compromise found” should be separate, dated statements with a clear scope.

Sources, verification and image credit

The technical claims above were checked against PHP's own advisories, the PHP release record, NHS England's alert and first-party research from Wiz and Cloudflare on 23 October 2026. Sources can change as investigations develop. Recheck the live advisories before using this article as an operational reference.

The links next to each claim are the source trail. No global compromise count, blanket safety claim or measured search-trend ranking is asserted here. The practical workflow and provider-message template are editorial recommendations, not instructions quoted from a vendor.

Cover: AI-generated editorial illustration using the PHP logo by Colin Viebrock, sourced from PHP's official logo page. The logo has been incorporated into a generated desk scene; the adapted cover is offered under CC BY-SA 4.0. No endorsement by the PHP project is implied.

The next useful step is small: pick one hostname, identify the runtime actually serving it, and obtain the evidence that both fixes are running. Then repeat until the inventory has no unexplained gaps. Calm beats panic. Verified beats calm.