PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Is Your Website Affected and What to Do Now

What is PHP2Shell?

PHP2Shell covers two separate memory-safety bugs in the PHP engine itself, not in WordPress or any framework. CVE-2026-109618 is triggered when PHP runs out of memory while a request is only partly set up, which can let cleanup code treat attacker-controlled data as valid. CVE-2026-109619 is a use-after-free: some request state survives after its memory has been freed, which can leak memory and lead to code execution. The PHP project rates both at CVSS v4.0 9.2.

The important word is unauthenticated. An attacker does not need an account, a password or a vulnerable plugin. A crafted web request to a vulnerable PHP server can be enough, and on Apache with mod_php the PHP project says the exploit can fire before any of your application code runs. That is why security teams treat it as an emergency even for websites that are otherwise well maintained.

Is my website affected?

If your website or application runs on PHP and serves web requests, assume yes until you have checked. PHP.net lists every web setup as at risk: PHP-FPM (the usual setup with Nginx), Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php. Researchers traced the vulnerable code back to PHP 5.4, released in 2012.

To check, find your exact PHP version. In WordPress, go to Tools, then Site Health, then Info, then Server. In cPanel or Plesk, look for the PHP version selector. On your own server, run php -v and also check the version PHP-FPM reports, because the command-line PHP and the web PHP are sometimes different. If the version is below 8.5.12, 8.4.27, 8.3.36 or 8.2.35 on its branch, you are vulnerable. Managed hosts usually patch the PHP binary for you, but shared hosting accounts can stay on an old PHP branch for years unless someone switches them.

Is PHP2Shell being exploited?

Yes. Amazon’s threat intelligence team reported an exploitation attempt against its honeypots on 17 October, four days before the public advisory, and more attempts after disclosure. Cloudflare reported early attack traffic and shipped firewall rules, and watchTowr said it had reproduced both bugs. The CVE identifiers leaked before the planned release, which is why PHP moved the release forward by a day.

Claimed exploit code is also circulating. Some of it is fake and some of it may contain malware aimed at the people who download it, so do not run proof-of-concept code against your own server unless a security professional has reviewed it. Patching is faster and safer than testing.

What to do today, in order

First, update PHP to a fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On Linux servers, install the patched package from your distribution, which received the fix in advance. On managed or shared hosting, confirm with your host that the patched build is live for your account, and switch your site to PHP 8.4 or 8.5 if it is still on an older branch. Restart every PHP-FPM pool or Apache process afterwards, because old workers keep running the old code.

Second, if you cannot update today, apply PHP’s interim mitigations. They reduce exposure but, in PHP’s own words, do not make an installation safe. For CVE-2026-109619, set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config (not with ini_set() or a .user.ini file), and on PHP 8.5 also set fatal_error_backtraces=0. For CVE-2026-109618, PHP suggests memory_limit=-1 set through php_admin_value so applications cannot override it, a sensible post_max_size, and a container or cgroup memory limit; do not use RLIMIT_AS or RLIMIT_DATA. Restart all workers after any change.

Third, if the site runs PHP 8.1 or older, you are outside official support. PHP published source backports for 7.4, 8.0 and 8.1, and some long-term-support vendors package them, but anything older has no fix at all. CISA advised organisations that cannot update, or that run PHP 8.1 or earlier, to consider taking those PHP systems offline. In practice that means an urgent upgrade or migration project, which we cover in our guide to PHP end of life.

How to tell if your site was hacked before you patched

Patching closes the door but does not remove anyone who already came in. Because exploitation started before disclosure, check for the usual signs of a compromised PHP server: new or recently modified .php files in upload, cache or temp folders; unfamiliar admin users; new cron jobs; outgoing connections from the web server; unexpected redirects or spam pages in Google results; and PHP workers crashing with memory errors in your logs around 17 to 23 October.

If you find any of these, treat it as an incident: take a snapshot for evidence, rotate database, API and hosting passwords, restore clean code from version control or a known-good backup, and only then bring the site back. Our urgent security check guide walks through this step by step.

The follow-up advisory: CVE-2026-115560

On 23 October PHP published a second, smaller advisory about session upload progress, tracked as CVE-2026-115560. It only affects applications that set session.serialize_handler to php_binary or php_serialize in configuration and then switch it to php at runtime before session_start(), with upload progress still enabled. PHP considers this unlikely in practice and will fix it in the next regular release. If you already disabled session.upload_progress.enabled for PHP2Shell, keep it disabled and no further action is needed.

Get your website checked

WebsNexus can confirm your PHP version and patch status, apply the fix or mitigations, review WordPress core and plugins, and look for signs of compromise, usually within a day. Security reviews start from $100. If your site is stuck on PHP 7 or older, we can also upgrade it or migrate it to Node.js, Next.js or Python so it is back on supported technology. Message us on WhatsApp at +92 326 6379003 with your website address.