PHP2Shell: two critical PHP flaws and what to do today

On October 21, 2026 the PHP project released emergency updates for two critical vulnerabilities in PHP itself, nicknamed PHP2Shell. They can let an attacker run their own code on a web server without logging in. The bugs are in the PHP runtime, not in a plugin or framework, so they affect WordPress, Magento, Drupal, Joomla, Laravel and custom PHP applications alike.

The short version: update PHP on every server that serves web requests, today, and restart it. The rest of this post explains who is affected, how to patch properly, what to do if you can’t patch yet, and how to check that nobody got in first.

What happened

The PHP security team rates both vulnerabilities 9.2 out of 10 (CVSS v4.0, Critical):

• CVE-2026-109618, remote code execution via out-of-memory corruption. If PHP runs out of memory while it is still setting up a request, the cleanup that follows can treat half-initialised data as valid.
• CVE-2026-109619, remote code execution via stale state. Data that belongs to one request can survive after its memory is freed, and a later request handled by the same worker can use it before it is reset.

The release had been announced for October 21 at 14:00 UTC. The CVE numbers leaked on October 20, and the fixes were published several hours early. The researchers credited include Calif, Wiz and OpenAI. Calif reports the earliest affected code dates back to PHP 5.4.

Who is affected

According to the PHP advisory, every PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

• Apache with mod_php is the most urgent. PHP demonstrated an exploit where an unauthenticated request triggers the attack before any application code runs, so your own code being secure doesn’t help.
• PHP-FPM also needs patching. It blocks one specific attack path, but PHP confirmed remote code execution against FPM through another route under the right application conditions.
• Popular applications are exposed. Calif says it confirmed pre-login code execution against specific versions of WordPress, Drupal, Joomla and Magento.

Is it being exploited?

Yes, attempts have started. Cloudflare says it is seeing early attacks and has deployed WAF rules for the known exploit paths on all plans, including the free one. watchTowr reports exploitation attempts against both vulnerabilities. Code claiming to exploit PHP2Shell is circulating publicly; some of it is unverified and may itself contain malware, so don’t run it on systems you care about.

Fixed versions

Linux distributions received the patches in advance. Ubuntu (USN-8948) and Red Hat have already published updates. Distribution packages often backport fixes, so a patched package can still show an older version number such as 8.1.2. Check your vendor’s advisory for the exact package release rather than relying on php -v alone.

How to patch properly

1. Find every PHP installation. Servers often run more than one PHP version: one for the command line, others for web sites, plus copies inside containers and hosting control panels. The version php -v shows may not be the one serving your site.

# Debian / Ubuntu
dpkg -l | grep -E '^ii +php[0-9.]*-(cli|fpm|common)'
# RHEL, AlmaLinux, Rocky
rpm -qa 'php*' | sort
# Is PHP loaded inside Apache (mod_php)?
apachectl -M 2>/dev/null | grep -i php

2. Update from your vendor.

# Debian / Ubuntu (including the ondrej/php PPA); upgrades all packages, PHP included
sudo apt update && sudo apt upgrade
# RHEL, AlmaLinux, Rocky
sudo dnf upgrade 'php*'

If you install PHP from the volunteer-run Remi repository, note that on release day PHP’s advisory warned Remi would not have updates that day. Check that a fixed build is available before assuming you’re covered. For containers, rebuild your images on a patched base image and redeploy them. On managed hosting, confirm with your provider; some platforms’ automatic updates don’t cover PHP.

3. Restart everything that runs PHP. Updated files on disk don’t help until the old processes are gone.

sudo systemctl restart php8.3-fpm   # one per FPM version you run
sudo systemctl restart apache2      # or httpd; required for mod_php

4. Verify the running version. Check what each site actually runs, for example through your hosting panel or a temporary, access-restricted phpinfo() page that you delete straight afterwards.

If you can’t patch today

PHP is clear that only updating is a complete fix. If an update has to wait a few hours, its advisory lists settings that block the confirmed attack paths. Put them in php.ini, the FPM pool or the Apache configuration, not in application code or .user.ini, then restart every PHP worker:

; Temporary measures until PHP is updated. They reduce exposure; they are not a fix.
memory_limit = -1                    ; enforce with php_admin_value so apps can't override it
post_max_size = 8M                   ; 32M if you need uploads; keep upload_max_filesize lower
session.upload_progress.enabled = 0
fatal_error_backtraces = 0           ; PHP 8.5 only

Removing the memory limit makes it easier for a busy or attacked server to run out of memory, so keep it temporary and put a container or service-level memory limit in place. Other stopgaps:

• Put a web application firewall in front. Cloudflare’s free rules or Google Cloud Armor’s managed rules cover the known exploit paths.
• Lock down the origin. If your server’s IP address is reachable directly, attackers can go around the WAF. Allow web traffic only from your proxy’s address ranges.
• Take PHP out of the path. If a site doesn’t need PHP, unload mod_php or remove the PHP handler for that site.
• Isolate what you can’t protect. CERT-EU recommends taking internet-facing applications off public networks until a fix is applied.

Check you weren’t hit before patching

Indicators specific to these exploits are still emerging. As Rapid7 points out, a clean log is not proof that a server is safe. After patching:

• Look for PHP files that appeared or changed recently, especially in upload, cache and media folders. Adjust the path to wherever your sites live: find /var/www -name '*.php' -newermt '2026-10-19' -ls
• In WordPress, Magento and other admin panels, check for administrator accounts you don’t recognise.
• Review web server error logs for crashes and memory errors from October 20 onward, and look for unexpected outbound connections from the server.
• If anything looks wrong, restore from a backup taken before October 20, then change database, admin and API credentials.

Old PHP versions are the bigger problem

PHP 8.1 and older are past end of life and only got source patches this time, and 7.3 and older got nothing. PHP 8.2 reaches end of life on December 31, 2026, so after this the next critical bug in 8.2 won’t be fixed upstream either. The same applies to the operating systems underneath. Servers on CentOS 7 and other unsupported releases may not receive packaged fixes at all, which leaves building from source or migrating.

If this week was a scramble, use it to plan an upgrade to PHP 8.3 or newer on a supported operating system.

How Zenisca can help

We’ve been patching and maintaining Linux and Windows servers, WordPress sites and Magento stores for businesses in Mississauga, Toronto and across the GTA since 2011. For PHP2Shell we can:

• Patch today. We find every PHP installation on your servers, containers and hosting panels, update each one to a fixed build, restart it and confirm the running version.
• Protect what can’t be patched yet. For end-of-life PHP or operating systems, we apply PHP’s interim settings, build the source patches where needed, set up WAF rules and lock down direct access to your server.
• Check for compromise. We review logs, file changes and admin accounts, clean up if needed, and restore from known-good backups.
• Test your application. We check that your WordPress site or Magento store still works after the update, including checkout, forms, scheduled jobs and integrations.
• Get you onto supported versions. We plan and carry out upgrades off PHP 8.2 and older and off unsupported operating systems, then keep them patched with our server security and maintenance service.

If you’re not sure whether your sites are affected, or you’d like it handled today, contact us or call +1 (416) 900-3785.

References

• PHP security advisory and release announcements (php.net)
• PHP2Shell frequently asked questions (Tenable)
• Critical unauthenticated remote code execution in PHP (Rapid7)
• PHP2Shell: PHP patches two critical RCE vulnerabilities (Qualys)
• Responding to core PHP vulnerabilities (Google Cloud)