KIungefiltert

· 4 min read · Auf Deutsch lesen

PHP2Shell: From Scans to Working Shells

The PHP2Shell flaws are now being exploited successfully, and CISA lists them as actively exploited. Patches have been out since October 21. Unit 42 has retracted its link to an attack on a government agency.

securityself-hosting

Translated from the German original with an AI language model, approved by me. Read the original

PHP2Shell has taken a turn. Until a few days ago, most of the activity was scanning, fingerprinting and exploits that didn't work. Now attackers are launching real shells. If you run PHP servers, that's the news that matters.

What happened

PHP2Shell is the collective name for two critical flaws in PHP: CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution (RCE), meaning an attacker can run arbitrary code on the server remotely, and without logging in. According to BleepingComputer, details and proof-of-concept code leaked before the patches. The PHP team said none of them worked. Amazon Threat Intelligence reported exploitation attempts four days before the patches came out. Cloudflare, watchTowr, Patchstack and others judged those early attempts unsuccessful.

Then came the evidence from honeypots. A honeypot is a deliberately vulnerable decoy system that logs attacks. Researcher Adel Karimi (Perplexity) observed an attack on an Apache mod_php setup running PHP 8.4.26. The chain had four stages of HTTP requests: exhaust memory, leak memory contents, and finally run a shell command. According to SecurityWeek, 35 shells were launched across three honeypots on October 24. They came from two IP addresses: one produced 3 shells, the other 32. No second-stage payload download was observed. Marcus Hutchins (Expel) confirmed the findings.

One distinction helps here. These are honeypot numbers, not a count of confirmed victims. Karimi himself notes that his single-worker setup favored the attacker. The data says nothing about how reliable the exploit is on other configurations. But one thing is clear: attempts have turned into successful code execution.

What has changed since our post

Three things I need to add or correct:

  • Patches exist. Our post listed the patch status as unclear. In fact, the PHP team fixed the flaws on October 21. According to several distribution and industry sources, including AlmaLinux and computingforgeeks, the fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
  • CISA confirms exploitation. On October 23, the US agency still reported no successful attacks and published a Sigma detection rule. On October 26, it added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog, as reported by BleepingComputer and SecurityWeek.
  • Unit 42 walked it back. Palo Alto Unit 42 had linked an attack on a European government agency to PHP2Shell. It now says, per The Hacker News, that it cannot confirm initial access came through these CVEs. The attack itself still happened. Only its link to PHP2Shell has been withdrawn.

Who is affected

PHP is affected, and PHP runs a large share of the web. According to BleepingComputer, VirusTotal estimates more than 5.1 million publicly reachable PHP hosts. The sources don't say how many of them are actually vulnerable. Older branches, 8.1 and below, are especially tricky because they no longer get official updates (end of life). For those, fixes only come as backports from distributions or commercial vendors such as TuxCare.

There is also a third, separate flaw: CVE-2026-115560. It has no patch yet, only mitigation guidance. According to PHP, it can only be exploited with an unusual combination of configuration and application code.

What you should do

  1. Update PHP, either to the versions above or to your distribution's patched packages. Note that Debian, Ubuntu and others often backport the fix without bumping the version number. What counts is your distribution's security update, not the PHP version string it reports.
  2. Restart your PHP processes. That means PHP-FPM, Apache with mod_php, or whatever you run. Running workers keep the old code in memory.
  3. Use the interim mitigation where you can't patch right away. PHP recommends session.upload_progress.enabled=0. This is also the recommended mitigation for CVE-2026-115560. According to industry sources, though, it doesn't cover every PHP2Shell attack path and is no substitute for updating.
  4. Look for traces. Search your logs for unusual clusters of out-of-memory errors and crashed workers. Check web directories for unknown PHP files, which could be webshells. If you run a SIEM, you can add CISA's Sigma rule.
  5. Take end-of-life versions seriously. If you still run PHP 7.x or 8.0/8.1, use this as your reason to upgrade now.

My take: these flaws are demanding for attackers, and the honeypot successes came from a favorable setup. I still wouldn't rely on that. With a KEV listing, public exploit code and working shells, the order is: install the patch, restart the processes, check the logs. For self-hosted systems running PHP web apps, ideally today.

Sources