PHP2Shell Was Exploited Four Days Before the Patch, and a New Unpatched PHP Flaw Followed. Do You Know Where PHP Runs in Your Estate?

Attackers started probing the PHP2Shell flaws four days before PHP shipped patches, and a separate unpatched PHP remote code execution bug was disclosed the next day. According to BleepingComputer, Amazon Threat Intelligence says exploitation attempts against PHP2Shell (CVE-2026-109618 and CVE-2026-109619, both critical RCE) began on Saturday 17 October 2026. PHP released fixes on 21 October.

Timeline

• 17 October: Amazon says the first exploitation attempts hit one of its honeypots while the flaws were still under embargo. Payloads varied, which suggests more than one actor. It is unclear how they obtained the details.
• Before 21 October: CVE IDs and mitigation advice given to some critical infrastructure providers leaked online. PHP moved its release date up.
• 21 October: Patches released. Amazon says attackers deployed several proof-of-concept exploits within hours.
• 22 October: Amazon and Dataminr publish reports.

What is and isn't known about exploitation

AWS CISO CJ Moses said PHP2Shell is "now seeing broad exploitation attempts in the wild." Success rates are unclear. Dataminr's TRACE team describes the activity since disclosure as limited to scanning, fingerprinting and non-working exploits, with no known compromises, but warns that working exploits are "only a matter of time." Cloudflare, watchTowr, Previdian, Hadrian and Patchstack also saw unsuccessful attempts before disclosure.

Amazon's advice is worth repeating: defenders should not assume the public disclosure date is the earliest date of exploitation. The UK NCSC has asked UK organisations to update PHP servers immediately or take them offline until patched.

A second PHP bug with no patch

On 23 October the PHP security team disclosed CVE-2026-115560, another RCE with no fix yet. PHP says exploitation needs an "unusual combination of configuration and application code":

1. session.serialize_handler is set to php_binary or php_serialize.
2. The application switches it to php at runtime with ini_set() before session_start().
3. Session upload progress is enabled.

PHP calls this unlikely in practice, and BleepingComputer reports no exploitation of this CVE. The mitigation is to set session.upload_progress.enabled=0 until a patch ships. The advisory will be published in full with the next release.

Why the exposure is large

VirusTotal tracks more than 5.1 million exposed PHP hosts, about 3.8 million of them with at least one port open to attack. W3Techs puts PHP at nearly 70% of websites. PHP is also embedded in CMS platforms, admin panels, legacy intranet apps and vendor appliances that nobody labels as "PHP", so the real question is rarely "have we patched our PHP server?" It is "which of our internet-facing hosts run PHP at all, and which version?"

What to do this week

• Patch to the 21 October releases wherever PHP is internet-facing.
• Apply the CVE-2026-115560 mitigation (session.upload_progress.enabled=0) and keep it in place until a fixed release.
• Check logs back to 17 October, not just from 21 October, for unusual requests to PHP endpoints.
• Build a list of every PHP host you expose, including those run by agencies, subsidiaries and vendors.

Where Obiguard Scout fits

The hardest step above is the last one. Obiguard Scout is an external attack surface management product. It maps what an organisation has exposed to the internet, including hosts, software versions and look-alike domains, and watches that picture for change. For an event like PHP2Shell, that gives you a starting inventory of which public hosts are running PHP and which versions are visible, so patching can be prioritised by exposure rather than by who remembers what.

Scope matters: Scout sees what is visible from the outside. It does not patch anything, and it cannot tell you whether a host is exploitable through a specific application configuration such as the one behind CVE-2026-115560. You can run a free check on any domain you own.

For related reading, see how recent supply-chain events changed the case for host-level monitoring.

The question to take away

If a patch for a flaw already under attack landed tomorrow, could you list every internet-facing host that needs it by lunchtime?

Run a free Scout check or talk to us about mapping your external attack surface.