PHP2Shell Exploited in Three Days: 14 Days Is a Maximum, Not a Target
Last week we covered the critical PHP fixes released on 21 October. Those flaws, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), are being exploited in the wild.
What happened
- Before the patch: Amazon Threat Intelligence saw attackers targeting the flaws four days before fixes were released. Several security firms also saw exploitation attempts, which they rated as unsuccessful.
- 21 October: PHP released fixed versions.
- 24 October: a honeypot run by Adel Karimi of Perplexity recorded confirmed remote code execution against Apache mod_php on PHP 8.4.26, the last unpatched 8.4 release. Expel’s Marcus Hutchins independently confirmed the findings.
That is three days from patch to confirmed compromise, with attacker interest starting before the patch existed. Karimi notes the evidence comes from one single-worker mod_php setup, so it does not show how reliable the exploit is elsewhere. It does show it works.
The Zero Day Clock
This is not a one-off. The Zero Day Clock, created by Sergej Epp of Sysdig, tracks how quickly publicly disclosed vulnerabilities are exploited. As reported by Tom’s Hardware:
- Mean time to exploit has fallen from nearly a year in 2021 to just over a day in 2026
- 73.2% of exploited vulnerabilities are now used before official disclosure, up from 31% five years ago
PHP2Shell fits that pattern exactly. Earlier this year I argued that 14 days is no longer enough. This is the evidence.
Cyber Essentials: 14 days is the ceiling
Cyber Essentials requires critical and high-risk updates (CVSS v3 7 or above, or rated critical or high by the vendor) to be installed within 14 days of release. Since April 2026, missing that is an automatic fail.
Too many organisations read that as “we have 14 days”. The NCSC requirements say otherwise:
“It’s important that updates are applied as soon as possible.”
“14 days is considered a reasonable period to be able to implement this requirement. Any longer would constitute a serious security risk while a shorter period may not be practical.”
Fourteen days is the longest you can take and still pass. It is not a target. An organisation that patched PHP2Shell on day 13 would be compliant, and could have been compromised for ten days.
What to do
- Patch PHP now if you haven’t: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor’s backported packages. Restart PHP so the fix is live.
- Check for compromise. If any internet-facing PHP system ran unpatched after 21 October, review its logs. CISA has shared a SIGMA detection rule for PHP2Shell exploitation attempts.
- Apply the interim mitigation for CVE-2026-115560, a separate PHP RCE flaw with no patch yet: set
session.upload_progress.enabled=0. PHP says it is only exploitable with an unusual combination of configuration and application code. - Set a faster internal target. Internet-facing systems and known-exploited flaws: days, not weeks. Keep 14 days as the backstop for everything else.
Bottom line
Attackers moved on PHP2Shell before the patch and had working exploitation within three days of it. If your patching process is built around the 14-day deadline, it is built around the wrong number.
Sources