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, rate-limit them and block the rest. This reduces exposure; it doesn't remove the bug.

   nginx

   No uploads at all? One line in server {}:

   nginx

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

   Need uploads? Allow-list the real endpoints and rate-limit them. The check sits in server {} so it also covers direct *.php requests:

   nginx

   # http {} context
   limit_req_zone $binary_remote_addr zone=p2s_upload:10m rate=3r/m;
   map $content_type $p2s_multipart { default 0; ~*^multipart/form-data 1; }
   map $uri $p2s_upload_ok {
       default                      0;
       /wp-admin/async-upload.php   1;   # your real upload endpoint(s), exact paths
   }
   map "$p2s_multipart$p2s_upload_ok" $p2s_block { default 0; 10 1; }
   
   # server {} context: runs before any location block
   if ($p2s_block) { return 403; }
   
   location = /wp-admin/async-upload.php {         # one per allow-listed endpoint
       limit_req zone=p2s_upload burst=3 nodelay;
       client_max_body_size 32m;
       include snippets/fastcgi-php.conf;           # your usual PHP handler
       fastcgi_pass unix:/run/php/php8.3-fpm.sock;
   }

   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 (custom rule)

   Security → WAF → Custom rules, action Block (or Managed Challenge). Edit the allow-listed paths. This only helps if your origin isn't reachable directly, so restrict it to Cloudflare's IP ranges.

   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"}

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.