PHP2Shell Timeline: The First 60 Hours, in Data

PHP2Shell is the name for two critical flaws in PHP core, CVE-2026-109618 and CVE-2026-109619. Both allow remote code execution. This post covers the first 60 hours: from the PHP advance notice on 20 October 2026 at 19:30 UTC to 23 October at 07:30 UTC. For the technical detail and the fix, read our main PHP2Shell analysis.

We counted what people said and built around the flaws, using Brandefense threat intelligence data, public posts on X, GitHub search and our free PHP check. Counts are lower bounds, and each one says how it was made.

Update 26 October 2026: we added an entry after the window on honeypot records of code execution, and updated the CISA status.

Update 23 October 2026: the window now runs 60 hours. We added what Japan’s Prime Minister posted on X, a correction from Sophos, and two new sections on notable X posts and on what we saw on the dark web.

We also filled gaps in our X collection, so the count for the first 36 hours is now 6,567 posts, not the 4,176 we first reported. Later on 23 October we added what Sophos and Arctic Wolf say about the Potassium malware.

On 23 October, 10:12 UTC, PHP posted an advisory on session upload progress; it is added to the timeline and to the steps below. Palo Alto’s advisory for PAN-OS and Panorama is added to the timeline too; the details are in our post on PHP2Shell across Palo Alto products. Other counts run to 23 October, 07:30 UTC and were read between 07:31 and 07:39 UTC (GitHub read at 07:39 UTC), except the cards marked as first 36 hours.

Free PHP2Shell Vulnerability CheckSee which PHP version your site shows to the outside world and whether it falls in the CVE-2026-109618 and CVE-2026-109619 range. Passive check, no account, no exploit traffic.Check Your Site →

1. 17 Oct 2026Earliest attempt on recordAmazon’s honeypot telemetry shows an exploit attempt four days before disclosure.
2. 20 Oct, about 15:00CVE ids start to circulateThe PHP Foundation says the ids spread with a wrong release time and a wrong score of 10.0, and that no technical details leaked. PHP rates both 9.2 (CVSS v4.0).
3. 20 Oct, 19:30PHP brings the notice forwardThe release is now set for 21 Oct at 14:00 UTC, a day earlier than first planned.
4. 20 Oct, about 20:00A proof-of-concept video leaksThe PHP Foundation says the researchers published it by mistake and deleted it, but copies spread.
5. 21 Oct, 03:02Cloudflare turns on WAF rulesProtections go out to free and paid plans before the patch exists.
6. 21 Oct, 03:59Fastly sees its first PHP2Shell-named toolFastly’s firewall data shows its first request from a tool with PHP2Shell in its name. By the 14:00 UTC release, more than 100 source IPs had used such tools.
7. 21 Oct, 07:41Early patched images appearChainguard publishes images with the fix more than six hours before the coordinated release, says the PHP Foundation.
8. 21 Oct, 11:35Exploitation at scale reportedHadrian says it sees PHP2Shell used in the wild at scale.
9. 21 Oct, 12:55Japan’s Prime Minister urges site owners to prepareA post on her X account, in Japanese, asks owners to check whether their sites use PHP and be ready for the patch at 23:00 Japan time (14:00 UTC). It adds that taking a site offline can reduce risk if patching is hard.
10. 21 Oct, 14:00Patches shipFixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There is no complete mitigation, says PHP.
11. 21 Oct, 16:00Palo Alto publishes its advisoryThe advisory lists PAN-OS and Panorama as affected through the management web interface. By 28 October it says active exploitation has been observed against management interfaces exposed to the internet.
12. 22 Oct, 05:30VulnCheck has a private exploitVulnCheck says it has a weaponized exploit for CVE-2026-109618 that works on x86-64 with ASLR enabled and display_errors off. It is for its customers only, not public. (1:30 AM Eastern Time.)
13. 22 Oct, 06:38Japan’s cyber office points to the IPA alertThe government account for cyber warnings shares the alert that Japan’s IPA published that day. It lists the fixed versions and says PHP 8.1 and older are end of life.
14. 22 Oct, 13:37CrowdStrike says one request is enoughCrowdStrike posts on X about its blog, which says it verified end to end that a single anonymous POST request can make an Apache mod_php worker run a command.

Conversation Peaked Right at the Patch

We collected 12,035 public X posts matching our searches in the window, from 8,920 accounts. Retweets are not counted. Of those, 1,295 came in the two hours after the 14:00 UTC release. Our collection is capped per search in many busy hours on both days, so every count here is a lower bound and the real curve is higher.

Daily totals: 4,553 posts on 21 October, 6,246 on 22 October and 1,232 on 23 October up to 07:30 UTC. In our collection the second day had more posts than the first, but no hour reached the hours right after the patch release.

Brandefense threat intelligence data, which covers Telegram channels, chat groups and forums, tells the same story. It holds 391 posts matching our searches in the window, from 125 sources, 383 of them on Telegram. The busiest two hours were 15:00 to 17:00 UTC on 21 October, with 53 posts. By day: 2 on 20 October after 19:30 UTC, 198 on 21 October, 164 on 22 October and 27 on 23 October up to 07:30 UTC.

Public X posts per six hours (UTC)

1. 20 Oct 19:30 to 24:004.
2. 21 Oct 00:00 to 06:00368.
3. 21 Oct 06:00 to 12:00866.
4. 21 Oct 12:00 to 18:002,078.
5. 21 Oct 18:00 to 24:001,241.
6. 22 Oct 00:00 to 06:001,535.
7. 22 Oct 06:00 to 12:001,728.
8. 22 Oct 12:00 to 18:001,910.
9. 22 Oct 18:00 to 24:001,073.
10. 23 Oct 00:00 to 07:301,232.

The last block is 7.5 hours long. The 21 Oct 18:00 block was thin in our first count; we have since filled it.

What the Posts Were About

Patching was the biggest topic. Of the X posts, 4,706 mention an update or a fixed version, and 1,002 mention a WAF or a mitigation. 259 mention a proof of concept or exploit code, and 594 say exploitation is happening.

1,035 report a service going offline or into maintenance. These are keyword matches, not a reading of each post.

Vendors disagreed on exploitation, and sensors saw different things. Amazon saw attempts from several actors between 02:00 and 08:00 UTC on 21 October. It saw new exploits used against its sensors almost immediately after the 14:00 UTC release. It says PHP2Shell is now broadly exploited in the wild.

Others had not seen it: Cisco Talos reported no exploitation as of 14:00 UTC on 21 October, and Huntress saw none on partner systems at 20:30 UTC. CISA had not seen exploitation when it published. As of 07:30 UTC on 23 October, neither CVE is in its Known Exploited Vulnerabilities list.

The picture moved on 22 October. At 16:18 UTC Sophos said it had seen successful exploitation in customer environments. At 21:21 UTC it corrected that: its customer data shows scanning and a small number of failed attempts, with no evidence of a successful compromise.

Sophos adds that building a working exploit is not straightforward and that attackers seem to struggle too. The payload it blocked was a likely Mirai variant known as Potassium, and it was not delivered. Arctic Wolf also links payloads to Potassium but says its data does not show the PHP2Shell requests downloaded or ran them.

What People Said on X

We read the public X posts in our collection, plus the Prime Minister’s own account, and picked three accounts that add something. Each is the account’s own claim, not our measurement. Counts of likes and views were read on 23 October.

The most-viewed post we found came from Japan’s Prime Minister, Sanae Takaichi. It is written in Japanese without our search terms, so it is not in the counts above.

On 21 October at 12:55 UTC (21:55 in Japan), about an hour before the patches, her account asked website owners to check at once whether they use PHP. It also asked them to prepare for the fix released at 23:00 Japan time. If patching quickly is hard, it asked them to consider taking the site offline for a while.

We translated her Japanese text. It has 95.6 million views and 386,135 likes. The account bio says some posts during her term are written by staff.

Our translation from Japanese of the post: “Temporarily stopping a website is also considered one effective measure to reduce risk”. The card shows one sentence of the post in her original wording. Open the post on X (@takaichi_sanae, Prime Minister of Japan, 21 October 2026, 12:55 UTC).

In a second post on 22 October at 04:00 UTC she said her own website had been taken offline on purpose the day before. It was back after the work was done. She asked site and server managers to follow the government’s cyber alert account. That post has 6.4 million views (her later post on X).

On 23 October at 02:53 UTC the researcher behind the MalwareTech blog took the opposite view of the AI exploit talk. He wrote that many “php2shell exploits” on GitHub and in his honeypot traffic are AI-written code. It does not match the real flaw.

The card shows the first words of one sentence in his post. Open the post on X (@MalwareTechBlog, MalwareTech, security researcher, 23 October 2026, 02:53 UTC).

He says he has not seen anyone get it working on more than a handful of PHP versions, and only with very specific settings. He adds that there is no mass exploitation yet. This is one expert’s view. It fits Sophos’s correction, but Amazon reads its own sensors differently.

The honeypot company Defused had a similar message early on. On 21 October at 18:10 UTC it posted that it had “so far not seen major exploit activity around either vulnerability” (DefusedCyber’s post on X, 18,874 views).

What We Saw on the Dark Web

We searched Brandefense threat intelligence data, which covers Telegram, Discord and forums, for PHP2Shell, both CVE ids and “php rce” in the 60 hours. It holds 391 unique posts from 125 sources: 383 on Telegram, 4 on Discord and 4 on a forum.

Most are news relays, patch notices and trading-signal bots. A few are worth describing. All of this is what the posts claim, and we have not verified any of it.

On the morning of 22 October, a seller in a Telegram channel for webshell trading advertised a tool that exploits both CVEs and uploads a web shell for both CVEs. The price was 150 US dollars, direct messages only.

The same advert, without a price, appeared in another channel about three and a half hours later. A third channel carried a bare line offering the exploit by direct message. We have no proof of a working tool. These look like attempts to resell the public proofs of concept, which is our reading and not a fact.

Demand showed in the questions. On 22 October at 08:14 UTC someone in a large Russian-language cybercrime chat asked whether anyone had a mass exploit. Late that evening a member of another chat asked for “the actual” script.

On 23 October at 04:23 UTC a member of a third chat asked whether any public proof of concept existed yet. The same request for help exploiting it was posted in two other chats. This fits the view that working code is rare, but a few questions are not a measurement.

On 21 October at about 21:30 UTC, a Farsi-language Telegram channel that shares exploits explained how to find exposed servers. The version banner PHP sends by default can be searched in internet-wide scan engines. We do not repeat its search strings.

The four forum posts are an automatic news bot on a Russian-language hacking forum reposting headlines.

Side Stories From the First 36 Hours

The numbers in the next two cards and the wrong-claims note come from the first 36 hours and were not recounted. Treat them as a snapshot.

A fast story attracts opportunists. These are the patterns we saw. We describe them and do not link to any of them.

Wrong Claims at Speed

Two near-identical posts at 13:47 and 13:50 UTC claimed that PHP 8.2 got no fix. PHP.net lists 8.2.35 as fixed.

One post at 05:31 UTC claimed that another team’s honeypots had already caught the exploit. We could not confirm it. The early sighting we checked is the Amazon post above. A later case: Sophos withdrew its report of successful exploitation after about five hours (see the timeline), and MalwareTech says AI-written fake exploits are being posted as real ones.

GitHub Filled Up Within Hours

GitHub search shows about 720 repositories created in the window that mention “php2shell”, 628 with the name in the repository name. 41 had at least 10 stars and 9 had 100 or more. MalwareTech says one with over 100 stars is not PHP2Shell code at all.

VulnCheck says only a very small number of the hundreds of PHP2Shell repositories are legitimate exploits. It found at least one that bypassed ASLR on x86-64 for PHP 8.4.26 only, and says it did not work outside that setup. We did not test it. VulnCheck’s own, more capable exploit is private and available only to its Initial Access Intelligence customers.

Some descriptions warn that the code is AI-generated, untested or a lab fixture. We did not download or run any repository, and we cannot say which ones are safe. Public exploit code is a risk to whoever runs it. Learn more about the terms in our proof of concept entry.

What Our Free PHP Check Saw

Our free PHP vulnerability check recorded its first check on 21 October at 09:33 UTC. By 07:30 UTC on 23 October, visitors had run 30,345 checks. They came from 8,493 distinct IP addresses and covered 22,637 distinct sites (each different address entered counts once). That is 3,342 checks on 21 October, 23,969 on 22 October and 3,034 on 23 October up to that time.

The busiest hour was 08:00 to 09:00 UTC on 22 October, with 2,078 checks. Known Google and Bing crawler addresses are excluded. No domains or addresses are kept in this post.

The bar shows the last verdict for each site.

How People Used the Check

Almost half of the IP addresses (4,193 of 8,493) checked more than one site, and most did it quickly. On average each address ran 3.6 checks (median 2). For addresses with more than one check, the median time from the first check to the last was under 2 minutes. The median pause between two checks in a row was 24 seconds.

4,617 sites were checked more than once, usually straight away: the median gap between a site’s first and second check was 47 seconds.

78 sites moved from vulnerable to patched between two checks. The median time from the first vulnerable result to the patched result was about 2 hours 33 minutes. The fastest change was seen within a minute, the slowest after about 28 hours.

Most checks came from search engines: Google (13,669 checks), Bing (2,310), DuckDuckGo (2,062) and Brave Search (591). Another 2,436 checks came from links on brandefense.io, 1,095 from links opened in Microsoft Teams, 100 from Gemini and 13 from Claude. 7,760 checks had no referrer.

The next bar splits the 1,486 sites on a vulnerable version at their last check by PHP line.

Read these numbers with care. A check reads only what the server shows. “Version hidden” does not mean safe. Some Linux distributions fix PHP without changing the version number the server shows, so a site counted as vulnerable may already be fixed.

These are checks run by visitors, not a scan of the internet. The sites people choose to check are not a random sample. In the first 36 hours (to 07:30 UTC on 22 October), the check ran 8,301 times on 6,430 sites. Of 658 sites with a readable version, 463 (70%) were vulnerable at their last check.

In the 24 hours after, it ran 22,044 times on 16,514 sites. Of 1,764 sites with a readable version, 1,091 (62%) were vulnerable at their last check in that period.

What to Do Now

• Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Restart PHP-FPM or the web server after. See patch management.
• PHP 8.1 and older get no new release. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship fixes. If you cannot update, take PHP systems offline until they are patched, as CISA advises.
• Set session.upload_progress.enabled=0 until the next regular PHP bugfix release, as PHP suggested on 23 October for CVE-2026-115560. PHP says applications that never change the session serialize handler at runtime can keep it on. Our post on CVE-2026-115560 lists the conditions.
• Check for web shells and for web server processes that start a shell, because attempts began before the fix existed. Fastly‘s firewall data shows its first PHP2Shell-named tool at 03:59 UTC on 21 October, about ten hours before the release. A researcher’s honeypot report of 24 October shows Apache workers starting shells right after exploit requests.
• Prove the fix is running, not only installed. Our PHP2Shell defense guide lists four pieces of evidence to check.
• Do not run exploit code from a repository you cannot verify.
• Map where PHP runs on your internet-facing systems with external attack surface management. Our free PHP vulnerability check gives a quick first view.

Watching criminal chatter helps you see what is coming, and prioritizing new CVEs with vulnerability intelligence shows which ones touch your own software. Our dark web monitoring and cyber threat intelligence work follow stories like this one as they form. The same pattern appeared in the WP2Shell WordPress flaw.

Drupal owners have a second update to make, because Drupal’s separate core bug in Field UI is not part of PHP2Shell. Exploiting public-facing software maps to T1190.

How We Counted

The window is 60 hours from the PHP advance notice. Counts are posts matching our searches, with duplicates removed by post id. Some matches are about the PHP release in general.

• On X: “php2shell”, the two CVE ids, “php 8.5.12”, “php rce exploit” and “PHP_SESSION_UPLOAD_PROGRESS”.
• In Brandefense threat intelligence data: “php2shell”, the two CVE ids and “php rce”.

The “What the Posts Were About” counts are keyword matches on the X post text. After we first published, we filled gaps in our X collection, so earlier published counts for the same hours rise.

GitHub counts are repositories created in the window from public search, which excludes forks. All counts were read on the morning of 23 October 2026 and will grow. They show scale and timing, not the number of victims.

PHP check numbers come from our free check’s logs, from its first check on 21 October to 07:30 UTC on 23 October. The first 36 hours and the 24 hours after are shown separately. For each site we use its last verdict.

Pauses between checks longer than an hour are left out of the pause figure. Referrers are the page a visitor came from, as the browser reported it. Likes and views of the featured X posts were read on 23 October.