PHP2Shell (CVE-2026-109618) is now confirmed exploited in the wild, and a third unpatched PHP flaw just surfaced. How MSPs check clients fast.
For a week, every security firm watching PHP2Shell said the same careful thing: lots of probing, no proven break-in. That line just expired. A researcher has now captured an attacker running actual commands on an internet-facing PHP server, start to finish, and a second expert called it the clearest confirmation he had seen.
If your clients run PHP, the "we'll get to the patch" window is closed. The flaw is real, it works, and a third, still-unpatched PHP bug surfaced the same week.
php CLI, per PHP's advisory.Start with evidence, then look for the one signal that proves a break-in rather than a knock on the door. This builds on our first PHP2Shell write-up, which covers the mechanics; here the job is finding out whether a client was actually compromised. Run these steps across your clients' PHP servers; for shared or managed hosting you cannot inspect, ask the host in writing to run the same checks.
Preserve evidence first. Copy the web and PHP logs and the config before you touch anything, then record hashes of anything suspicious so you can prove what you found.
D=/root/ir-$(date +%F); sudo mkdir -p "$D"
sudo cp -a /var/log/apache2 /var/log/nginx /etc/php /root/ir-* 2>/dev/null; sudo cp /var/log/php*-fpm.log "$D" 2>/dev/null
Look for a shell spawned by a web process — the decisive sign. A web worker (Apache, php-fpm, httpd) that launched sh, bash, curl or wget is the clearest proof of code execution; Datadog calls process ancestry the strongest evidence.
sudo ps -eo user,ppid,pid,comm,args | grep -E 'apache2|httpd|php-fpm|php-cgi' | grep -E ' (sh|bash|curl|wget|python)( |$)'
Scan error logs for the memory-exhaustion footprint. A short burst of "Allowed memory size … exhausted" errors located at "Unknown on line 0" means PHP failed during request setup, before any script ran, which is the behaviour Datadog documents for this bug.
sudo zgrep -hE 'Allowed memory size.*exhausted|Unknown on line 0|AH00052.*Segmentation fault' /var/log/php*.log /var/log/apache2/error.log* 2>/dev/null
Search access logs for the request pattern and the two confirmed attacker IPs. The confirmed attacks reached / and /index.php with multipart fields named PHP_SESSION_UPLOAD_PROGRESS; the source addresses 15.204.59.70 and 162.35.99.94 appear in the honeypot evidence (one source only, below).
sudo zgrep -hE 'PHP_SESSION_UPLOAD_PROGRESS|15\.204\.59\.70|162\.35\.99\.94' /var/log/apache2/*access* /var/log/nginx/*access* 2>/dev/null
Hunt for what an attacker leaves behind. List files written to the web root since the first attempts on October 17, 2026, then review new cron jobs and new accounts; anything here means isolate the server and rotate the secrets it held.
sudo find /var/www /srv -type f -newermt 2026-10-17 -printf '%Tc %p\n'; sudo crontab -l; sudo tail -n5 /etc/passwd
Reach the servers nobody lists. Old staging copies, a marketing microsite, an appliance with a PHP admin panel. Loop the checks above over your inventory instead of visiting each box by hand.
while read H; do echo "== $H =="; ssh "$H" "ps -eo ppid,comm,args | grep -E 'apache2|httpd|php-fpm'"; done < hosts.txt
On-device logs may not reach back to October 17. If a client keeps a SIEM or syslog archive, run the same searches there for the full window, and treat a clean on-device result as "nothing recent," not "never touched."
Every PHP install serving web requests before the October 21 fixes is affected, and a separate flaw has no fix at all. The engine bug sits below your clients' applications, so a tidy, well-coded site inherits it anyway.
| Branch | Affected | Fixed in | Source |
|---|---|---|---|
| PHP 8.5 | < 8.5.12 | 8.5.12 | PHP |
| PHP 8.4 | < 8.4.27 | 8.4.27 | PHP |
| PHP 8.3 | < 8.3.36 | 8.3.36 | PHP |
| PHP 8.2 | < 8.2.35 | 8.2.35 | PHP |
| PHP 7.4 / 8.0 / 8.1 | all | source backports only | PHP |
The third flaw, CVE-2026-115560, affects even fully patched PHP, including 8.5.12, but only on a server with an unusual setup: the application has to switch its session serialize handler to php at runtime with session upload progress still on. PHP Foundation executive director Elizabeth Barron said it "requires a very unlikely combination of configuration and specific PHP application code," so The Register reported it will wait for the next regular release. There is no fix today, no exploitation reported, and the interim mitigation is to set session.upload_progress.enabled=0.
Patch and restart, in that order, and don't settle for a config tweak. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution's patched package), then restart every PHP worker so the running processes pick up the fix. PHP's advisory is blunt: "There are no complete mitigations, updating is the only safe choice."
sudo systemctl restart php8.4-fpm apache2 (adjust the version), and confirm the web runtime now reports the fixed version.memory_limit = -1 and post_max_size = 8M (use 32M only if the app needs uploads) via php_admin_value, add session.upload_progress.enabled = 0, and restart workers. PHP says these "do not make an installation safe."Watch two traps: distribution packages often keep an old version string while carrying the fix, so trust the vendor advisory over the banner; and end-of-life branches (8.1 and older) get no official release, only source backports.
The hard part was never the patch. It's knowing every place a client runs PHP — including the forgotten staging box — and proving a server is genuinely safe rather than trusting a version banner that can lie. That's the gap an autonomous pentest closes across your whole client book.
An attack is someone doing this without permission; a pentest is the same reconnaissance run with your client's permission, inside a scope, with a report they can act on. Point KinoSec at a client's external web surface and it maps what's reachable from the internet, fingerprints the technology behind it, finds vulnerabilities and chains exploits the way an attacker would, then writes up findings with remediation. You re-run it after patching and hand each client evidence instead of a promise.
It is confirmed exploited in the wild as of October 26, 2026. Perplexity detection lead Adel Karimi captured a working remote-code-execution attack against an internet-facing PHP server, and Expel threat researcher Marcus Hutchins called it "by far the highest quality confirmation" he had seen, per BleepingComputer. Earlier in the week most firms had seen only scanning and non-working exploits.
Look for the one signal that proves execution: a shell spawned by a web process. Run the process-ancestry search in the second step of "How do I check if my clients were already hit?" above, which Datadog calls the strongest evidence. Then run the error-log and access-log searches in that same section, including the confirmed source IPs 15.204.59.70 and 162.35.99.94, and list new files in the web root since October 17, 2026.
No. PHP's advisory states plainly that "there are no complete mitigations, updating is the only safe choice." The session.upload_progress.enabled=0 setting is a partial stopgap for one path and is the interim mitigation for the separate, unpatched CVE-2026-115560, but it does not make a server safe from the two patched flaws. Only upgrading to a fixed PHP release and restarting every worker closes the hole.
As of October 26, 2026, neither CVE-2026-109618, CVE-2026-109619 nor CVE-2026-115560 appears on CISA's Known Exploited Vulnerabilities catalog. Confirmed in-the-wild exploitation makes a KEV listing likely soon, so recheck the live catalog. KEV status does not change the urgency: patch regardless of whether it is listed.