PHP2Shell: Two Critical Flaws and What the PHP Foundation Is Prioritising

Two critical flaws in PHP core let an unauthenticated attacker run code on a vulnerable server. The patches shipped within a day. Then, while the internet was still patching, the bot protection at our hosting platform took our own site offline. Our own testing had tripped it.

Two flaws, one very bad week

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 shipped on 21 October 2026, fixing CVE-2026-109618 and CVE-2026-109619. Both scored 9.2 out of 10 under CVSS v4.0. Both allow unauthenticated remote code execution.

The first flaw interrupts PHP at the moment it runs out of memory. Request data is left half-built, and the cleanup code treats the wreckage as valid. The second leaves request-owned state pointing at memory that has already been freed, and the next request handled by the same worker reads that stale state before normal startup clears it.

The attack is a single crafted multipart POST. No login. No unusual configuration. PHP runs most of the web: WordPress, Magento, Joomla, Laravel, and every custom store, portal and booking system built on them. The advisory lists every version from 5.4 upwards as affected.

The researchers were Calif, Wiz and OpenAI, and they have said AI models did much of the work. The flaws had sat in PHP for decades. What changed is that the barrier to weaponising them collapsed.

Our site went dark

At 21:20 UTC on 21 October, compourri.co.za stopped answering. Every page returned 403 Forbidden from an openresty layer in front of the web server. The response carried no PHP headers, no content security policy, nothing that our own configuration sets. Apache never saw the request.

The cause was our own testing. We spent the evening of the disclosure checking whether the exposure applied to us, and one of those checks sent a multipart POST with a PHP_SESSION_UPLOAD_PROGRESS field, which is the signature of the exploit. Our host runs Imunify360 bot protection in front of the web server, and it answered with a plain 403 Forbidden for every path we tried afterwards. Only files Cloudflare had already cached still loaded.

Two details make this worth writing about. First, no status page showed anything: our host's network status page read "no open network issues", and the platform vendor's page carried an incident about a different problem. An address-level block never shows up on a status page. Second, the block did not clear when the traffic stopped. It lifted on its own hours later, and the site came back without anyone changing a setting.

How to tell a block from an outage

The useful test costs one request. If the response carries none of the headers your own configuration sets, no content security policy, no strict transport security, no server header, then your web server never saw the request. Nothing is wrong with your site. Something in front of it refused to pass the request on.

Two more checks narrow it down. Send a request straight to the server's IP address with no host header and see what comes back. If the default page answers with the same challenge or the same refusal, the rule applies to the whole server rather than to your domain. And try the site from a different network, a phone on mobile data, for instance. If it loads from another address and not from yours, you have an address-level block.

What you cannot do is fix it in your control panel. Our account is cPanel, and Imunify360 does not appear anywhere in it. The module that blocked us runs in the platform's edge layer, above the web server, which is why cPanel shows a perfectly healthy account while the site is unreachable. The panel can still do two useful things: switch your PHP version, and whitelist your own address in the firewall plugin if your host installs one. The edge block itself only comes from the hosting provider.

The tools that protect you can take you offline. A block on one address can take a whole site down for a legitimate visitor, and the person who can lift it is your hosting provider.

The response deserves credit

The PHP project handled the fix well. The security team published an advance notice on 20 October, moved the release forward when the CVE identifiers leaked publicly, and shipped patched versions of four supported branches within roughly a day. The team also published minimal source backports for 7.4, 8.0 and 8.1 for anyone whose host does not backport.

Cloudflare shipped WAF rules to every customer, including free plans. CISA issued an alert the same day. Most large hosts began rolling patched builds during the week. That is a competent response to a critical bug, and it deserves to be said plainly.

The criticism that follows is not aimed at the people who shipped the patch.

Where the process did fail

The disclosure broke. Coordinated disclosure was scheduled for 22 October. On 20 October the CVE identifiers for both flaws appeared on Hacker News and social media, which forced the release up by a day and cut the window the ecosystem had to respond. Exploit code for one of the flaws was already circulating before the fix shipped.

Coordinated disclosure is a narrow and fragile process. When the identifiers leak, every host in the world learns the shape of the attack at the same moment the attackers do, and the patching window collapses. The PHP Foundation runs that process for a language that sits under a large share of the web. Whether the leak started inside a Foundation channel or in the researchers' own timelines, the result is the same: less time to patch and fewer people who knew what to look for.

Who runs the Foundation now

The PHP Foundation appointed Elizabeth Barron as Executive Director on 27 February 2026, after a search committee of Nils Adermann, Sebastian Bergmann, Lorna Mitchell and Ben Ramsey. Roman Pronskiy, the founding Executive Director, moved to JetBrains and left the board in September.

The Foundation's own announcement describes her background. She co-founded a volunteer nonprofit supporting women and non-binary individuals in the PHP industry, worked as Community Manager at GitHub where she led developer outreach programmes including Patchwork, and worked with CHAOSS, the Linux Foundation project that measures open source community health.

That record is not a side note. She led the CHAOSS Diversity, Equity and Inclusion working group, maintained it in the project's repository, and wrote the CHAOSS DEI Audit 2021, a nine-month self-audit of how the project handled inclusion. The recommendations are public, including the call to add a DEI component to every metric the project produced.

Since taking the role she has started a PHP Ambassador Programme, a PHP Onboarding Initiative special interest group and a Community Events Coalition, pushed accessibility work, and run a listening tour and a State of PHP survey. On the Foundation's blog she published around twenty posts between March and September 2026. Two of them were about security.

The question worth asking

Nothing in the record suggests that inclusion work caused this bug, or that it delayed the patch. The maintainers who shipped the fix in a day were not the Foundation's community team, and the Foundation did run security work in the same window: an Ecosystem Security Team announced in May 2026 with grant funding behind it, plus regular guidance for maintainers on handling reports.

The fair criticism is about fit and resourcing. A foundation for a language this widely deployed has one job that outranks the rest: making sure the unglamorous maintenance work gets funded and staffed. The audits. The fuzzing. The memory safety hardening. The release engineering. The long, quiet hours that keep a runtime defensible.

What a foundation chooses to spend its attention on is a fair thing to criticise, and the public record of what this one chose to spend attention on in 2026 is a long list of community, onboarding and inclusion programmes with two security posts beside it. That is a question about resourcing and accountability. It is not a question about anybody's personal politics, and it is not a claim that a policy caused a memory bug.

Two questions would settle the argument. First, does the Foundation publish a security response target, such as the time from advisory to patched release, the time from a report to triage, and the number of funded engineers working on the runtime itself? Second, is there a published plan for the end of life of 8.1 and older, with a migration path for the hosts that still serve them? Both are answerable in public.

What you should do this week

1. Ask your host for your exact PHP version. "Up to date" is not a version number. Write it down.
2. If it reads 8.1 or lower, plan the move to 8.3 or newer. 8.2.35 is the floor, and 8.2 stops getting security fixes on 31 December 2026.
3. Ask what their rollout does. Will there be a window where requests are blocked?
4. If you cannot upgrade today, set the interim measures from the PHP advisory in php.ini: session.upload_progress.enabled = 0, post_max_size = 8M and memory_limit = -1. They reduce exposure. They do not make you safe, and ini_set() in your own code does not work for the first one.
5. Search your logs for multipart POSTs against .php endpoints. Then look for files in your web root that your build never produced.
6. If your site suddenly stops loading, check whether the response carries your own headers. No headers means the request never reached your server, and the fix belongs to your host.
7. Keep a static copy of your site somewhere you can point DNS at. Ours would have kept the front page alive during the 403.

If you want a second opinion on whether your own server was left exposed, our remote assistance team can walk through it with you.

Editor's note: this article reflects the information available on 22 October 2026. The hosting provider rollout was still in progress when this was written.