Is your server open to php2shell? Check and fix it free.

1Is this server patched? Run on the server

Prints the PHP version and the verdict. Uses the same fixed versions as this page.

php -r '$f=["8.2"=>"8.2.35","8.3"=>"8.3.36","8.4"=>"8.4.27","8.5"=>"8.5.12"];$b=PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;$v=PHP_VERSION;echo "PHP $v: ",isset($f[$b])?(version_compare($v,$f[$b],">=")?"PATCHED":"VULNERABLE, update to ".$f[$b]):(version_compare($v,"8.6",">=")?"newer than affected branches":"NO UPSTREAM FIX, upgrade to 8.2.35+ or check your distro"),PHP_EOL;'

2Check every PHP on the box, not just the command line

PHP-FPM and php-cgi can be a different version from `php`. Also lists Apache's PHP module and PHP inside running containers.

for b in $(ls /usr/bin/php* /usr/sbin/php-fpm* /usr/local/bin/php* /usr/local/sbin/php-fpm* /opt/*/root/usr/sbin/php-fpm 2>/dev/null | grep -E '(php|php-fpm|php-cgi)[0-9.]*$'); do echo "$b: $($b -v 2>/dev/null | head -1)"; done
apache2ctl -M 2>/dev/null | grep -i php; httpd -M 2>/dev/null | grep -i php
docker ps --format '{{.Names}}' 2>/dev/null | while read c; do echo "$c: $(docker exec "$c" php -v 2>/dev/null | head -1)"; done

3On Debian, Ubuntu, RHEL, Alma or Rocky packages: look for the CVE in the changelog

Distributions backport fixes without changing the version number, so the number alone can mislead. If the CVE is listed, that package is fixed.

apt changelog "$(dpkg -S "$(readlink -f "$(command -v php)")" | cut -d: -f1)" 2>/dev/null | grep -m2 -E 'CVE-2026-10961[89]'
rpm -q --changelog php-common 2>/dev/null | grep -m2 -E 'CVE-2026-10961[89]'

If you cannot patch today, take the site offline or behind a firewall

This is CISA's advice, and the only stopgap that removes the risk. Everything else on this list reduces it; none of it is a fix.

Turn off session upload progress

Set it in php.ini or the PHP-FPM pool, then restart all workers. ini_set() and .user.ini are too late.

session.upload_progress.enabled = 0

On PHP 8.5, turn off fatal error backtraces

fatal_error_backtraces = 0

Cap request bodies

If the site takes no uploads, 8M; otherwise 32M with upload_max_filesize below it. Block multipart requests at the web server or WAF if your app does not use them.

post_max_size = 8M

Put a WAF in front (Cloudflare, AWS WAF, Cloud Armor and others)

Reject request bodies larger than the WAF can inspect: these attacks use large payloads to exhaust memory.

Do not rely on container memory limits, RLIMIT_AS or RLIMIT_DATA

They do not block the attack and can trigger the vulnerable path.

PHP or web server workers that started a shell or a download tool

This is the sign CISA asks you to watch for.

ps -eo pid,ppid,user,etime,cmd --forest | grep -A3 -E 'php-fpm|php-cgi|apache2|httpd|lsphp|frankenphp' | grep -E '\b(sh|bash|dash|curl|wget|nc|ncat|python3?|perl)\b'

PHP files created or changed since the bug leaked

sudo find /var/www /home/*/public_html -name '*.php' -newermt '2026-10-19' -ls 2>/dev/null

Executables dropped in temp folders

sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null

Unexpected outbound connections from the web user

sudo ss -tnp | grep -E 'php|apache2|httpd|lsphp'

Clean logs do not prove you are safe

If anything above looks wrong, do not wipe the server: take a snapshot first, then talk to an incident responder. Under the CERT-In directions of 28 April 2022, reportable incidents, including unauthorised access to IT systems and attacks on servers, must be reported to CERT-In within 6 hours of noticing them.