PHP2Shell Check

How to close the hole without breaking anything

The flaw is in the PHP interpreter itself, so updating the CMS, plugins or site code does not help. Steps:

1. Take a backup and size up the update

   An update within your branch (for example 8.3.30 → 8.3.36) is a bug-fix release with no language changes: install it right away after backing up site files and the database. Moving to another branch (8.1 to 8.3 or later) can break old code — try the site on a test copy first.

2. Update PHP

   Pick the way that matches how PHP is installed and replace 8.3 with your branch. The --only-upgrade flag updates installed packages only and adds nothing. If the distribution repository does not have the fixed version yet, check the package changelog (the fix may be backported under the old number) or take PHP from the ondrej/sury repository.

   # Debian / Ubuntu: which PHP packages have updates
   sudo apt update
   apt list --upgradable 2>/dev/null | grep php
   # add your own: libapache2-mod-php8.3, php8.3-mysql and other modules
   sudo apt install --only-upgrade php8.3-common php8.3-cli php8.3-fpm
   
   # RHEL / AlmaLinux / Rocky Linux: which PHP packages have updates
   dnf check-update 'php*'
   sudo dnf upgrade php-common php-cli php-fpm
   
   # Docker: pull for ready-made images (image:), build --pull for your own Dockerfiles; replace a pinned tag such as php:8.3.30-fpm with a fixed one
   docker compose pull
   docker compose build --pull
   docker compose up -d

   Shared hosting or a control panel (ISPmanager, cPanel, Plesk): pick the fixed PHP version in the site settings. If it is not listed, contact support — on such plans the host updates PHP.

3. Restart PHP

   While old processes run, the vulnerable code stays in memory. Test the configuration first — the commands below will not restart a service with a broken config. A restart takes seconds, but requests during it may fail — do it at a quiet hour. Restart other long-running PHP processes too: queue workers, supervisor daemons, RoadRunner or Swoole. In Docker the containers are already new after up -d.

   # nginx or Apache + PHP-FPM: restarting PHP-FPM is enough (the service is php-fpm on RHEL)
   sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm
   # Apache with mod_php: restart Apache (httpd on RHEL)
   sudo apachectl configtest && sudo systemctl restart apache2

4. Check the result

   On the server, check the binary that actually serves the site (php-fpm8.3 -v, not just php -v) or the package changelog (commands above). From outside, run this check again.

5. If the site was vulnerable, look for signs of a break-in

   According to Help Net Security, Amazon MadPot honeypots saw exploitation attempts from 17 October 2026. Look for new or changed PHP files in the site directory that you did not deploy. The command only lists files and changes nothing. An empty result does not prove there was no break-in: file modification times can be forged.

   # use your site directory
   find /var/www \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -newermt '2026-10-17' -ls

   Found unfamiliar files? Do not delete them right away: keep copies and the web server logs, change server passwords and access keys, and bring in an incident response specialist.

If you cannot update today

Turn on WAF rules for PHP2Shell if your provider has them, and schedule the update within days. A WAF lowers the risk from known attack patterns but does not close the flaw. Hiding the version from headers (expose_php = Off) is useful, but it is not protection either.