PHP2Shell (CVE-2026-109618 and CVE-2026-109619): what it is and what to do

The PHP project has released emergency updates for two critical flaws in PHP itself, together known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The fixes shipped on October 21, 2026. On a vulnerable server, a single crafted web request from someone who has never logged in can lead to the attacker running code as the web server user. The flaws are in the PHP runtime, not in WordPress, Drupal, or any plugin, so every PHP site is in scope until the server underneath it is updated. This article reflects what is known as of October 23, 2026.

What the flaws do

Both flaws involve PHP reusing memory it should have discarded. One is triggered when PHP runs out of memory while it is still setting up a request, leaving half-built data that the cleanup code later trusts. The other leaves internal state behind after a request ends, which the next request on the same PHP worker can pick up. Researchers have also shown that the same weakness can leak memory from other requests, which may contain passwords, session tokens, and API keys.

The PHP project rates both flaws 9.2 out of 10 (CVSS v4.0). Every way of running PHP for the web is affected, including PHP-FPM, Apache with mod_php, and php-cgi. The risk is highest on Apache with mod_php, where the attack can succeed before any of the site's own code runs. Details leaked online on October 20, before the fixes shipped, and security firms have reported attack attempts since. The PHP Foundation says no working public exploit existed at release. Either way, treat this as urgent.

Which versions are affected

No WordPress or Drupal update is needed or planned for this. Hiding error messages does not help, and the PHP project says no configuration change fully closes the flaws. Updating PHP is the fix.

Check that a server is really patched

Linux distributions backport the fix into the version they already ship, so the version number often stays the same. A fully patched Ubuntu 24.04 server still reports PHP 8.3.6 in php -v; the fix is in package 8.3.6-0ubuntu0.24.04.13. Check the package, not the PHP version:

# Ubuntu and Debian: list installed PHP packages and versions
dpkg -l | grep -E '^ii +php'

# Red Hat Enterprise Linux, Amazon Linux, Rocky, Alma
dnf updateinfo list --cve CVE-2026-109618
rpm -qa 'php*' | sort

Compare the result with your vendor's notice: Ubuntu USN-8948, Red Hat bulletin RHSB-2026-013, and the Amazon Linux, Debian, and SUSE advisories. If dnf updateinfo still lists the advisory, the update is not installed.

Installing the package is half the job. Running PHP workers keep the old code in memory until they restart, so restart PHP-FPM and Apache afterwards (for example systemctl restart php8.3-fpm or systemctl restart httpd). No server reboot is needed.

If you run PHP outside a standard server

• Amazon Lightsail: running instances cannot be updated in place by AWS. Create a new instance from the updated blueprint and move the site.
• AWS Elastic Beanstalk: update to the latest platform version, or let managed platform updates apply it.
• Containers and custom images: rebuild on a patched base image and redeploy. An old image stays vulnerable after any restart.

If you cannot patch today

These steps reduce exposure until you can update. They do not make an unpatched server safe.

• Set session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool configuration, then restart every worker. Setting it in .user.ini or application code is too late to help. The PHP project now advises keeping it off on patched servers too, until its next regular release, because of a related issue (CVE-2026-115560). It only affects upload progress bars built on PHP sessions, which few sites use.
• Lower post_max_size to 8M, or 32M if the site accepts uploads, with upload_max_filesize below it.
• Restrict who can reach the server, and keep any web application firewall protections switched on.

Signs worth investigating

Look in web server and PHP logs for bursts of "Allowed memory size exhausted" errors after large form or upload requests, repeated HTTP 500 responses, unusually long or malformed PHPSESSID cookies, and PHP workers restarting without explanation. If a server was exposed and unpatched and you see these signs, treat it as a possible compromise: rotate database passwords, API keys, and other secrets the site uses, and follow the first-hour steps for a hacked site.

How eWay is handling PHP2Shell

On environments eWay manages, this follows our emergency change path rather than the monthly maintenance window. We are applying the fixed PHP packages from each vendor's security channel across the Ubuntu, Red Hat Enterprise Linux, Amazon Linux, and other Linux distributions we run, then restarting PHP so the fix takes effect. Behind a load balancer, servers are updated one at a time so sites stay up. We have also added targeted web application firewall rules as an extra layer, and we monitor HTTP error rates for the patterns above.

If eWay manages your servers, you do not need to change anything. If you need confirmation for an auditor, insurer, or security team, ask and we will provide it for your environments. If you run PHP yourself or with another host, use the checks above, and see preparing for a PHP version upgrade if you are on 8.2 or older.

What to include in a support ticket

• The sites or servers you want checked or confirmed
• Whether you need written confirmation, and for whom
• Any scanner or security notice you received, with its date
• Any of the warning signs above, with times and log excerpts

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. Related reading: keeping servers patched and the PHP project's security advisory.