Even the dark web took PHP2Shell seriously

Within two days of PHP2Shell becoming public, BreachForums told its members "we take our security seriously". It's the same line that turns up in corporate breach notices, this time from a forum best known for trading stolen credentials and leaked corporate data.

Tenable's Research Special Operations team tracked how the criminal underground reacted to the two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. DarkForums went offline and said it would stay that way "until PHP has been patched globally". Dread, the Reddit-style forum on Tor, posted a maintenance notice naming both CVEs. Others restricted new registrations or moved conversations to Telegram, and several were offline within hours of disclosure.

Those operators knew exactly what sat behind their PHP stack (member identities, private messages, stolen credentials listed for sale) and that law enforcement and rival groups would both be looking for a way in. A forum's estate is far smaller than a bank's or a university's, so the comparison flatters them. It does show what response speed looks like when the list of things you run is short and known.

The first instruction was to find it

The Australian Cyber Security Centre's alert on 21 October asked organisations, first, to "identify PHP within their environments". Applying patches came third on its list. The order is right, and in my experience it's also the step that takes the longest.

Both vulnerabilities are rated 9.2 under CVSS v4.0 by the PHP security team, and both can let an unauthenticated attacker run code on a web server. Fixed releases for the supported 8.x branches landed at 1am AEDT on 22 October. Under the Essential Eight, which stays in force while ASD moves to its new Essentials series, a vendor-rated critical vulnerability in an internet-facing service should be patched within 48 hours of release, a timeline that assumes you already know which servers need patching.

Where the 48 hours go

According to W3Techs, PHP runs 69.3 per cent of websites whose server-side language is known. It sits underneath WordPress, Magento and Drupal, which is also the foundation of GovCMS, the platform behind many federal government websites. Very little of it was installed by a security team. It came in with a microsite an agency built for a 2019 campaign, a WordPress install a business unit set up for one event, a customer portal a vendor hosts on the company's behalf, and a container image someone pulled from a public registry and never rebuilt.

So when a CISO asks where the organisation is running PHP, the honest answer tends to involve several teams and a few days of asking around, and it still misses the microsite nobody remembers commissioning.

The version question adds a second layer. Supported branches 8.2 to 8.5 have fixed releases. For 7.4 to 8.1 the PHP security team published source backports, which help only if you build PHP yourself, and anything older gets nothing from the project. An end-of-life install found on day three is a migration with a test cycle and an outage window attached, which puts it well outside any 48-hour window.

The investigation starts on 17 October

Amazon Threat Intelligence observed an exploitation attempt against its honeypot network on 17 October, four days before the fix was public, and CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue on 26 October. A compromise assessment that starts from the disclosure date is starting too late.

Installing an updated PHP package doesn't touch workers that are already running, and until PHP-FPM or Apache is restarted the old code stays in memory and stays exploitable. A remediation report that counts package versions without checking running processes will overstate how much has been fixed.

The question for this week

The useful question for a security team now is how long it took to produce a complete list of PHP installations, with versions, including the internet-facing ones nobody in IT owns. If that took days, the 48-hour window had closed before patching began, and the next critical flaw in a common web component will run on the same timetable. That list needs maintaining between incidents; rebuilding it under pressure is where the time went this time.

Threat actors worked out what it was running within hours. Ask your team how long it took you.