php2shell: critical remote code execution in PHP

Do this now

Work from the top. Steps marked Unofficial come from researcher root-cause analysis that PHP hasn't confirmed. They're low-risk and reversible, but not a substitute for the patch. Everything else follows PHP and CERT guidance.

1. Find every PHP install, and the php.ini your web server loads

   Include PHP inside vendor appliances, control panels and containers. php --ini shows the CLI config; web requests use the FPM or Apache one, usually at a different path.

   shell

   php -v
   php-fpm8.3 -i | grep "Loaded Configuration File"  # Debian/Ubuntu, match your version
   php-fpm -i    | grep "Loaded Configuration File"  # RHEL / Alma / Rocky

   Where php.ini usually is

   Debian / Ubuntu, PHP-FPM	/etc/php/8.3/fpm/php.ini
   Debian / Ubuntu, mod_php	/etc/php/8.3/apache2/php.ini
   RHEL / Alma / Rocky / Amazon	/etc/php.ini
   Docker php:* images	Drop-in: /usr/local/etc/php/conf.d/zz-php2shell.ini
   cPanel / Plesk / shared hosting	MultiPHP INI Editor or PHP Settings, or .user.ini in the web root

2. Unofficial stopgap

   Turn off session.upload_progress, then reload PHP

   Researcher analysis puts one of the flaws in this handler. Almost no site needs it, and the change is reversible. Edit the web server's php.ini from step 1, not the CLI one.

   php.ini

   session.upload_progress.enabled = Off

   shell

   sudo systemctl reload php8.3-fpm    # Debian/Ubuntu FPM (match your version)
   sudo systemctl reload php-fpm       # RHEL family FPM
   sudo systemctl reload apache2       # mod_php (httpd on RHEL)
   php-fpm8.3 -i | grep upload_progress.enabled   # verify: should print Off

   Can't edit php.ini? Equivalent settings

   FPM pool (pool.d/www.conf)	php_admin_flag[session.upload_progress.enabled] = off
   Apache mod_php vhost	php_admin_flag session.upload_progress.enabled Off
   Shared hosting (FPM/CGI)	.user.ini in the web root; picked up within about 5 minutes

3. Unofficial stopgap

   Block multipart/form-data POSTs you don't need

   The second suspected path is the multipart parser itself, which runs on any multipart POST regardless of step 2. No uploads on the site? Block multipart entirely. Need uploads? Allow-list those paths and block the rest. This reduces exposure; it doesn't remove the bug.

   On Cloudflare? It added emergency WAF rules on 21 Oct that apply automatically on the Free plan; paid plans need the Cloudflare Managed Ruleset deployed. Cloudflare hasn't tied them to these CVEs. Details below.

   nginx

   Add this line to each server {} block that passes requests to PHP. It blocks every multipart POST, file uploads included, so use it only if the site doesn't need uploads.

   nginx

   if ($content_type ~* "^multipart/form-data") { return 403; }

   shell

   sudo nginx -t && sudo systemctl reload nginx

   Apache 2.4 (vhost or .htaccess)

   apache

   RewriteEngine On
   RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
   # Allow-list your real upload endpoint(s). Delete the next line to block all multipart.
   RewriteCond %{REQUEST_URI} !^/wp-admin/async-upload\.php$
   RewriteRule ^ - [F]
   
   # Optional: cap request bodies where uploads aren't expected (not on upload paths)
   # LimitRequestBody 1048576

   shell

   sudo apachectl configtest && sudo systemctl reload apache2   # httpd on RHEL

   Cloudflare WAF

   Managed rules. Cloudflare released emergency WAF rules on 21 Oct (references). On the Free plan they're in the Free Managed Ruleset, which is on by default unless someone turned it off; it inspects only the first 1 MB of a request body. On paid plans they're in the Cloudflare Managed Ruleset: check it's deployed under Security → WAF → Managed rules. Cloudflare hasn't said they target php2shell; its posts describe generic “anomalous execution” rules released the same day.

   Custom rule (extra layer). Security → WAF → Custom rules, action Block (or Managed Challenge). Edit the allow-listed paths.

   rule expression

   http.request.method eq "POST"
   and starts_with(lower(http.request.headers["content-type"][0]), "multipart/form-data")
   and not http.request.uri.path in {"/wp-admin/async-upload.php"}

   Both only protect traffic that goes through Cloudflare. Restrict your server to Cloudflare's IP ranges so attackers can't reach it directly.

4. Take end-of-life PHP off the internet

   PHP 8.1 and older, all 7.x and all 5.x get no fix. Firewall it, put it behind a VPN, or serve a maintenance page until it's upgraded to 8.2 or later.

5. Patch the moment fixed builds ship

   Due 21 Oct, 14:00 UTC for 8.2, 8.3, 8.4 and 8.5 (latest releases before the fix: 8.5.11, 8.4.26, 8.3.35, 8.2.34). PHP may ship earlier if exploitation spreads. Have the update staged: mass scanning is expected within minutes of release. On managed hosting, open a ticket now and ask them to stand by.

   Update commands

   Debian / Ubuntu	sudo apt update && sudo apt upgrade
   RHEL / Alma / Rocky	sudo dnf upgrade 'php*'
   Docker php:* images	Pull the new tag, rebuild, redeploy
   Windows	New build from windows.php.net

   Then reload PHP-FPM or Apache as in step 2. Distro packages often backport fixes without changing PHP's version number, so check your vendor's security tracker rather than comparing against php.net versions.

6. After patching, check for compromise

   Look for new web shells, unexpected cron jobs, services or users, and odd outbound connections. Detection lists the signals. Found something? Treat it as an incident.