PHP2Shell: CVE-2026-109618 and CVE-2026-109619 Explained

The majority of web exploits need something from the application. A missing auth check, an upload that trusts the filename, a template that evaluates user input, a deserialization sink. This is different, the vulnerable code runs while PHP is building the request, before index.php is compiled or executed. Your router has not run. Your auth middleware has not run. Your WAF rules for /admin have not run. PHP is still parsing multipart/form-data.

That is what the lab in part 3 demonstrates. A hello-world application is enough to demonstrate it. I put one line in src/index.php: echo "hello from php2shell lab\n";. The exploit never needs it to do anything useful.

A reverse proxy or an edge WAF can still block the request before it reaches PHP, and that is worth doing while you patch. But the application itself cannot defend this path. By the time the app is involved, the interesting part is already over.

The 30-Second Version

The Bug Is Older Than the Exploit

The pattern here is not new. It has been sitting in PHP for a long time, and people kept walking past it for a very reasonable reason: proving that a half-initialized hash table can become code execution is hard.

In 2004, Stefan Esser found the first PHP memory-limit remote vulnerability. He did not release a public exploit. Commercial exploit vendors built private ones. For years, the public story was mostly folklore and fake exploits passed around IRC. The primitive was real, but it was not something a random researcher could reproduce from a blog post.

In 2020, someone reported PHP bug #78876. Long variables in multipart/form-data could cause an out-of-memory condition and leave temporary files behind. It looked like a cleanup annoyance, not a remote code execution bug. In 2024, the OSTIF and Quarkslab audit of PHP found a related OOM issue. They could not prove exploitation, so it was not treated as an urgent RCE. That is the important part of the story. The bug was findable. The exploit was not practical yet.

In 2026, two research efforts converged. Calif's Ryan Austin joined OpenAI's Patch the Planet initiative and started auditing PHP with an LLM companion, guided by the 2004 and 2020 history. Wiz Research ran its own AI-assisted audit and found four variants, then demonstrated RCE against WordPress, Drupal, and Joomla. The PHP Foundation and the PHP security team coordinated the fix. Calif reported the first bug on August 11 and the second on August 21. Wiz reported its set on August 24. PHP acknowledged the reports on September 21 and shipped the patch on October 21.

The disclosure did not go to plan. Details leaked on social media on October 20, before the planned date. PHP moved the release to October 21 at 14:00 UTC. AWS had already seen an exploitation attempt on October 17, from an anonymized IP, four days before the patch existed. watchTowr saw exploitation on its honeypots the next day. Public PoCs showed up within hours. This is the part defenders should remember: the public disclosure date is not the first day of exploitation.

The Chain in One Picture

The public PoC splits the work into four requests. Two create the dangling state; two consume it. Here is the chain at a high level:

The worker can crash after B2. In the lab it usually does, with AH00052: child pid ... exit signal Segmentation fault (11). The command has already run by then. A crash is common, but it is not required, and it is not a reliable success signal.

What This Shows and What It Doesn’t

Securing PHP2Shell

[php:error] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 4096 bytes) in Unknown on line 0
"POST /index.php?q0000000=v&q0000001=v..." 500 211
[php:warn] PHP Request Startup: Session ID is too long or contains illegal
characters. Only the A-Z, a-z, 0-9, "-", and "," characters are allowed
in Unknown on line 0
"POST /index.php" 200 1680406
[core:notice] AH00052: child pid 17 exit signal Segmentation fault (11)

# OOM during request startup
grep -R "Allowed memory size.*exhausted.*Unknown on line 0" \
  /var/log/php* /var/log/apache2 /var/log/nginx 2>/dev/null

# Apache worker segfaults
grep -R "AH00052.*Segmentation fault" /var/log/apache2 2>/dev/null

# Shell or interpreter children of a web worker
ps -eo pid,ppid,user,comm,args --forest | grep -E "apache2|php-fpm|www-data"
pstree -ap "$(pgrep -o apache2)" 2>/dev/null

# New files under the web root
find /var/www -type f -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' \
  2>/dev/null | sort

# Container drift
docker diff <container>
docker top <container>
docker logs --since 2026-10-17T00:00:00 <container>

Update Risk: The Part with side effects

The patch is not a one-line change. The main fix commit touches a large part of the engine because it changes how OOM unwinds and how request-owned state is reset. That is the right fix, but it means you should not treat the update as a silent package bump.

If you use the Remi RPM repository, PHP warned that it would not have updates on release day and urged users to switch to distribution packages or build from source. That is not a reason to wait. It is a reason to know where your PHP package actually comes from.

Rollback is a valid emergency lever, but be honest about what it means: rolling back reintroduces the CVE. Keep the previous image digest, roll back only with compensating controls, and put a hard deadline on the second attempt.

Were We Already Compromised?

Patching closes the door. It does not answer whether someone walked through it. If the host was exposed during the window, do the boring checks.

If you find evidence, treat it as an incident, not a patching task. Preserve logs and disk state, isolate the host or container, and follow your notification process. The exploit gives an attacker a web user's view of your app and its secrets. That is enough to matter.

Final Thoughts

The bug is older than the exploit. The exploit is narrower than the vulnerability. The lesson is not narrow at all: a memory-safety bug in the runtime sits below every framework, plugin, and auth check you have. You can write perfect application code and still be owned by the thing that parses the request.

The other lesson is about time. The patch window for a critical internet-facing bug is hours, not weeks. AWS saw an attempt before the advisory. Public PoCs appeared within hours of disclosure. AI did not create the bug, but it made the exploit cheaper to build. That genie is not going back in the bottle.

Patch PHP. Rebuild the images. Restart the workers. Then go read the logs from October 17. The lab in part 3 is here if you want to see what the traffic looks like before you decide whether your detection rules are real.

Credits and Sources