The PHP Vulnerability Behind PHP2Shell: Who Is at Risk and What to Do Now

Two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, were patched on 21 October 2026. Here is how to tell if your website is exposed, and the steps to take today.

On Wednesday, 21 October, the PHP project shipped four security releases in a single afternoon and asked every PHP user to update immediately. By Thursday, US Google searches for "PHP vulnerability" had reached their highest point of the week, and the bug had a nickname: PHP2Shell.

If your website runs on WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel or almost any other PHP software, this one concerns your server, not your plugins.

This guide explains the PHP vulnerability in plain English, shows who is exposed and who is not, gives you the commands to check your own server, and lists what to do today and over the next few weeks. Every fact comes from PHP's own advisories, government security agencies or the vendors involved.

Key Takeaways

• Two critical flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, can let an attacker who is not logged in run code on a web server. PHP rates both 9.2 on CVSS v4.0.
• The fix is a PHP update: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux vendor's patched package. Updating WordPress, a plugin or a theme does not fix it.
• Every PHP installation that serves web requests is in scope. PHP rates the risk highest for Apache with mod_php.
• PHP 8.1 and older get no official release. You need a vendor backport, PHP's source backports or an upgrade.
• Amazon and Cloudflare have seen exploit attempts. As of 23 October, CISA has not added either CVE to its Known Exploited Vulnerabilities catalog, and no successful break-in has been publicly confirmed.
• After patching, restart every PHP worker, then check your logs back to 17 October.

What happened, in plain English

PHP is the language behind the server side of most websites. W3Techs finds it on 69.3% of websites whose server-side language it can detect (data dated 23 October 2026).

Researchers found that when PHP runs out of memory or hits a fatal error in the middle of a request, it can leave behind scraps of half-built or already-freed data. A carefully built request can make PHP reuse those scraps in a way the attacker controls. The result is remote code execution: the attacker runs their own commands on your server, with the same permissions as your website.

No login is needed, and no plugin bug is needed. The weakness sits inside PHP itself, underneath WordPress, Drupal or Laravel.

Here is how the week unfolded:

• 19 and 24 August: Wiz Research says it found the first of the bugs on 19 August and reported them to PHP on 24 August. PHP's advisories credit several researchers.
• 17 October: Amazon's honeypot network recorded a PHP2Shell exploitation attempt four days before disclosure.
• 20 October: PHP posted an advance notice of a critical release, with both flaws rated CVSS v4.0 9.2.
• 21 October, 03:02 UTC: Cloudflare switched on managed WAF rules for free and paid plans.
• 21 October: PHP released the fixed versions and published its security advisory.
• 23 October: PHP added an informational note about a third, much narrower issue (CVE-2026-115560), covered in the mitigation section below.

The technical detail

The two CVEs are separate bugs with the same root theme: PHP's error handling can leave memory in a state that a later step trusts by mistake.

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). PHP aborts a request with longjmp() when it runs out of memory. If that happens while request memory exists but is not fully set up, request cleanup can read or act on invalid data. The advisory lists ways to force the out-of-memory condition, such as multipart requests without a usable declared length, parts carrying many headers, empty file fields and deeply nested field names. PHP confirmed unauthenticated code execution against Apache mod_php with default limits.

CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Long-lived PHP workers keep some global state that points into memory owned by one request. If a fatal error, a timeout or an out-of-memory event leaves that state behind, the next request handled by the same worker can use freed memory before normal setup resets it. Session upload progress, which is on by default, is one confirmed path. PHP confirmed it against both mod_php and PHP-FPM, and the application does not even need to call session_start().

Affected versions. PHP's advisories list 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. PHP 8.1 and older are past end of life, so the project did not ship releases for them. Wiz reports that releases dating back to PHP 5.4 are affected by at least one of the issues.

Severity. PHP scores both flaws 9.2 on CVSS v4.0. On the older CVSS 3.1 scale, NVD gives CVE-2026-109618 a 9.8 and CVE-2026-109619 an 8.1. Red Hat rates CVE-2026-109618 "Important" at 8.1, because reliable exploitation needs precise heap manipulation and timing. The scores differ, but the advice is the same everywhere: patch.

Exploitation status. Reports differ, so here is exactly who said what:

• Amazon says it saw an attempt on 17 October and "broad exploitation attempts in the wild" after disclosure, while noting it is unclear whether any would have succeeded.
• Cloudflare says it observed attack traffic targeting its customers.
• Canada's Cyber Centre said on 21 October that a proof of concept is public but it had not identified active exploitation.
• Neither CVE appears in CISA's Known Exploited Vulnerabilities catalog as of 23 October.

In short, attackers are trying. Treat the risk as real, without assuming every unpatched site has already been breached.

Who is in danger

PHP's advisory puts it plainly: all PHP installations serving web requests are at risk. How exposed you are depends mostly on how PHP runs on your web hosting setup.

Hosting setups

• Apache with mod_php. Highest risk, according to PHP, because the attack can run before any application code does. In a phpinfo page or WordPress Site Health, this shows as "Apache 2.0 Handler".
• PHP-FPM behind Nginx or Apache. Exposed. PHP's source analysis suggests the out-of-memory bug can be reached, though no complete FPM exploit has been shown, and the session upload progress path was confirmed against FPM.
• php-cgi, FrankenPHP and LiteSpeed. All named in PHP's at-risk list.
• Shared hosting. Your host patches PHP. Your job is to confirm it happened.
• Managed WordPress platforms. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are already protected, with nothing for customers to do.
• cPanel and WHM servers. cPanel's EasyApache 4 25.91 release fixes ea-php74 through ea-php85. cPanel also patched its own internal PHP, which runs the cPanel interfaces and Roundcube webmail: versions 138.0.18, 136.0.50 and 134.0.66 include PHP 8.4.27, and 110.0.153 carries backported fixes for PHP 8.1.34.
• Plesk servers. On 21 October, a Plesk staff member said the fixes would be included in Plesk PHP packages but gave no ETA. Check Plesk's announcements for your Obsidian version before you assume you are covered.
• AWS. AWS's bulletin says Elastic Beanstalk managed platform updates apply the fix in the next maintenance window. Lightsail instances cannot be updated in place, so AWS advises creating new instances from updated blueprints and migrating. Lambda functions using custom runtimes or container images need a rebuild and redeploy.
• Docker and other containers. Rebuild on a patched base image and redeploy. A patched host does not patch the PHP inside your container.
• XAMPP and other local stacks. These bundle their own PHP. The risk is low while they only listen on your own machine, but any copy reachable from a network needs the same update.

CMSs and frameworks

Because the bug lives in the PHP runtime, every PHP application running on an unpatched version is in scope. Datadog's analysis notes that any PHP script exposes the vulnerable path, even one that only prints a response. Wiz demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images.

That covers every major PHP CMS and framework:

• CMSs and commerce platforms: WordPress and WooCommerce, Drupal, Joomla, self-hosted Magento Open Source and Adobe Commerce, PrestaShop, OpenCart, TYPO3, Craft CMS, Statamic, MediaWiki, phpBB and Moodle.
• Frameworks: Laravel, Symfony, CodeIgniter and CakePHP, plus any custom PHP application.

None of these need their own patch to close the hole. WordPress.org said directly that no WordPress update is required or planned. The same logic applies to the others: the fix is in PHP, so updating the CMS, a theme or a plugin does not close it.

Who is not affected, and why

• Hosted website builders such as Shopify, Wix and Squarespace. You never manage a PHP runtime on these platforms, so there is nothing for you to patch. The provider looks after its own stack.
• Static sites and JavaScript stacks with no PHP anywhere. A Next.js or Astro site with no PHP server is out of scope. A headless WordPress backend behind it is not, because that backend still runs PHP.
• Servers already on 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or on a vendor package that lists both CVEs as fixed, with every PHP worker restarted since.
• PHP 8.6 RC4. PHP says this release candidate includes the fixes. Earlier 8.6 test builds do not, and no 8.6 build belongs in production yet.
• Command-line-only PHP. PHP's advisory targets installations that serve web requests, so cron jobs and CLI scripts are lower priority. They usually share the same package, though, so they get patched along with everything else.

How to check if the PHP vulnerability affects your server

Work through these steps in order. The goal is to confirm the PHP that actually serves your website, which is not always the one your terminal shows.

Step 1: Find the PHP version that serves your site. Start inside your CMS:

• WordPress: Tools, then Site Health, then the Info tab, then Server. Note the PHP version and the PHP SAPI. "Apache 2.0 Handler" means mod_php. "fpm-fcgi" means PHP-FPM.
• Drupal: Reports, then Status report.
• Joomla: System, then System Information.

Step 2: Check the server itself. If you have SSH access:

# Version of the command-line PHP (can differ from the web runtime)
php -v
# Is Apache loading PHP as a module (mod_php)?
apachectl -M 2>/dev/null | grep -i php
# Which PHP-FPM services are running?
systemctl list-units --type=service | grep -i fpm
# Is session upload progress still on? (CLI config; check FPM pool files too)
php -i | grep -i "session.upload_progress.enabled"
# The PHP version Composer sees, useful in CI and deploy scripts
composer show --platform | grep "^php "

# Version of the command-line PHP (can differ from the web runtime)
php -v
# Is Apache loading PHP as a module (mod_php)?
apachectl -M 2>/dev/null | grep -i php
# Which PHP-FPM services are running?
systemctl list-units --type=service | grep -i fpm
# Is session upload progress still on? (CLI config; check FPM pool files too)
php -i | grep -i "session.upload_progress.enabled"
# The PHP version Composer sees, useful in CI and deploy scripts
composer show --platform | grep "^php "

Step 3: Read the package changelog, not just the version number. Linux distributions often backport fixes without changing the upstream version. On Ubuntu 24.04 LTS, for example, the fixed package is php8.3 version 8.3.6-0ubuntu0.24.04.13. That looks "old", yet it is patched. Search the changelog for the CVE numbers:

# Debian and Ubuntu
apt changelog php8.3-fpm 2>/dev/null | grep -m3 -E "CVE-2026-10961[89]"
# RHEL, AlmaLinux, Rocky Linux and CloudLinux
rpm -q --changelog php-fpm | grep -m3 -E "CVE-2026-10961[89]"
# cPanel EasyApache packages
rpm -qa 'ea-php*-php-fpm' | sort
rpm -q --changelog ea-php81 | grep -m3 -E "CVE-2026-10961[89]"
# Plesk (adjust the version folder)
/opt/plesk/php/8.3/bin/php -v

# Debian and Ubuntu
apt changelog php8.3-fpm 2>/dev/null | grep -m3 -E "CVE-2026-10961[89]"
# RHEL, AlmaLinux, Rocky Linux and CloudLinux
rpm -q --changelog php-fpm | grep -m3 -E "CVE-2026-10961[89]"
# cPanel EasyApache packages
rpm -qa 'ea-php*-php-fpm' | sort
rpm -q --changelog ea-php81 | grep -m3 -E "CVE-2026-10961[89]"
# Plesk (adjust the version folder)
/opt/plesk/php/8.3/bin/php -v

Step 4: Confirm the workers restarted after the update. A patched package on disk does nothing until PHP reloads it.

systemctl status php8.3-fpm | grep Active
systemctl status apache2 | grep Active    # httpd on RHEL-based systems

systemctl status php8.3-fpm | grep Active
systemctl status apache2 | grep Active    # httpd on RHEL-based systems

If the "active since" time is earlier than your update, restart the service.

On shared or managed hosting, ask your host in writing: "Has the PHP that serves my site been patched for CVE-2026-109618 and CVE-2026-109619, and have the PHP workers been restarted?" A clear yes with a date is what you want.

What to do now

1. Update PHP. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution's patched package. The PHP project is blunt about this:

"There are no complete mitigations, updating is the only safe choice."

2. Restart every PHP worker. Restart PHP-FPM pools, Apache, LiteSpeed and any container running PHP.

3. Deal with old branches. PHP 8.1 and older get no official release. Your options:

• A vendor backport. Ubuntu Pro covers older LTS releases, including PHP 7.4 on 20.04, and cPanel shipped backports for ea-php74, ea-php80 and ea-php81.
• PHP's own minimal source backports for 7.4, 8.0 and 8.1, if you build PHP from source.
• An upgrade to a supported branch, tested on a staging site first.

If none of these is possible soon, the UK's NCSC advises organisations to consider taking the system offline until it can be fully mitigated. WordPress.org gives the same advice for self-managed servers on PHP older than 8.2.

4. If you cannot patch today, reduce exposure. PHP lists interim measures that cut off specific attack paths. None of them makes a server safe on its own:

• Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration, then restart every worker. Do not rely on ini_set() or .user.ini for this. PHP's 23 October note recommends keeping it off until the next regular release anyway, because of the narrower CVE-2026-115560 issue.
• On PHP 8.5, set fatal_error_backtraces=0 and restart.
• Keep post_max_size low (PHP suggests 8M without uploads, 32M with them) and keep upload_max_filesize below it.
• PHP also suggests memory_limit=-1 enforced with php_admin_value, paired with a container or cgroup memory limit. Talk to your host first: removing the PHP memory limit means a runaway script can consume far more server memory.
• If your site never accepts file uploads or multipart forms, block multipart requests at the proxy or WAF, as both PHP's advisory and Amazon suggest.
• Turn on WAF rules. Cloudflare's managed rules cover free plans automatically, and paid plans should confirm the managed ruleset is set to block. AWS WAF users should run the latest PHP managed rule group. Vercel applied rules automatically for PHP traffic it serves or proxies. Every one of these vendors says a WAF does not replace patching.

5. Check your logs back to 17 October. Amazon recommends starting investigations from 17 October, not the disclosure date. Look for:

• POST form uploads containing the string PHP_SESSION_UPLOAD_PROGRESS (Amazon).
• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained PHP worker churn (Wiz).
• "Allowed memory size … exhausted" errors reported at "Unknown on line 0", and Apache AH00052 segmentation fault lines (Datadog).
• A web server process starting a shell, plus unexpected files, accounts, processes or outbound connections (Datadog and Canada's Cyber Centre).

Clean logs do not prove a server is safe, and noisy logs do not prove it was breached. Memory errors happen on healthy sites too.

6. If you find signs of compromise, take the site offline, restore from a backup made before 17 October onto a patched server, rotate database, admin, SFTP and API credentials, and follow a checklist such as WordPress.org's guide for hacked sites.

7. Fix the habits that made this hard. Once the emergency passes:

• Know which PHP branch every site runs and when its support ends. PHP's supported versions page shows 8.2 security support ending on 31 December 2026, 8.3 on 31 December 2027, 8.4 on 31 December 2028 and 8.5 on 31 December 2029.
• Plan any 8.2 site's move to 8.4 or 8.5 now, while you have a few weeks rather than a few hours.
• Set a written patch window for critical runtime fixes. Amazon advises measuring response to critical internet-facing flaws in hours, not days.
• Keep tested, off-server backups and a staging copy of every important site.
• Treat outdated runtimes as a known risk. OWASP's Top 10 lists vulnerable and outdated components as a core web application risk for exactly this reason.

What we're doing for our clients

For the sites we build and look after, our website maintenance routine this week is the same checklist as above. We confirm the PHP runtime and SAPI for each site rather than trusting the CLI version, check package changelogs for both CVE numbers, restart workers and verify the restart time, and review logs from 17 October onward. Sites still on PHP 8.2 get an upgrade plan to a newer branch before 8.2's security support ends on 31 December 2026.

If you run a WordPress or WooCommerce site and are not sure what your host has done, our WordPress development team can run these checks with you.

FAQ

What is PHP2Shell and how does it affect my website?

PHP2Shell is the nickname for two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619. On an unpatched server, an attacker who is not logged in could run code with your website's permissions. That puts your files, database and customer data at risk. Your site is affected only if the PHP serving it has not been updated.

Do I need to update WordPress, Drupal or Joomla to fix it?

No. The fix is in PHP, not in the CMS. WordPress.org says no WordPress update is required or planned. Keep your CMS updated for its own security fixes, but only a PHP update closes PHP2Shell.

Will a security plugin or a firewall protect my site?

A security plugin cannot be relied on, because the attack happens in PHP's own request handling, which can run before WordPress loads. A network WAF from Cloudflare, AWS or Vercel can block known attack patterns, and it is worth turning on while you patch. Every one of those vendors says a WAF does not replace the PHP update.

My site is on shared hosting. What should I do?

Ask your host in writing whether the PHP serving your site has been patched for both CVEs and whether PHP workers have been restarted. Then check the PHP version in your control panel or in WordPress Site Health. If your host cannot confirm a date, consider moving to a host that can.

Is there a script that tests whether my server is vulnerable?

Running exploit code from the internet against a live server is risky and may itself be harmful. A safer check is the one in this guide: confirm the serving PHP version, look for both CVE numbers in your package changelog, and confirm the restart. Commercial scanners such as Tenable's Nessus have also added detection plugins.

My server shows an older PHP version number, but my host says it is patched. Who is right?

Possibly both. Linux distributions backport security fixes without changing the upstream version number. Ubuntu 24.04's patched PHP 8.3 package, for example, still reports 8.3.6. The package changelog is the reliable record, so search it for the two CVE numbers.

My site runs an end-of-life PHP version. Do I have to take it offline?

Not necessarily, if you can get a patched build. Check for a vendor backport through Ubuntu Pro, cPanel or another long-term support vendor, or build from PHP's source backports. If you cannot get a fix quickly, the UK's NCSC and WordPress.org both suggest considering taking the server offline until you can upgrade.

Has anyone actually been hacked through PHP2Shell yet?

As of 23 October, no successful compromise has been publicly confirmed. Amazon and Cloudflare have reported exploit attempts, and CISA has not added the CVEs to its Known Exploited Vulnerabilities catalog. That can change quickly, which is why patching comes before waiting for proof.

Why do PHP, NVD and Red Hat give different severity scores?

They use different scoring systems and assumptions. PHP scores 9.2 on CVSS v4.0. NVD scores CVE-2026-109618 at 9.8 on CVSS 3.1, while Red Hat scores it 8.1 because reliable exploitation needs precise heap manipulation. All three agree it needs patching.

The bottom line

The PHP vulnerability behind PHP2Shell is serious because it sits below everything you normally patch. Your CMS can be fully up to date while the PHP underneath it is not. Five steps get you clear: find the PHP that serves your site, confirm the fix in the package changelog, restart the workers, check your logs back to 17 October, and plan your move off any branch that is near end of life.

If you'd like a second pair of eyes on your setup, get in touch with Billion Web Studio.

Ganesh Shanmugam is the founder of Billion Web Studio, a website development company building for businesses in the USA, the UK, Dubai and the wider UAE, Canada, Australia and India.