Is your PHP vulnerable to PHP2Shell?
Paste your PHP version and get an answer in ten seconds. The check runs in your browser. Nothing you type is sent anywhere.
Check the PHP your website runs, not just the one on the command line.
They're often different. A server can show 8.3.36 in a terminal while the website still runs an older PHP-FPM.
On the server
php-fpm -v # or php-fpm8.3 -v php -v # command line only
The PHP-FPM binary is the one serving web requests on most nginx and modern Apache setups.
In a control panel
cPanel shows it under MultiPHP Manager or Select PHP Version. Plesk shows it in each domain's PHP Settings. Managed hosts usually list it on the site's dashboard.
From outside
curl -sI https://your-site.example \ | grep -i x-powered-by
This only works if your server advertises its PHP version, and many don't. No header doesn't mean you're safe.
-1ubuntu or +deb, check your distribution's security notice for CVE-2026-109618 and CVE-2026-109619.
Updating isn't enough. Restart everything.
PHP workers that started before the update keep running the old, vulnerable code until they restart.
sudo systemctl restart php8.3-fpm # PHP-FPM, use your version sudo systemctl restart apache2 # Apache with mod_php: full restart sudo systemctl restart lsws # LiteSpeed
Apache with mod_php needs a full restart. A graceful reload keeps the old PHP library loaded. To list processes still running a PHP binary that was replaced on disk:
sudo grep -lsE 'php[^ ]* \(deleted\)' /proc/[0-9]*/maps
# any output = a process still runs the old, vulnerable PHP
If you can't update today, CISA advises taking PHP 8.1 and older offline until it's fixed. A web application firewall and Rapid7's interim mitigations reduce exposure, but they aren't a fix.
A version number is a start. A Scan is the whole answer.
For $99 a server we find every PHP runtime on it, judge each one against the vendor's real fixed build, check the running workers, and sweep for signs of compromise. Credited in full toward a $249 Patch.