October 31, 2026
PHP2Shell ran on two clocks. The publicβs stopped first.
The first pre-announced, leaked and pre-exploited critical bug produced a curve we had not seen: 238,212 Wikipedia views on patch dayβ¦

By Andrii Kuzovchykov
8 min read
The first pre-announced, leaked and pre-exploited critical bug produced a curve we had not seen: 238,212 Wikipedia views on patch day, 5,255 ten days later, with the exploitation evidence, the CISA listing and the first rooted servers landing in the second half of that window. Log4j ran the other way.
On Tuesday October 20, 2026 at 19:30 UTC the PHP project pre-announced two critical bugs and a fix for 14:00 UTC the next day. By the time the advisory went up, at 13:34 UTC on October 21, 26 minutes early, the details had leaked, a container vendor had published the fixed images six hours before the scheduled release according to the PHP Foundation, and Amazon had found an exploitation attempt dated October 17 in its honeypots, four days before anyone outside the embargo was supposed to know. That same day the English Wikipedia article called PHP2Shell was read 238,212 times. The next afternoon a UK minister told the House of Lords that 32 government services were offline, and Finland's public sites had gone dark as a precaution.
This piece is about a shape, not a bug. PHP2Shell is, as far as our archive goes, the first critical vulnerability of its size that was pre-announced, leaked and exploited before its own patch, and it produced a curve we have not seen before: the public's attention peaked on the day of the fix and was down 95 percent eight days later, while the evidence of real intrusions, the regulator's listing and the first rooted servers all arrived on days three to eight, when almost nobody was reading any more. Log4j in December 2021 ran the other way round. The pre-announcement moved the public's clock forward. The attackers' clock did not move with it.
The chart below is the public's clock: 238,212 views on October 21, 153,627 on October 22, 76,748 on October 23, 31,660 on October 24, then 11,891 on October 28 and 5,255 on October 30, with one small up-day on October 26.
Figure 1 β Read on day one, forgotten by day eight
The public's clock: forty percent of the attention came on day one
Over its first ten days the PHP2Shell article collected 593,609 views, and 40 percent of them came on the first day. That is how scheduled events behave, not security stories. The pre-announcement told the world when to look, and the curiosity was spent on the one question most readers had: whether PHP, which W3Techs counts on about 70 percent of websites with a detectable server-side language, was going to be fixed. It was, in four releases. The only day the curve rose again was October 26, from 22,603 to 28,614, the day the US government listed the bugs as exploited. Then it fell to 6,647 on October 29, the day the first confirmed campaign was reported.
Wikipedia views are curiosity, not defenders; the people who patched read the advisory, not an encyclopedia. The page is a proxy for how much of the general public was paying attention, and that is the only claim I make for it.
Log4j did it the other way round
In December 2021 the Log4j article was viewed 313 times on December 9, the day Log4Shell was disclosed, 17,004 the next day, 36,394 on December 12 and 92,309 on December 13, the peak, on day four. It was 85 percent below the peak by day nine. The timeline from CSO Online puts mass exploitation in the same days the article was climbing; CISA listed the bug on December 10. The public learned about Log4Shell at the pace the attackers used it, because nobody had scheduled it.
Two caveats. Wikipedia's traffic in 2021 is not its traffic in 2026, so I compare the shape of each curve and nothing else. And in 2021 the attention split across two articles, because a separate Log4Shell page did not exist until December 12; it peaked at 26,350 on December 15. The shape holds on either page: a peak on day four to six, not day one.
Figure 2 β Log4j, December 2021: the peak came on day four
The attackers' clock: the evidence arrived on days three to eight
Here is the second clock, in order. The first proof-of-concept exploits appeared around 02:00 UTC on October 21, twelve hours before the embargo lifted. The Delft University tracker logged its first request at 08:37 UTC that day and by October 30 had counted 77,566 requests from 742 addresses in 73 countries, of which, by its October 26 count, 171 addresses had sent exploit code or droppers rather than probes. On October 24 a researcher recorded 35 successful shell executions on three honeypots from two addresses. On October 26 CISA listed both CVEs as exploited. On October 27 Wiz reported that in its own telemetry none of the attempts had succeeded and that exposed vulnerable machines had fallen about 67 percent in a few days. And on October 29 The Register reported, from a Dream report verified by Palo Alto Networks' Unit 42, that suspected Chinese attackers had chained PHP2Shell with a Linux kernel bug to root 25 servers, including two firewalls linked to US government-affiliated organizations compromised on October 23 and October 24, with a chain that completes in under 15 minutes.
Put the dates next to the views. The two firewalls fell on days two and three, with the article still above 30,000 views a day. The listing came on day five, at 28,614. The first public report of those intrusions came on day eight, at 6,647. By the time the story had a victim, the audience had left.
The listing is a useful ruler because it requires evidence of exploitation, so its date tracks when the evidence reached CISA. The catalog lists Log4Shell one day after disclosure, React2Shell two days after its December 3, 2025 disclosure, and both PHP2Shell CVEs and the Brotli bug nicknamed node2shell five days after theirs. Five is the slowest of the four, for the bug with the most attention on day one.
Figure 3 β Days from disclosure to the exploited list
What our feeds carried, and when we rang
Our own collection is a third, slower clock: 4 items on October 21, a proof-of-concept repository on GitHub trending, a technical write-up on Hacker News and a Register story; 13 on October 22 from five source types; 8 on October 23, when Meduza and The Moscow Times carried the Russian directive, which told operators to 'consider temporarily restricting external access to vulnerable web servers, up to and including taking them offline'; then 2, 1, 4, 3, 1 and 3 through October 29. Thirty-nine items in nine days, 25 in the first three. Our Stack Overflow feed caught four questions about the two CVE ids on days two and three, three of them from people trying to patch App Engine, Bitnami WordPress and a hand-patched Ubuntu 7.4: the defenders' clock, which starts when the operator reads the advisory and finds the hosted platform has not shipped the fix.
The honest part: our system clustered the story into a trend it named 'PHP Runtime Vulnerabilities And Patch Lag', 15 signals from 6 source types, and raised its first critical alert on October 23, two days after the patch, when the source-diversity trigger fired. Our alerting waits for independent corroboration by design, so we were a day behind the attackers' second firewall. The cluster also absorbed a Windows installer question and a PyPI backdoor, which is what clustering does to a hot week. The public trend page shows the raw items.
Figure 4 β What our feeds carried
Two normal explanations and one harder one
The boring explanation is that the fast decay is what a solved problem looks like. Wiz saw none of the attempts in its telemetry succeed, counted a 67 percent fall in vulnerable exposed machines within days and a 47.9 percent fall in affected organizations, and found that one week after disclosure less than 53 percent of initially affected organizations remained vulnerable. Weight about 40 percent: strong for the well-run half of the internet, silent on the half Wiz does not see.
The second boring explanation is that the attackers' clock is mostly noise. Delft's 77,566 requests hit honeypots built to be easy, the 35 shell executions were on honeypots too, Sophos and Palo Alto Networks walked back their early reports of successful attacks, and the one confirmed campaign is 25 servers in a single vendor report with a 'suspected' attribution. Weight about 25 percent: two government-affiliated firewalls verified by a second firm are more than noise, but not the mass event the day-one numbers implied.
The harder reading, mine, is that the pre-announcement changed who the information was for. A scheduled disclosure is designed for defenders, and it worked for them. But it also tells the public when to pay attention, and the public pays attention once, on the announced day, for about as long as it takes to learn there is a patch. The attackers do not read the schedule; their window opens when the fix can be diffed, which the PHP Foundation says happened at 07:41 UTC, and stays open for as long as there are unpatched servers. So the curves separate, attention front-loaded and exploitation back-loaded, and the reports that would keep the public on the second curve arrive after it has left. Log4Shell, unscheduled, kept the two together for a week. Weight about 35 percent. I would be wrong if the next pre-announced critical bug shows a Wikipedia curve that climbs for several days, or if the confirmed intrusions from this one stay at two firewalls and 25 servers.
What this data can't tell you
It can't tell you how many servers were compromised. Wiz's zero is Wiz's customers; Delft's 77,566 are honeypot requests; the 25 rooted servers are one vendor's report; CISA has not named a compromised organization.
It can't compare the three events on one scale. Figures 1 and 2 share a shape, not a y-axis. Our own feeds cannot see React2Shell at all: our Hacker News collection holds 74 items for December 2025 against 1,878 for October 2026, a coverage gap on our side, which is why React2Shell appears only through CISA's dates and SecurityWeek's numbers, more than 77,000 exposed addresses and more than 30 confirmed organizations by December 5.
It can't say that attention caused anything: two clocks ran at different speeds, and the piece shows the gap, not a mechanism. And it can't say how the bugs were found; the Wikipedia account, one flaw found on August 1 with an AI model during an OpenAI project and Wiz finding them independently the same month, is a synthesis of company statements I did not verify against primary sources.
What to watch
- The next regular PHP release, which the Foundation says will carry the fix for the deferred third vector, CVE-2026β115560; a second Wikipedia spike would mean the public's clock can be restarted.
- Whether the Brotli bug, with no reported in-the-wild exploitation as of October 27 per SecurityWeek, produces a confirmed intrusion by the end of November; it has public exploit code and no workaround on Node.js.
- A second independent report of PHP2Shell intrusions beyond Dream's 25 servers before November 30; one would move the harder reading up, none would move the second boring one up.
- Wiz's 'less than 53 percent still vulnerable' figure at the one-month mark; if it is still above 30 percent, the attackers' window is open while the public's is closed.
Reproducibility note
Wikipedia daily views are from the Wikimedia pageviews REST API (English Wikipedia, all access, human users), pulled on October 31, 2026 for PHP2Shell (October 21 to 30, 2026) and for Log4j and Log4Shell (December 2021); our own daily Wikipedia top-1,000 collection holds the same PHP2Shell rows for 8 of the 10 days and the same 2021 rows for December 10 to 23, and is the check, not the source. The CISA lags are calendar days from public disclosure to the dateAdded field in the catalog CSV downloaded on October 31, 2026. Our feed counts are distinct URLs per day across our live sources whose title names PHP2Shell, the two CVE ids or a PHP vulnerability, excluding page-view and catalog rows; they are our collection, not a census. The trend id is 25468. Honeypot counts are Delft's live page and The Register's October 27 report; exposure percentages are Wiz's own telemetry; the Russian directive is reported by Meduza citing RBC and labeled here as a Russian official document.
Sovenyr is a personal data project β an aggregation and detection tool, not a commercial product. Counts are our collection, not a census. Reading judgments are flagged as such. β Andrii
Originally published at https://sovenyr.substack.com on October 31, 2026.