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.
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.
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":
session.serialize_handler is set to php_binary or php_serialize.php at runtime with ini_set() before session_start().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.
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?"
session.upload_progress.enabled=0) and keep it in place until a fixed release.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.
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.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →