How to Patch PHP2Shell: The Technical Walkthrough (With and Without an AI Engineer)

PHP2Shell is a CVSS 9.2 remote code execution vulnerability in PHP's file upload handling. It dropped this morning. Automated scanners are already sweeping for targets. This post gives you the exact commands to patch it, organized by operating system, plus an explanation of what Daniel does when he handles the same task autonomously.

If you want to skip straight to autonomous patching, go to the PHP Security Fix portal. If you want to understand the commands and do it yourself, keep reading.

Step 0: Immediate stopgap (do this first)

Before upgrading PHP, apply the configuration stopgap. This disables the exploit vector immediately without requiring a PHP restart in most configurations.

# Find your php.ini file
php --ini | grep "Loaded Configuration"

# Add or update this line in php.ini
echo "upload_progress.enabled = Off" >> /etc/php/8.3/fpm/php.ini

# OR use sed to update if the line exists
sed -i 's/upload_progress.enabled = On/upload_progress.enabled = Off/g' /etc/php/8.3/fpm/php.ini

# Verify the change
php -i | grep upload_progress.enabled
upload_progress.enabled => Off => Off

Step 1: Check your current PHP version

php --version
PHP 8.3.35 (cli) (built: Oct 15 2026)
Copyright (c) The PHP Group
Zend Engine v4.3.35

# PHP 8.3.35 is vulnerable. Target: 8.3.36

Step 2: Upgrade PHP

# Update package lists
sudo apt-get update

# Upgrade PHP (replace 8.3 with your branch)
sudo apt-get install --only-upgrade php8.3 php8.3-fpm php8.3-cli php8.3-common

# If you're using ondrej/php PPA (most common for recent PHP versions)
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install --only-upgrade php8.3-fpm

# Update PHP from Remi or IUS repository
sudo dnf update php php-fpm

# Or with yum
sudo yum update php php-fpm

# Verify Remi repo is enabled if package isn't found
sudo dnf install -y dnf-utils
sudo yum-config-manager --enable remi-php83

# Amazon Linux uses amazon-linux-extras or dnf
sudo dnf update php php-fpm

# Or via amazon-linux-extras
sudo amazon-linux-extras install php8.3
sudo yum update php

# Pull updated base image
docker pull php:8.3.36-fpm-alpine
docker pull php:8.3.36-apache

# Rebuild your application image
docker build --no-cache -t myapp:patched .

# Rolling restart (if using Docker Compose)
docker compose up -d --force-recreate

Step 3: Restart the PHP process

# PHP-FPM (most common for nginx setups)
sudo systemctl restart php8.3-fpm

# Apache with mod_php
sudo systemctl restart apache2
# or
sudo systemctl restart httpd

# Nginx (doesn't run PHP directly, but restart for good measure)
sudo systemctl restart nginx

Step 4: Verify the patched version is live

php --version
PHP 8.3.36 (cli) (built: Oct 21 2026)
Copyright (c) The PHP Group
Zend Engine v4.3.36

# Confirm upload_progress is disabled
php -i | grep upload_progress
upload_progress.enabled => Off => Off
upload_progress.freq => 1%
upload_progress.min_freq => 1

# ✓ Patched. upload_progress.enabled = Off confirmed.

What about PHP 8.1 and older?

There is no upstream patch for PHP 8.1 or any older branch. The PHP project has ended security support for these versions. If you're running PHP 8.1, the fix is a branch upgrade to 8.2, 8.3, or 8.4 — then apply the version-appropriate patch.

Branch upgrades are more involved than a package update. They require testing, because PHP 8.2 introduced some deprecations that became errors in 8.3. If you're running a large application on PHP 8.1, this is a conversation to have with your team. The stopgap (upload_progress.enabled = Off) buys you time. It doesn't replace the upgrade.

What Daniel does — the same steps, autonomously

When Daniel patches a server for PHP2Shell, he runs essentially the same sequence you just read — but he does it autonomously, with full logging, after you approve the plan.

He connects to the server over SSH. He reads php --version and php -i | grep upload_progress. He determines whether the server is vulnerable and which branch it's running. He constructs the exact upgrade command for that server's OS and package manager. He shows you the plan. You approve. He runs it, captures every line of output, verifies the patched version is live, and writes a receipt.

The difference between doing this yourself and doing it with Daniel isn't the commands — it's the number of servers you can cover in an hour. One engineer can patch maybe four or five servers in an hour, with interruptions. Daniel can handle a queue of servers sequentially with no interruptions, producing a receipt for each one, while your engineer focuses on the servers that need judgment calls.

The portal is at cognitivedaniel.com/php-security-fix. The simulation will walk you through exactly how it works before you connect a real server.