PHP2Shell: 7 Log Signals That Show You've Been Hit

If your organization runs anything on PHP, patch it today and start looking for signs someone got there first. On October 21, 2026, the PHP project shipped emergency fixes for two critical remote code execution flaws now called PHP2Shell. Five days later, CISA added both to its Known Exploited Vulnerabilities catalog.

PHP sits behind WordPress, Drupal, Joomla, Magento, and countless internal tools and appliance admin panels. That means most mid-sized companies have exposure they may not even know about. This post covers what happened, what attackers are doing, and the exact log signals your team should hunt for this week.

Raj Choudhary has spent 15 years building enterprise SIEM and SOC programs. He founded Vigilense AI to give mid-sized teams the same detection and response large enterprises have.

What PHP2Shell is

PHP2Shell is a pair of memory-safety bugs in the PHP engine itself, so a perfectly written app can still be vulnerable. Both are rated CVSS 9.2 and allow code execution with no login. The root cause is how PHP cleans up after an out-of-memory error: leftover internal state survives into the next request on the same worker, and an attacker can shape that memory (Wiz Research, PHP advisory).

Who is affected: every PHP setup that serves web requests, including Apache mod_php (highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The oldest affected path goes back to PHP 5.4 (SentinelOne, UK NCSC).

Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no full fix, and 8.2 reaches end of life on December 31, 2026 (Decrypt).

A third, narrower bug (CVE-2026-115560) was announced on October 23. It only applies to apps that switch session serializers at runtime and will be fixed in the regular release cycle (The Hacker News).

Timeline

It took 63 days from discovery to patch, and attacks started before the patch existed.

The root problem was spotted in a 2024 audit, but nobody could prove it exploitable then, so the fix stalled (SentinelOne).

Who is attacking, and how

Exploitation is confirmed: CISA listed PHP2Shell as known exploited on October 26, and honeypots have caught attackers running real shell commands.

• Mass scanning. Cloudflare saw thousands of attempts before disclosure and millions within a day.
• Real shells. Honeypots caught attackers using curl, wget and php -r to call back to a remote server, the usual step before dropping a payload.
• State-linked targeting. CYFIRMA tied slow, rotating scans of 216 chosen hosts (government, banks, airports, payment platforms) to a group linked with moderate confidence to Lazarus. Rate-limit alerts will miss it.

Palo Alto Unit 42 also saw an AI-driven attacker go from a vulnerable PHP app to Domain Admin attempts in under two hours at a European agency. It later said it could not confirm PHP2Shell was the entry point, but the speed is the lesson.

Why this one is different: complexity is no longer a defense

These bugs sat in PHP for over a decade because exploiting them was too hard for almost anyone to bother. AI changed that math. Wiz says frontier models let one researcher do in a week what used to take a top team months, including adapting the exploit to each target's memory layout.

The same tools work for attackers. Once a patch is public, AI can help reverse it into a working exploit in hours. That is why the gap between disclosure and mass exploitation here was measured in minutes, not weeks.

For a security team, this means two things:

1. Patch windows are shrinking. "We'll get to it next maintenance window" is no longer safe for internet-facing systems.
2. Post-exploitation moves at machine speed. The European agency case above went from foothold to Domain Admin attempts in under two hours. A human-only SOC working tickets in the morning cannot keep up with that.

PHP2Shell also is not a one-off. In July, AI-assisted research produced wp2shell, a pre-auth RCE chain in WordPress core (Wiz). Expect more "too complex to exploit" bugs to fall the same way.

What to do this week

Patching PHP itself is the only full fix. Updating WordPress or a plugin does not close this gap.

• ☐ Inventory every PHP install. Include appliance admin panels, load balancers and vendor products that bundle PHP. NCSC-NL keeps a list of affected third-party software on GitHub.
• ☐ Patch internet-facing systems first. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every worker.
• ☐ Verify the version from the web side. The command-line PHP often uses a different config than the web server.
• ☐ Ask your host or MSP for confirmation if you don't manage the server yourself.
• ☐ Running PHP 8.1 or older? There is no full fix. Upgrade, or take the system offline until you can.
• ☐ Assume compromise on anything exposed before patching. Hunt for web shells and new outbound connections, then rotate secrets the PHP process could read (database passwords, API keys, tokens).

If you truly cannot patch today, these reduce risk but do not stop every attack path (lilting.ch, Sliplane):

• Set session.upload_progress.enabled = 0 in php.ini or the FPM pool, not via ini_set(), and restart workers.
• On PHP 8.5, turn off fatal-error backtraces.
• Turn on vendor WAF rules (Cloudflare, AWS, Akamai, Fastly and others shipped them) and block PHP_SESSION_UPLOAD_PROGRESS fields in multipart POSTs at the edge.

Switching from mod_php to PHP-FPM is not a mitigation. FPM is also affected.

How to spot exploitation in your logs

The attack runs below the application, so app logs show little. The useful evidence is spread across web server, PHP, process and network logs, which is why correlation matters.

CISA has published a SIGMA rule in its GitHub repository that covers the process-level behavior. Known indicators so far include 204.76.203[.]7 (mass scanner) and 162.35.99[.]94 (callback server seen in honeypot shells).

A single signal is noisy. A 500 burst followed by a PHP worker launching curl to a new IP within minutes is not.

A hunting query you can run today

This finds PHP workers launching shells or download tools in the last 7 days. It uses OCSF process fields, so it maps to most EDR data. Adjust table and field names to match your SIEM.

SELECT time, device.hostname, actor.process.name AS parent, process.name AS child, process.cmd_line
FROM process_activity
WHERE time > now() - INTERVAL 7 DAY
  AND actor.process.name IN ('php-fpm', 'php-cgi', 'php', 'httpd', 'apache2', 'lsphp', 'frankenphp')
  AND process.name IN ('sh', 'bash', 'dash', 'curl', 'wget', 'nc', 'python', 'python3', 'perl')
ORDER BY time DESC

Any hit on an internet-facing server is worth a full investigation. Some apps legitimately shell out (image tools, cron wrappers), so build an allowlist from what you find in the first run.

How Vigilense AI helps

Attackers are using AI to move from foothold to domain admin in hours. Defenders need the same speed. Vigilense AI is an AI-powered MDR platform built for teams of 50 to 500 people that don't have a 24/7 SOC.

• Detections for PHP2Shell behavior. We are rolling out rules for the signals above across customer tenants: PHP workers spawning shells or download tools, the 500 to OOM to worker-crash sequence, and web servers calling out to new hosts.
• AI investigations in minutes, not hours. When an alert fires, our investigation agent pulls the related web, process, network and identity events, links them into one story, and tells you if it is a scan or a real compromise.
• Alert consolidation. ThreatFusion groups the flood of scan noise into a few incidents, so the real hit does not get buried under a million probes.
• Your data stays yours. With our Bring Your Own Database design, we query logs where they already live (SQL, KQL, SPL and more). No rip-and-replace of your SIEM.
• Humans approve the big moves. Containment actions like isolating a host or disabling an account go through analyst approval.

Not sure if you were hit?

We'll run a free PHP2Shell compromise assessment across your web servers: the 7 signals above, the hunting query, and a review of outbound traffic since October 17. You get a written result within 48 hours.

Book your free assessment →

Sources

• PHP security advisory, GHSA-w8hw-w9fx-j79w
• PHP security advisory, GHSA-6wmf-4rv5-p3rp
• Wiz Research, PHP2Shell disclosure
• UK NCSC, Critical security issue affecting PHP
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching (updated Oct 26, 2026)
• The Hacker News, PHP2Shell Exploitation Attempts Continue Amid Suspected N. Korea Global Scanning Activity (Oct 25, 2026)
• SentinelOne, Stopping PHP2Shell
• BleepingComputer, PHP ships emergency patches
• Dark Reading, PHP2Shell Bugs Signal Red Alert
• Rapid7, PHP2Shell coverage
• lilting.ch, php2shell needs the PHP patch
• Wiz, Exploitation in the wild of wp2shell
• Reuters and BBC coverage, Oct 21 to 23, 2026