Yesterday we published a piece arguing that the week's PHP2Shell numbers counted different things and that no confirmed compromise was public. The second half of that is no longer true.
What changed
Adel Karimi, detection and response lead at Perplexity, confirmed successful remote code execution against honeypot systems on 24 October, three days after the emergency releases shipped on the 21st. CISA added both flaws to the Known Exploited Vulnerabilities catalogue on 26 October, and United States federal civilian agencies have until the 29th to install the patches.
Our sentence was accurate when it was written and it is not accurate now, which is the ordinary condition of writing about an incident while it is happening. Saying so is cheaper than letting the archive carry it.
What has not changed is the rest of that piece. Exposure counts, request counts and attempt counts still measure different things, and Unit 42's withdrawal of the European government link still stands.
What the catalogue says
The entries carry the catalogue's own names, which are more descriptive than the nickname: CVE-2026-109618 is listed as "PHP Memory Corruption Vulnerability" and CVE-2026-109619 as "PHP Stale Internal Request-State Vulnerability". Both were added on 26 October with a due date of 29 October, which is 3 days. Known ransomware use is recorded as unknown for both.
Three days is the shortest interval the catalogue sets, and it is now the second PHP entry this month to get it.
Why a honeypot is the evidence that arrives first
A honeypot is a system that exists to be attacked, instrumented so that everything done to it is recorded. 24 October is therefore the date that matters here, rather than the 21st, when the patch shipped, or the 26th, when the catalogue caught up. A honeypot is usually the first place a successful technique is seen, for an uncomfortable reason: a real victim often does not know, and when it does, it does not say.
The sequence in almost every one of these stories runs the same way. Attempts are counted by edge providers. Successes are confirmed on honeypots. Real compromises surface weeks later in breach notifications, or never.
A honeypot confirmation is strong evidence that the technique works in the wild. It is not evidence about how many production systems have fallen, and nobody should present it as that.
What this does and does not tell you
The confirmation tells you the exploit is real, reliable enough for somebody to run against an internet-facing target, and in circulation. What it does not tell you is that your server was hit, or how many have been, and the catalogue's 3-day deadline binds United States federal civilian agencies rather than you, however sensible it is to read as a signal.
The honest position after this week is narrower than either the panic or the dismissal: the flaws are being exploited successfully, nobody has published a victim, and the gap between those two facts is where most of the argument has happened.
What to do
- Patch, if somehow you have not. 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
- Review logs back to 17 October, which is still the earliest published probe, rather than to the disclosure date.
- If you run anything resembling a honeypot or a staging host that is internet-facing, check it first. It is the system most likely to hold evidence and least likely to be watched.
- Federal agencies have until 29 October. Everybody else should ask why their own deadline is later than that.
What is not established
- How many production systems have been compromised. No count exists and no victim has been named.
- Who is running the successful exploitation.
- Whether the honeypot activity and the mass scanning reported earlier are the same operators.
- What the exploit achieves against hardened configurations, as opposed to a honeypot.
- Whether ransomware operators have picked it up. The catalogue records ransomware use as unknown.
Adel Karimi's own write-up was not retrieved for this piece; the confirmation above is as the reporting of it describes.
