PHP2Shell is two critical remote code execution flaws in PHP (CVE-2026-109618 and CVE-2026-109619). The patches shipped on October 21. Attackers did not wait for them.
Amazon Threat Intelligence reports that exploitation started four days before the patches. The embargo leaked. Defenders lost their head start.
How the race works now
An attacker follows a short loop:
- Download the patch.
- Diff it to find the changed code.
- Ask an AI model to turn that diff into an exploit script.
- Test the script against exposed servers.
AI shortens steps 2 and 3 from days to hours. Calif found the flaws with AI during an audit in August. Attackers can use the same tools to work backward from the fix.
Here is a small, simplified example. A patch adds one line that checks a length before a memory copy. That line tells the attacker exactly where the old code trusted its input. The attacker no longer needs to audit millions of lines of PHP. The patch points to the weak spot. A model then drafts a request that sends an oversized value to that code path. The first version usually fails. The attacker adjusts it and tries again. Each loop takes minutes.
A PoC is not an exploit
Dozens of public PoCs appeared within hours. Most of them fail. VulnCheck reports that many only work on x86 systems with ASLR turned off, or on ARM64.
This creates noise. Defenders see a PoC and assume every server is at risk. Attackers filter the broken ones in minutes and keep the few that work. Defenders rarely have that speed.
Consider two teams that read the same headline. Team A sees a public PoC crash a test server and declares the whole estate safe. Team B sees the same crash and declares the whole estate on fire. Both are wrong. The crash only shows that one script failed on one configuration. It says nothing about your servers, your PHP build, or your memory settings. Only a test against your own systems answers that question.
Why ASLR decides if a PoC works
Memory corruption gives an attacker control of data. To run code, the attacker also needs to know where code and data live in memory. Address Space Layout Randomization (ASLR) moves those addresses each time a process starts.
Most public PoCs hardcode addresses. On a server with ASLR turned off, those addresses stay the same, so the exploit lands. On a server with ASLR on, the script guesses wrong and usually crashes the worker. ARM64 builds behave differently, which explains why VulnCheck saw RCE there too.
Check your Linux hosts:
|
cat /proc/sys/kernel/randomize_va_space # 2 = full randomization (good) # 0 = off (public PoCs may work as-is) |
A value of 2 raises the cost of an attack. It does not fix the flaw. A skilled attacker can chain an information leak to defeat ASLR.
What the attack traffic looks like
Calif controlled memory with as few as a few dozen requests. On small systems, that takes seconds.
That traffic has a shape. Look for a short burst of similar requests from one source. Each request changes slightly in size or structure. Look also for a spike of PHP worker crashes or restarts (php-fpm "child exited on signal 11" lines). A crash pattern often means someone is tuning an exploit against your server. VulnCheck released Suricata rules for this traffic. Deploy them, and alert on worker crash spikes in the same window.
Know your version
|
PHP branch |
Fixed version
|
|---|---|
|
8.5 |
8.5.12 |
|
8.4 |
8.4.27 |
|
8.3 |
8.3.36 |
|
8.2 |
8.2.35 |
|
8.1 and older |
No fix |
Check each host:
|
php -v php -i | grep -i "configure" |
Your Linux distribution may backport the fix and keep an old version string. Check your vendor advisory before you trust the number.
Why old bugs come back
A researcher flagged this area of PHP years ago. Most people judged it too hard to exploit, and it faded from view. AI changed that math. Work that once took an expert weeks now takes a model and a patient operator a few days. Revisit every "too hard to exploit" decision in your risk register. The cost to exploit those bugs just dropped.
What an attacker looks for
Attackers do not start with your asset inventory. They start with what answers on the internet:
- End-of-life PHP. PHP 8.1 and older will not get a fix.
- Forgotten legacy apps. Nobody has touched them in years.
- Vendor appliances and internal tools. Many embed PHP and hide it from your scans.
A typical case looks like this. A marketing team launched a campaign microsite in 2019. An agency built it on PHP 7. The agency closed. The site still runs on a forgotten virtual machine, and it is not on any asset list. Your patch report shows 100% complete. The attacker finds the microsite in minutes.
Find PHP the way an attacker does:
- Response headers: X-Powered-By: PHP/7.4.3 tells an attacker the exact version.
- Cookies: a PHPSESSID cookie marks a PHP backend, even with headers stripped.
- Paths and errors: .php URLs, index.php redirects, and default PHP error pages.
- Inside the build: search container images and appliance firmware for php-fpm or libphp.
Run the outside checks against your own internet-facing assets first. That list is the attacker's target list.
A patch is not proof
Teams apply a WAF rule or an interim mitigation and move on. That rule blocks one attack path. The flaw stays in place. Months later, nobody remembers why the server never got the update.
Verify from the outside. Test the system the way an attacker would, after the fix. A status report says someone clicked "done". A test shows whether the door is still open.
What to do before the next advisory
Answer three questions in the first hour: Do we run it? Where? Is it exposed?- Assign an owner to every application, and a review date to every end-of-life exception.
- Give every temporary mitigation an owner, an expiry date, and an open ticket until the real fix reaches production.
- Test your attack surface continuously. A yearly test cannot keep up with a race measured in hours.
If you are not sure what you expose, continuous testing such as Cobalt agile pentesting can map and validate your attack surface before the next advisory lands.
