The day almost the whole Internet got cooked!
CVE-2026-109618 and CVE-2026-109619 - The October 2026 PHP RCE bugs
On 21 October 2026 the PHP project disclosed two critical remote-code-execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can let an unauthenticated visitor run code on your server, and they affect essentially any PHP that serves web requests — PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and others.
Bottom line: update PHP to a patched release and restart it. This post is a safe way to check whether a server you own or administer is affected, confirm the fix, and look for signs it was already misused — using tools you already have, with no exploit code and no third-party scripts.
Run every step only against your own servers. Pointing a scanner or exploit at a server you don't control is unauthorised access, and the attempt itself can crash the target — so it's both illegal and harmful, whatever the intent.
What's affected
| Branch | First patched release |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
| 8.1 and older | End of life — no fix; upgrade to a supported branch |
A build on the right branch but an older point release (say 8.3.30) is still vulnerable. Enterprise distributions — RHEL, AlmaLinux, Rocky, Debian, Ubuntu — backport the fix while keeping the old-looking version number, so on those, trust your package manager's security status rather than the version string alone.
Step 1 — Read your actual PHP version
This is the real test. A scanner only guesses the version by poking the server; reading it off the running binary is exact.
php -v
If your sites run under PHP-FPM, each pool uses its own binary — check the one your site actually uses, for example:
/usr/sbin/php-fpm8.3 -v
Compare what you see against the table above, and don't overlook any separate PHP that a control panel or admin tool runs.
Step 2 — Update, then re-check
Your OS vendor shipped the fix, so install it from your package manager rather than building from source or using a third-party repo:
# Debian / Ubuntu
apt update && apt upgrade
# RHEL / AlmaLinux / Rocky / Fedora
dnf update
Then restart your web server and PHP service so the new build is actually in use, for example:
systemctl restart php8.3-fpm
systemctl restart nginx # or: systemctl restart apache2
Run the Step 1 command again to confirm the version moved.
Two cautions:
- Never bypass a failed signature check (no
--nogpgcheck, and don't install a package flagged "not signed"). An unsigned package can't be trusted to be the real fix. - If PHP workers keep running the old build after an update, they're still vulnerable — make sure the service actually restarted.
Step 3 — Confirm the server shrugs off bad input (optional)
This is reassurance, not a vulnerability test. It sends one large, deeply nested form body — the kind of malformed input these bugs rely on — to your own site, and checks the server handles it and stays up. It contains no exploit.
python3 -c "print('&'.join('a%d[b][c][d][e]=%d' % (i,i) for i in range(2000)))" > /tmp/php_probe.txt
curl -sk -o /dev/null -w 'HTTP %{http_code}\n' --data @/tmp/php_probe.txt https://YOUR-SITE/
rm -f /tmp/php_probe.txt
Replace YOUR-SITE with your own domain. A patched server answers normally (usually a 200) and keeps running. Afterwards, check that the web server and PHP are still alive — on a patched build they will be.
Step 4 — Check nothing already got in
Request bodies aren't logged, so no log proves an attack. What you can look for are the traces a successful one leaves: it runs as the web user and tends to drop files or processes behind it. These commands only read; adjust the paths and the cutoff date (here, the 21 Oct disclosure) to your setup.
# PHP files created or changed since the disclosure, under your web roots
find /var/www -type f -name '*.php' -newermt '2026-10-21 19:00' -ls 2>/dev/null
# Files dropped in temporary folders since then
find /tmp /var/tmp /dev/shm -type f -newermt '2026-10-21 19:00' -ls 2>/dev/null | head -30
# Programs running as the web user that aren't PHP itself
ps -eo user:20,pid,etime,args | grep -E 'www-data|apache|nobody' | grep -vE 'php-fpm|php-cgi'
# Per-user cron jobs
ls -la /var/spool/cron*/ 2>/dev/null
# PHP out-of-memory errors and worker crashes around the disclosure
zgrep -hiE 'Allowed memory size|killed by signal|segfault' /var/log/php* /var/log/nginx/*error* /var/log/apache2/*error* 2>/dev/null | tail -40
Some hits are normal: template engines regenerate cached PHP, and a large upload can log the odd memory error. What matters is a PHP file or a running program you didn't put there, especially dated on or after 21 Oct. If you find something you can't explain, treat the server as potentially compromised.
Things not to do
- Don't run exploit repos against a live server. The GitHub "scanners" that confirm the bug by running
whoamiare attack tools; run as root on your own box, they can crash sites or carry their own backdoor. Reading the version (Step 1) already tells you whether you're patched — more reliably than an exploit can. If you want to experiment, use a throwaway VM, never the machine that hosts your sites. - Don't scan or exploit a server you don't own, even to "confirm" it's vulnerable. That's unauthorised access under laws like the CFAA (US), the Computer Misuse Act (UK) and the IT Act (India), and the attempt can take the target down. If you think a service you use is exposed, report it to them and let them check their own systems.
If you find signs of a break-in
Take the site offline or isolate it. Preserve the logs and a copy of the suspicious files before deleting anything. Rebuild or restore from a known-good backup taken before 21 Oct rather than cleaning in place — a dropped web shell is easy to miss. Rotate any credentials the site could reach (database, API keys, mail). And get a second pair of eyes if you're unsure.
Reference: PHP security advisory, 21 October 2026.
