PHP2Shell: Two Critical PHP Flaws Leave Millions of Servers Exposed

PHP quietly powers the back end of most of the web. W3Techs measures it on 69.3% of all websites whose server-side language can be identified. WordPress alone runs close to 40% of the web, and it sits on PHP — so do Magento, Drupal, Joomla, phpBB, WHMCS and MediaWiki. When a flaw turns up inside PHP itself, the blast radius is not one app. It is the foundation under millions of sites at once.

That is what happened this week. On Tuesday, October 20, word began spreading that two unpatched PHP vulnerabilities were about to be disclosed. Screenshots circulated, including one showing an exploit tool named PHP2Shell. Researchers at watchTowr examined the leaked material and confirmed the bugs were real and led to remote code execution. PHP had planned an orderly, scheduled fix. The leak forced an emergency release instead — shipped on Wednesday afternoon, slightly ahead of the planned 14:00 UTC slot.

Flaw one: turning PHP's own safety valve against it

The first bug, CVE-2026-109618, lives in how PHP reacts when a request runs out of memory. Normally, hitting the memory limit triggers a controlled shutdown of that request. The problem is timing: parts of the request's memory can be reached before they are fully initialised, and if an allocation fails in exactly that window, the emergency exit path skips proper accounting. Cleanup then runs over data that was never valid — and a crafted request can steer that confusion into executing the attacker's code.

Forcing that out-of-memory moment turns out to be easy. PHP processes multipart/form-data request bodies — the format browsers use for file uploads — before any application code runs. A request that never declares a usable content length can slip past the post_max_size limit, and empty file fields do not count against the max_file_uploads cap even though PHP still builds internal records for each one. Stack enough of them together and memory runs dry on demand, at the precise spot where the bug sits.

Flaw two: a use-after-free in worker memory

The second bug, CVE-2026-109619, is a different failure with the same destination. A PHP worker process keeps state in memory between requests — error data, session data and similar. That state is supposed to be wiped before the memory is reused. A fatal error, including one triggered by the out-of-memory trick above, can skip the wipe. PHP then frees memory the worker still points to, and the next request to land on that worker reads a dangling pointer. With a carefully shaped heap, that use-after-free also ends in code execution with the web server's privileges.

PHP's own analysis proved the first bug end-to-end over HTTP on Apache with mod_php on default settings. PHP-FPM — the setup most managed hosts run — is considered susceptible to the first flaw, and for the second flaw the session route reached working code execution on both mod_php and FPM. There is no "safe" setup here. Both need the patch.

Why governments switched their own websites off

The clearest signal of how serious this was came from the Netherlands. DigiD, the national login service, put up a "temporarily unavailable" page. MijnOverheid went down with it, as did the websites of the Dutch parliament and the NCSC — the very agency responsible for warning the public. Finland's agencies pulled sites offline as a precaution, and in Germany, Freiburg University took its central websites, intranet, learning platform and student webmail offline at 10:39 on Wednesday morning.

None of these were confirmed break-ins. They were calculated decisions: better unreachable for a day than running a PHP build an unauthenticated stranger could take over. Security agencies across Europe, Australia, Japan and the UK issued the same advice — patch immediately, or take the application off the public internet until you can.

Updating WordPress does not fix this

This is the part that catches site owners out. The bug is not in WordPress, your theme or your plugins, so updating them changes nothing. The vulnerable code is in the PHP interpreter on the server underneath everything. The only question that matters is which PHP version your host runs, and whether they have updated it. If you are on shared hosting, the fix is entirely in your provider's hands — contact them today and ask directly whether they have applied the October 21 PHP security release.

What to do right now

1. Check the version your site actually runs. php -v shows the command-line build, which is not always the one serving your website. Check the web-facing one with a phpinfo page or php-fpm8.3 -v.
2. Update PHP to one of the patched releases above — or confirm your host already has.
3. Restart the service. Workers that are already running keep the old code in memory. Restart PHP-FPM or Apache after updating.
4. Do not trust the version number alone. Linux distributions often backport security fixes into packages that keep an older version string. Check the package changelog for the CVE numbers instead — apt changelog php8.3-cli on Debian/Ubuntu, rpm -q --changelog php on Red Hat systems.
5. Skip the config workarounds. Tweaks circulating online, such as disabling session upload progress, block only one attack path. They do not make an unpatched server safe. Only the patch closes the hole.

Where things stand

Cloudflare reported early attack attempts against PHP sites on Wednesday morning and pushed out firewall rules to blunt them; hosting companies reported the same pattern. As of October 21, however, there was no confirmed break-in attributed to these flaws — the Dutch NCSC said it had seen no active abuse, and neither CVE had yet appeared on the US government's known-exploited-vulnerabilities list. What is public is proof-of-concept code, and after a leak like this, mass scanning typically begins within hours.

So the window is now. If you run anything on PHP — a blog, a shop, a forum, a company site — the only thing that matters is whether your server was patched before someone came looking. Check your version today.