On this page
CISA added both PHP2Shell bugs, CVE-2026-109618 and CVE-2026-109619 in PHP, to its Known Exploited Vulnerabilities catalog on October 26. Catalog version 2026.10.26 went out at 6:24 PM ET with a due date of October 29 and, for the first time on this story, a forensic triage requirement. US federal civilian agencies now have three days to fix every affected server and to check whether each one was already broken into. Everyone else running PHP web servers should take the same order seriously: save evidence, upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart, then look back for a break-in.
This is a follow-up to our original PHP2Shell write-up, which covers how the two bugs work, which SAPIs are exposed and the config mitigations. Here we cover what the KEV listing changes and what the exploitation evidence looks like five days after the patch. The HOL Guard evidence pack for CVE-2026-109618 holds the source record.
What CISA listed
| CVE | KEV name | Added | Due | Forensic triage | Ransomware use |
|---|---|---|---|---|---|
| CVE-2026-109618 | PHP Memory Corruption Vulnerability (out-of-memory corruption, GHSA-w8hw-w9fx-j79w) | 2026-10-26 | 2026-10-29 | Yes | Unknown |
| CVE-2026-109619 | PHP Stale Internal Request-State Vulnerability (GHSA-6wmf-4rv5-p3rp) | 2026-10-26 | 2026-10-29 | Yes | Unknown |
Under BOD 26-04, "forensic triage: Yes" means an agency has to finish remediation within three days and also assess whether each asset was compromised. CISA updated its October 21 PHP alert the same day. Its advice has not softened: if you cannot update, or you still run PHP 8.1 or older, take the PHP systems offline until they are patched. CISA also says PHP often ships inside other products, so an inventory of "servers where we installed PHP" will miss some.
How to fix
Upgrade PHP to a fixed release, then restart every process that runs it:
# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart apache2 'php*-fpm'
# RHEL / Alma / Rocky / Fedora
sudo dnf upgrade 'php*' && sudo systemctl restart httpd php-fpm
# Containers: rebuild on the new base tag and redeploy
docker build --pull -t my-app .
The order matters on any host that served traffic on an unpatched build after October 17, the earliest attempt Amazon has reported (per SecurityHQ). CISA's triage guidance says to collect volatile evidence before patching, because patching can wipe it. On a PHP box that is literal. The restart kills the Apache or FPM worker that ran an attacker's shell along with its child processes, and a reboot can empty /tmp, where the Mirai payload seen in these attacks lands. Collect first; it takes about two minutes:
mkdir -p /root/p2s-triage && cd /root/p2s-triage
ps -eo user,pid,ppid,lstart,cmd --forest > ps-forest.txt
ss -tnp > sockets.txt
ls -la --time-style=full-iso /tmp /var/tmp /dev/shm > tmp-listing.txt
cp -a /var/log/apache2 /var/log/httpd /var/log/nginx /var/log/php* . 2>/dev/null
php -v > php-version.txt
Then patch, restart, and confirm that the web server itself (not just the CLI) reports the fixed version. The original post has the PHP_VERSION and lsof checks for workers still running the old binary.
What changed since the patch
Until this weekend the public evidence was millions of attempts and no confirmed code execution. That changed on October 24. Perplexity researcher Adel Karimi recorded 35 shells started by Apache workers on three honeypots running PHP 8.4.26 under mod_php, from two IP addresses, using a four-stage request chain that exhausted memory, leaked it, then ran a command (SecurityWeek, BleepingComputer). Karimi ties it to CVE-2026-109618 and says his single-worker setup was deliberately favorable to the attacker, so it does not measure reliability on busier pools. The follow-up commands were id, curl, wget and php -r fetches to 162.35.99[.]94; no second stage was downloaded.
- Botnets are trying. Sophos saw failed attempts to install Potassium, a Mirai-derived DDoS bot, written to
/tmp/nfsand run as./nfs php(The Hacker News). SecurityHQ's analysis traces that download to 92.118.112[.]100. - A slow, targeted scan. CYFIRMA reports Korean-speaking operators, linked with moderate confidence to the Lazarus ecosystem, working through a list of 216 unpatched or partly mitigated hosts from 21 rotating nodes. The scans are paced to stay under rate-limit alerts (The Hacker News).
- Appliances are on the list. Defused Cyber saw upload-progress probes carrying the marker
p2s-rideragainst its Palo Alto GlobalProtect honeypots from 204.76.203[.]7 (same THN report). That fits CISA's warning that PHP hides inside other products. - Traffic is still climbing. The Delft Threat Intelligence Lab's live tracker counted 58,951 exploitation requests from 627 IPs by 23:25 UTC on October 26. Its busiest hour so far was 14:00 UTC today, with 8,179 requests.
Correction to our October 25 update. We reported Unit 42's account of a European government agency breached through PHP2Shell, with an AI agent running the follow-up. On October 25 Unit 42 retracted that update, saying it cannot tie the initial access to these CVEs. We have marked the original post.
Check whether your server was hit
Body contents usually are not in access logs, so you are hunting for the side effects. ReliaQuest reproduced CVE-2026-109618 in a lab and, as quoted by The Hacker News, describes the sequence to look for: a POST that returns 500, PHP reporting memory exhaustion and heap corruption, then the Apache worker crashing. Search from October 17 to the time each host restarted on a fixed build.
# memory exhaustion and heap corruption from PHP
grep -hE 'Allowed memory size|zend_mm_heap corrupted' /var/log/apache2/error.log* /var/log/php*fpm*.log* 2>/dev/null | head
# Apache children dying mid-request
grep -h 'Segmentation fault' /var/log/apache2/error.log* 2>/dev/null | head
# clients sending POSTs that end in 500 (combined log format)
awk '$6=="\"POST" && $9==500 {print $1}' /var/log/apache2/access.log* | sort | uniq -c | sort -rn | head
# payload and callback addresses named in public reporting
ls -la /tmp/nfs /var/tmp/nfs 2>/dev/null
grep -rlE '162\.35\.99\.94|92\.118\.112\.100|204\.76\.203\.7' /var/log 2>/dev/null
A hit on the first three is a lead, not proof: a big upload on a small memory_limit can produce the same lines. A shell or curl under www-data in your saved process list, or a file at /tmp/nfs, is a compromise, and the upgrade does not undo it. Rotate every secret the web user could read (database passwords, API keys in .env and environment variables) and look for new .php files in web roots. If you lack request or process logs for part of the window, record that window as unproven rather than clean.
Who is not in scope
- PHP that never answers HTTP requests. Cron jobs, queue workers and CLI scripts are outside the request paths in both advisories. The KEV listing does not change that.
- Hosts that never served traffic on an unpatched build, such as new servers built on 8.5.12, 8.4.27, 8.3.36 or 8.2.35. They need the upgrade check, not the look-back.
- The October 29 date binds US federal civilian agencies only. For everyone else it is CISA saying it has seen enough evidence of real attacks, which is a reason to move faster, not a compliance deadline.
What this is not
The KEV listing is not a public victim report. CISA does not publish the evidence behind an entry, lists ransomware use as unknown, and the strongest public proof of code execution is still on research honeypots; Sophos also withdrew an early claim of a successful compromise. It does mean attackers have working chains and are aiming them at real hosts, so "no one has been confirmed breached" is no longer a reason to wait.
References
- CISA Known Exploited Vulnerabilities catalog (2026.10.26)
- CISA alert: Critical Vulnerabilities in PHP Require Immediate Patching (revised Oct 26)
- CISA BOD 26-04 and forensic triage guidance
- PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618, RCE via OOM corruption)
- PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619, RCE via stale global state)
- php.net: Security advisory: Critical remote code execution vulnerabilities, update now
- SecurityWeek: PHP2Shell Exploitation Moves From Probes to Working Shells
- The Hacker News: PHP2Shell Exploitation Attempts Continue Amid Suspected N. Korea Global Scanning Activity
- The Hacker News: PHP2Shell Exploit Attempts Hit Millions as Attackers Try to Deploy Mirai Malware
- Unit 42 threat brief (updated Oct 25, retraction)
- Delft Threat Intelligence Lab: PHP2Shell in the wild




