The usual story of a critical bug goes in a fixed order. A researcher reports it, the vendor patches it, and attackers reverse-engineer the patch. PHP2Shell broke that order. Someone was using it four days before PHP told the world it existed.

Before October 17: the research

The bugs, CVE-2026-109618 (an out-of-memory corruption path) and CVE-2026-109619 (a use-after-free in per-request state), trace back to research watchTowr credits to Calif.io. Both are rated 9.2 on CVSS v4.0, and both give an unauthenticated attacker code execution on the server. When Calif.io reported them to PHP has not been made public.

October 17: a honeypot catches it

Amazon runs a network of decoy servers called MadPot. On October 17 one of them logged a PHP2Shell exploitation attempt. The traffic came from an IP address belonging to a commercial anonymization service. Amazon believes a threat actor sent it. How that actor got the details is still unknown.

No advisory, no leak and no patch existed at this point.

October 20: a leak and a notice

Two things happened that day. A post on social media named the CVEs, claimed a 10.0 score and said every PHP version since 5 was affected (The Hacker News). And at 19:33 UTC, PHP's security team posted its own advance notice of a critical, out-of-cycle release, which is standard practice and gives operators a day to book maintenance windows.

watchTowr confirmed the flaws were real. PHP later rated them 9.2, not 10.0, and hasn't confirmed the claim about version scope. By the evening, people were calling the pair PHP2Shell.

October 21: six hours before the fix

• 07:34 UTC. Patchstack reports several active exploitation incidents from hosting partners.

• 07:43 UTC. Cloudflare's CTO says the company sees early attacks and has pushed WAF rules for the known exploit vectors to all customers.

• 13:52 UTC. PHP ships 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source backports for 7.4, 8.0 and 8.1.

• 13:57 UTC. Patchstack's telemetry still shows probing, with no hard evidence of breaches.

Some organizations didn't wait. They pulled services offline before the fix, which is also what the UK NCSC now advises for any system that can't be patched straight away.

October 22: the code goes public

Proof-of-concept repositories for both CVEs are appearing on GitHub. As of watchTowr's last update, the CVEs were not yet in CISA's Known Exploited Vulnerabilities catalog, though CISA has issued an alert urging immediate patching.

Did the attacker really find it before PHP?

That's the question in the headline, and the public evidence doesn't settle it. We know an attacker had a working exploit on October 17. We don't know when Calif.io's report reached PHP, so we can't say who got there first.

There are a few ways it could have happened. Someone may have found the same flaw independently; memory bugs in a runtime this widely deployed draw skilled people on both sides. The details may have slipped out of the private disclosure chain, which grew once Linux distributions and long-term-support vendors received patches ahead of release. Or the bug may have been in quiet use for a while, and October 17 was simply the first time a sensor was in the right place.

Whichever it was, defenders end up in the same spot. An advisory date marks the moment a vendor goes public. Attackers may have started well before it.

What the timeline means for your team

A team that only reacted to advisories had zero warning for four days and about six hours of known exploitation before a fix existed. Everyone who saw it early was watching live traffic: a honeypot operator, a CDN and hosting providers with telemetry.

Two lessons follow. Detection has to run independently of the patch calendar, because the calendar starts late. And when the fix does land, the team needs to judge the exposure quickly: which hosts run mod_php, which runtime is actually serving traffic, and whether an interim mitigation is good enough to hold for a day.

That second skill comes from practice. In the SimulationsLabs scenario library, players work through real vulnerable services: a PHP file-upload service in secureArchive, an insecure deserialization chain in HealthChk, and over 200 others spanning web security, cryptography, OSINT and Linux privilege escalation. Run them as an internal CTF or a timed cyber drill, and you'll see who can turn a vague advisory into a working exploit path under pressure.

Start for free or request a demo, and run your first drill before the next out-of-cycle release.