The PHP Foundation says AI-assisted research has changed the volume of PHP vulnerability reports it handles: 15 CVEs published since 1 July 2026, plus more than 100 reports in the same stretch that turned out to be invalid, duplicated or not reproducible. That is what a bug hunt looks like when the hunters have tools that never sleep. For a site owner, the useful part is the timing. The gap between a fix shipping and someone trying it is now measured in hours.
What the Foundation actually said
In its 21 October post, the PHP Foundation says tools now find bugs faster for defenders and attackers alike. It names the work behind that: a scan of PHP with Anthropic’s Claude Mythos run with Alpha-Omega, OpenAI’s Daybreak Red used to validate reports, and outside audits from Calif, Wiz and Trail of Bits.
The same post traces the bug that became php2shell back to a 2024 audit. A contractor found early signs of a memory problem then, a possible exploit was described, and no concrete route was found. The fix stalled for months while the security team argued over trade-offs. On 11 August 2026 a researcher at Calif demonstrated unconditional remote code execution from the same root cause. OpenAI reported it independently, Wiz sent more attack vectors on 24 August, and OpenAI again on 18 September. The Foundation calls the delay a structural failure of its own process and its own resourcing.
That admission is worth reading, because most vendors would have shipped a press release instead. The Foundation’s account of the release is the primary source, and it runs longer than any coverage of it.
The window between patch and attack
The release was planned for 22 October at 14:00 UTC. It shipped a day early, and the day it shipped had its own leaks.
| When (UTC) | What happened |
|---|---|
| 20 Oct, 15:00 | CVE numbers start circulating on forums with a wrong severity of 10.0. The real score is 9.2 |
| 20 Oct, 19:30 | PHP publishes its pre-announcement early and moves the release forward a day |
| 21 Oct, 07:41 | Chainguard publishes build images containing the fix, six hours before the agreed time |
| 21 Oct, 14:00 | Patches ship as 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| 23 Oct | CISA adds a detection rule to its alert |
A published image with the fix in it can be read by anyone who knows how to look, which is what makes those six hours matter. The Foundation also says one of the reporting firms published a proof-of-concept video by mistake, deleted it, and watched copies spread anyway. By the time the patch was public, the tools to study it were already loose.
Why shared hosting is the awkward part
On shared hosting the PHP build belongs to the server, so the patch schedule belongs to your host. You cannot apply it yourself, you cannot see when it landed, and you share the machine with every other account on it. That is why the version in your response header matters more than the version on your WordPress dashboard.
Two sites can sit on the same server, one owned by someone who checks and one by someone who does not, and both get patched or neither does. The branch you pick in the control panel is only half the story, because the patch level inside that branch is set above you. My own site showed exactly that on 22 October. The header said 8.2.33 in the morning and 8.2.35 by the evening, and MilesWeb did it without a ticket from me.
What to look for in a host, or in the one you already have
- A PHP version selector you can use yourself. If changing the version needs a ticket, every future security release needs a ticket too.
- A patch policy with an hour count in it. “Within 24 hours of a PHP security release” is a policy. “We keep PHP up to date” is a sentence.
- A firewall that is on by default, with rules for new CVE numbers. Good hosts push blocking rules while the server build is still being rolled out.
- Logs you can ask for by date. If support will not send you last week’s access logs, you cannot investigate anything.
The order matters. The version selector tells you what you control. The policy tells you what happens when you are asleep. The firewall covers the hours in between, and the logs tell you afterwards whether any of it worked.
What I do on my own site
This site runs LiteSpeed on PHP 8.2. On the morning of 22 October the response header said 8.2.33, which sat inside the affected range. I did not change anything. My host patched the build during the day, and by the evening the same header said 8.2.35.
The version is only the top of the list, so I checked the rest anyway. Two user accounts, both created in August. Four plugins, all expected. One theme. Nothing that should not be there. The site also served a short spell of 503s while the build was swapped, and I have already written about what a 503 during patching does to rankings. A few minutes of downtime is the cheap side of this trade. The rest of the php2shell week is in the earlier post.
Three questions to email your host this week
- Which PHP build is my account on today, and when was it last patched?
- What is your written policy for PHP security releases, in hours from the upstream release?
- Can you send me the access logs for 20 to 23 October, and confirm whether firewall rules for CVE-2026-109618 and CVE-2026-109619 are active on my server?
You can check the version yourself in about a minute. In WordPress that is Tools, Site Health, Info, Server. The full list of patched builds is in the PHP release announcement.
Fifteen CVEs in under four months is the rate now, and the Foundation says the reports will keep coming. The part you can actually move is the machine under your site, and whether you can see what it is doing without opening a ticket.
