PHP2Shell: what the October 2026 PHP flaw means for your website

What happened

On 21 October 2026 the PHP project shipped emergency releases for two critical bugs in PHP itself, now known as PHP2Shell. Both can let an attacker run code on a server without logging in. Within days, security firms were reporting attack traffic, and proof-of-concept scripts were circulating on GitHub.

This is not a plugin bug and not a WordPress bug. It sits one layer lower, in the language runtime that WordPress, Laravel, Drupal, Magento and most shared hosting in Indonesia run on. That is why it matters to a company website even if nobody on your team has touched the code in years.

severity score for both CVE-2026-109618 and CVE-2026-109619

CVSS 9.2

date PHP released the fixed versions

21 Oct 2026

of PHP installs with a known version were on end-of-life branches, per Qualys

71%

Is my website affected?

Probably, if your site runs on PHP and nobody has updated the server since 21 October. PHP says installations that serve web requests are at risk, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the setup with a demonstrated exploit, so treat it as the most urgent.

Linux distributions such as Debian, Ubuntu and RHEL often patch older version numbers in place. If your host says you are on "8.1.2-1ubuntu2.x", the fix may already be inside, so check the vendor advisory instead of the number alone.

What to do this week

1. 1.Ask your host, in writing, which PHP version serves your site and whether the PHP2Shell fix is applied. On shared hosting the host has to patch; you cannot do it yourself.
2. 2.On a VPS, update PHP from your distribution or the PHP packages you use, then restart every PHP worker. A config change or patch does nothing until the workers restart.
3. 3.If you cannot patch today, PHP recommends turning off session.upload_progress.enabled in the server-level php.ini and restarting. Setting it from inside the app with ini_set() or .user.ini is not enough.
4. 4.Move off PHP 8.1 or older. Those branches are outside regular support, and most exposed servers are on them.
5. 5.Look for signs of compromise if the site was unpatched for days: unknown admin users, new PHP files in uploads folders, changed .htaccess files, and outbound traffic you cannot explain.

A web application firewall helps buy time. Cloudflare has reported blocking attack traffic aimed at these bugs, including attempts to slip past its rules. A WAF is a seatbelt, though, not a fix. PHP's own guidance is blunt: updating is the only complete fix.

What this says about running WordPress

Most WordPress security advice is about plugins, and fairly so. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, about 91% of them in plugins. PHP2Shell is a reminder that the stack under the plugins needs owners too: the PHP version, the web server, the operating system.

On cheap shared hosting, those layers belong to the host. On a self-managed VPS, they belong to whoever set it up, which in many companies means nobody in particular. The question worth asking after this week is not "are we patched?" but "who would have patched us, and how would we know?"

If your site is a company profile, service pages and a blog, it does not need PHP running on every request. A static or server-rendered front end with the CMS behind a login removes most of this attack surface. We compare the options in WordPress vs Astro and Headless CMS vs WordPress.