Security Advisory: PHP2Shell (CVE-2026-109618 and CVE-2026-109619), Critical Remote Code Execution in PHP

/ Press Releases

Status: Active. Exploitation has been reported. Patch now. Last updated October 31, 2026.

Summary

Two critical remote code execution flaws in PHP, together nicknamed PHP2Shell, were disclosed on October 21, 2026. An attacker does not need a login. A successful attack can give them control of the web server running PHP. That includes WordPress sites and any other PHP application, such as Invoice Ninja, Laravel, Drupal, Joomla or Magento. Security researchers have reported attacks in the wild, so treat any unpatched, internet-facing PHP server as at risk.

Vulnerability details

  • CVE IDs: CVE-2026-109618 and CVE-2026-109619
  • Severity: Critical. CVSS v4.0 score of 9.2 as reported by researchers.
  • Type: Remote code execution, no authentication required
  • CVE-2026-109618: If PHP runs out of memory part way through setting up a request, its cleanup code can act on half-built internal data. This can be turned into code execution. The reported attack path uses multipart file uploads.
  • CVE-2026-109619: Internal data from one request can outlive the memory it points to. The next request handled by the same PHP worker can then act on that stale data. Reported paths involve PHP sessions and upload progress tracking.
  • Affected software: PHP builds older than 8.2.35, 8.3.36, 8.4.27 or 8.5.12. PHP 8.1 and older have no official fixed release. Apache mod_php is considered the highest risk, but PHP-FPM, CGI, LiteSpeed and FrankenPHP are also in scope.
  • Exploited in the wild: Yes, reported. Researchers observed scanning and at least one exploitation attempt starting October 21, 2026. Public proof-of-concept code exists, though much of it is unreliable.
  • Fixed in: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or a distribution package that includes the fix

Important: an attack can leak server memory and leave no files behind. A clean file scan does not prove a server was not exposed.

Who is affected

Any server or hosting plan that runs PHP and answers web requests, including shared hosting, virtual servers, containers and all-in-one stacks. All-in-one stacks such as Bitnami images, cPanel and Docker application images bundle their own PHP. Updating the operating system alone may not update the PHP they use.

What ASI recommends

Work through these steps in order. Commands are examples for a Debian or Ubuntu web server. Adjust the PHP version number, paths and service names for your system, and test on a non-production copy first where you can.

1. Find your PHP version and where it comes from

Web PHP and command line PHP can be different versions, so check what the web server uses. Containers and all-in-one stacks (Bitnami, cPanel, Docker images) bundle their own PHP.

php -v                              # command line PHP
apachectl -M 2>/dev/null | grep -i php   # Apache loading mod_php?
php-fpm -v                          # PHP-FPM, if used
docker exec <container> php -v      # PHP inside a container

2. Update PHP to a fixed release

Use 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a distribution package that includes the fix. Distributions sometimes backport fixes without changing the version number, so check the package changelog for the CVE IDs.

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade "php8.2*"
apt changelog php8.2-common | grep -i -E "109618|109619"

# RHEL / Rocky / Alma
sudo dnf upgrade "php*"
rpm -q --changelog php | grep -i -E "109618|109619"

# Docker (use a patched image tag)
docker compose pull && docker compose up -d

If your stack has no in-place PHP update, move to a current vendor image or a new server built from the current image, migrate the site and database, and verify the version before switching traffic.

3. Restart every PHP worker

Old workers keep running vulnerable code until they are restarted.

sudo systemctl restart apache2          # Apache with mod_php
sudo systemctl restart php8.2-fpm       # PHP-FPM
docker compose up -d --force-recreate   # containers

4. If you cannot patch today, apply interim mitigations

Put these in the main PHP configuration (php.ini or the FPM pool), then restart workers. ini_set() and .user.ini are not enough. Also keep request and upload size limits low at the web server or proxy, and restrict public access to the server if you can. These steps are partial. PHP states that no configuration change fully fixes these flaws.

; php.ini
session.upload_progress.enabled = 0
fatal_error_backtraces = 0     ; PHP 8.5 only

5. Rotate secrets

Memory can leak without leaving files behind, so change database passwords, application salts and keys, administrator and service passwords, mail and API credentials, and reissue TLS private keys. For WordPress, the salts can be regenerated from the command line. Change the database password in the database and in wp-config.php together.

sudo -u www-data wp config shuffle-salts --path=/var/www/html

6. Check for signs of compromise

Review the period since October 21, 2026, and longer if the server was exposed earlier. Attackers change addresses and agent names quickly, so a clean result is not proof of safety.

Web logs: scanner names and addresses researchers linked to PHP2Shell activity.

zgrep -i -E "php2shell" /var/log/apache2/access.log*
zgrep -E "85\.11\.167\.243|45\.198\.224\.169|109\.71\.252\.97|221\.14\.159\.134|91\.90\.123\.25" /var/log/apache2/access.log*

Files: unexpected PHP files, especially in upload and temporary folders, and anything changed since disclosure that you did not change.

find /var/www -name '*.php' -newermt 2026-10-21 -type f
find /var/www -path '*/uploads/*' -name '*.php'
find /tmp /var/lib/php/sessions -name 'sess_xqsuvwz3n97wu8j3emz1axuo5y'

WordPress integrity: compare core and plugin files with the official copies.

sudo -u www-data wp core verify-checksums --path=/var/www/html
sudo -u www-data wp plugin verify-checksums --all --path=/var/www/html

Also review new user accounts, scheduled jobs, authorized SSH keys and unexpected outbound connections from the web server.

7. Add a protective layer

A web application firewall and rate limiting reduce scanning noise and some exploit attempts, but they do not replace patching.

How ASI can help

ASI can confirm which of your systems run affected PHP, patch or rebuild them, check for signs of compromise, and rotate credentials afterward. Contact us at info@asiweb.org or request a free consultation.

References

Last updated: October 31, 2026. Questions? Contact ASI.