First, to be clear
Temporary measures narrow the attack surface but do not close the vulnerability. They are suitable for buying a few hours until a maintenance window, not as a solution. If the server faces the internet, plan the update for the same day.
Measure 1. Disable upload progress tracking
This is the first thing the official advisories recommend: this mechanism opens one of the attack paths.
session.upload_progress.enabled = 0Add the line to php.ini and restart PHP-FPM. To check that it was applied:
php -i | grep upload_progress.enabledWhat you lose: the file upload progress indicator in some older CMSes. Modern interfaces calculate progress in the browser and are not affected.
Measure 2. Limit the request body size
The attack requires sending a large amount of data to the server. Reduce the allowed size in PHP and in the web server.
post_max_size = 8M
upload_max_filesize = 8MIn nginx:
client_max_body_size 8m;Choose a value that fits your workload: if users upload video, 8 MB will break uploads. Set the minimum your site needs.
Measure 3. Perimeter rules
If Cloudflare or another filtering service sits in front of the site, enable your provider's rules for these vulnerabilities. They appeared in the first days after publication. This helps against mass scanning but not against a targeted attack.
Measure 4. Reduce the damage of a compromise
While the vulnerability is open, reduce what an attacker gets if they succeed:
- Disable dangerous functions if you do not need them:
disable_functions = exec,passthru,shell_exec,system,proc_open,popen. - Deny write access to code directories. Executing someone else's code is not the same as being able to save it.
- Check that database passwords and API keys are not stored in files reachable from the web root.
What not to do
Do not rely on an administrator password, two-factor authentication, or IP restrictions inside the application: the attack triggers before the application code gains control. Hiding the PHP version in headers does not help either, because scanners probe the behavior of the server, not the header.
Frequently asked questions
How long do these PHP2Shell mitigations protect me?
Only as long as it takes to schedule a maintenance window. They do not make the server safe.
Can I just take the website offline until I can update PHP?
If the site is not critical, stopping PHP-FPM is the most reliable temporary measure. Static files continue to be served.
How do I tell whether my server has already been attacked?
Look in the logs for unusual large POST requests and for requests that ended with a 500 status in unexpected places. Details are in our article on signs of compromise after the vulnerability.