php2shell ten days on: confirmed attacks and a third flaw

Ten days ago CISA, the US cybersecurity agency, wrote that it had seen no php2shell attacks. On 26 October the two flaws, CVE-2026-109618 and CVE-2026-109619, went into its catalogue of exploited vulnerabilities, and federal agencies got three days to fix them (catalogue). Meanwhile around twenty firewalls were breached, and the PHP project flagged a third flaw that the 21 October releases don't fix. What the first two do, and how to tell whether your PHP is patched, we covered in our 22 October article.

Two retracted claims and the first proof

Sophos, on 22 October, reported a successful attack at a customer and corrected itself that same evening: it had been scans and attempts that went nowhere. Unit 42, Palo Alto Networks' research team, had tied an intrusion at a European government body to php2shell, and two days later withdrew the update because it couldn't confirm the attackers had got in that way.

The first proof that holds up came from researcher Adel Karimi on 24 October: 35 shells, meaning 35 times the attacker was able to run commands on the server, on three decoy servers running PHP 8.4.26 and Apache with mod_php. Karimi himself warns that he set them up to make the attack easier, with a single Apache process, and that after getting in nobody downloaded anything else.

On public exploits Sansec called it right. Hundreds went round on GitHub and, according to VulnCheck, the real ones can be counted on one hand. Working ones do exist, though: VulnCheck's own, which it keeps private, was getting into PHP 8.2.28 through 8.5.11 with mod_php and default settings as of 26 October. Wiz, in the systems it watches, still hadn't seen an attack succeed from start to finish on the 27th.

The noise, meanwhile, was huge. Cloudflare counted thousands of attempts in the ten hours before the announcement, and then millions (The Register). Yet as of 26 October CrowdSec counted no publicly confirmed compromise, and its data showed attackers testing rather than harvesting. Hosts moved fast: according to webhosting.today's timeline, SiteGround, Hostinger, GoDaddy, OVHcloud, Hetzner, cPanel and CloudLinux had patched PHP or put blocking rules in place by 22 October. Kinsta closed its incident with no evidence of breaches, and Hostinger saw no rise in infections.

Palo Alto's firewalls

The first real attack on record hit firewalls. Dream Research described a campaign against the web interface used to manage Palo Alto firewalls, which runs on PHP 8.0.30 underneath. The attackers chained php2shell with a Linux kernel flaw, CVE-2026-46300, and with a single request and no password they became root. Twenty-five servers taken, across the United States, Japan, Taiwan and South Korea.

Palo Alto marked its advisory as «attacked» and released fixes for every supported version. According to Unit 42 the company contacted each affected customer, about 0.02% of installed devices: all of them with firewall management reachable from the internet.

PHP 8.0 hasn't received fixes since 26 November 2023, and it was sitting inside the device meant to protect the network. Firewalls, NAS boxes, VPN panels and phone systems often have a web management page, and only the vendor knows which PHP runs under it. That's why we wouldn't leave the management of these devices reachable from the internet, even with the fixes installed.

In Italy

The Italian figures came from ACN, the national cybersecurity agency, on 25 October, based on Censys data: 741,523 PHP services exposed to the internet. Of those whose version can be read, 285,149, or 81.9%, use one that is potentially vulnerable. The agency hedges its own count: it includes servers patched without a version change, as CloudLinux, Plesk and cPanel do, so the ones actually at risk are fewer. Three days later its bulletin recorded both flaws being exploited in the wild.

Aruba says the update on its hosting plans was done automatically; on cloud and dedicated servers it's up to the customer. Verified reports of Italian sites breached through php2shell, as of 31 October, we haven't found.

The third flaw, still unpatched

CVE-2026-115560 was announced by the PHP project on 23 October in a separate advisory. It goes through the same mechanism as the second flaw, the one that tracks uploads in sessions, and the project considers it an unlikely scenario: it needs an application that changes the session format while running, with ini_set() before session_start(), and that mechanism still switched on. The fix will come with the next regular release; it isn't in the 21 October versions.

The project and ACN point to the same measure, session.upload_progress.enabled=0, which was already among the temporary ones on 22 October. The feature it turns off only exists to show how far a file upload has got. We'd switch it off everywhere, even where you think the application never touches the session format: with a CMS and a few dozen plugins, you can't be sure.

What to check now

1. 01Ask your host for written confirmation: PHP with the 21 October fixes, and processes restarted. The message to copy is in the 22 October article.
2. 02Put session.upload_progress.enabled=0 in the server or PHP-FPM pool configuration, because ini_set() doesn't count, and restart the processes. On shared hosting, add it to the same message.
3. 03In the logs, from 17 October onwards, look for file uploads to pages that have no forms, out-of-memory errors and PHP processes ending abruptly.
4. 04List the devices with a web management page and check that none can be reached from the internet. On a Palo Alto firewall, install the fix given in its advisory.

Ten days ago we wrote that we wouldn't wait to find out whether Amazon or Sansec was right. In the end they were both half right: the public exploits didn't lead to mass attacks, and the private ones were used for targeted ones. If you'd like a second opinion on a server or an exposed device, write to us.