October 21, 2026
Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, leaked before their fix was ready. Known as PHP2Shell, both let an unauthenticated attacker run code on a server that runs PHP. Researchers expect mass exploitation soon after the patch lands. Here is what you need to know, and how to check your servers.
In short
- What: two remote code execution bugs in the PHP core, each rated CVSS v4.0 9.2 by PHP.
- How: exploits reportedly use
multipart/form-datarequests, which PHP parses before your application code runs. A login page in your application doesn't stop them. - Who: any server where PHP handles web requests: php-fpm, Apache with mod_php, php-cgi, LiteSpeed. Reports say every release since PHP 5.4 is affected.
- Fix: PHP's security release is due October 21, 14:00 UTC. The fixed versions are expected to be 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
- No fix for old branches: PHP 8.1 and older are end of life. Only your Linux distribution can backport a fix to them.
What happened
On October 20, details of two critical bugs in the PHP core surfaced online ahead of a coordinated disclosure. PHP confirmed them the same day and scheduled an emergency security release. Security firms including watchTowr and Sansec confirmed that they allow remote code execution. Technical details are not public yet, but the patch will reveal them, so expect working exploits soon after the release.
What to do now
- Update PHP as soon as your distribution or PHP repository ships the fix, then restart php-fpm or Apache. A running process keeps using the old code until it restarts.
- Check distro builds by changelog, not version number. Debian, Ubuntu and RHEL backport fixes without changing the upstream version, so a patched Ubuntu 24.04 would still report PHP 8.3.6.
- Rebuild container images. Restarting a container won't update the PHP inside it.
- If you can't patch yet, block
multipart/form-datarequests to PHP at nginx, Apache or your WAF, or take PHP offline. Blocking breaks file uploads. Settingsession.upload_progress.enabled = 0reportedly stops only one of the two bugs, so don't rely on it.
How to check a server by hand
Is PHP serving web requests?
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd'
Apache only counts when mod_php is installed.
Which PHP packages are installed?
dpkg -l 'php*' # Debian, Ubuntu
rpm -qa 'php*' # RHEL, Rocky, AlmaLinux
apk list --installed 'php*' # Alpine
Does the distro changelog list the fix?
zgrep -h 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'
A server is vulnerable when its PHP version is below the fixed release and the changelog doesn't list the CVEs. Repeat this on every server, after every update, and remember the containers.
Automate it with Netpicker CVEasy
Checking a fleet by hand is slow and easy to get wrong. Netpicker's CVEasy rule library now includes rules for CVE-2026-109618 and CVE-2026-109619 on Linux. Netpicker runs them against the servers in your inventory and shows you which ones are vulnerable.
For each server, the rules:
- Find PHP serving web requests: php-fpm, php-cgi, LiteSpeed, FrankenPHP, Apache with mod_php, or PHP's built-in server.
- Match each process to its package with dpkg, rpm or apk, so an unused PHP CLI next to a patched php-fpm doesn't raise a false alarm.
- Read the distro changelog to recognize backported fixes on Debian, Ubuntu and RHEL.
- Flag PHP that no installed package provides, such as a custom build, for a manual check.
The rules use read-only commands and don't need root.
Scan your servers automatically
Don't wait for an attacker to find your unpatched PHP. Get Netpicker with CVEasy and let it scan your servers for PHP2Shell automatically.
Sources: PHP security release announcement · Sansec: PHP2Shell · watchTowr FAQ · SecurityWeek
