Independent Reporting · Not Legal or Security Advice · Verify With the Breached Company · Editorial Policy

PHP2Shell Leak Timeline: From Leaked CVE IDs to Chainguard at 07:41 UTC

The fixes for PHP2Shell were supposed to come out at 14:00 UTC on Thursday, October 22. Instead, a chain of slips that started on the afternoon of Tuesday, October 20 pushed the release a day earlier and left one vendor accused of breaking the embargo. This account of the PHP2Shell leak follows the PHP Foundation’s own timeline, with the other side’s response from Chainguard alongside. In disclosure terms, an embargo is the agreement to keep a bug quiet until a set release time so that everyone gets the patch at once.

Where it stands: PHP shipped its fixed releases on Oct. 21. In a post the same day, the PHP Foundation blamed Chainguard for publishing fixed images early; Chainguard’s CEO, Dan Lorenc, told The Register on Wednesday that he does not dispute the timeline but that his company “didn’t leak.”

The PHP2Shell leak, hour by hour

The times below come from the cited sources and are in UTC. The Eastern Time column is our conversion (EDT, UTC minus four hours).

UTC (ET) What happened Source
Oct. 20, ~15:00 (~11:00 a.m.) CVE IDs surface on forums and social media; the time and score attached are both wrong PHP Foundation
Oct. 20, 19:30 (3:30 p.m.) PHP publishes its pre-announcement early; release moved to Oct. 21, 14:00 UTC PHP Foundation
Oct. 20, 19:35 (3:35 p.m.) watchTowr publishes its PHP2Shell FAQ watchTowr
Oct. 20, ~20:00 (~4:00 p.m.) Calif mistakenly publishes a video PHP Foundation
Oct. 20, ~23:00 (~7:00 p.m.) Mitigation advice given to some infrastructure providers may have leaked PHP Foundation
Oct. 21, 02:29 (Oct. 20, 10:29 p.m.) An archive tied to a write-up is first submitted to VirusTotal VirusTotal
Oct. 21, 03:02 (Oct. 20, 11:02 p.m.) Cloudflare’s WAF protection on by default Cloudflare
Oct. 21, 07:41 (3:41 a.m.) Fixed Chainguard images go public ahead of the embargo PHP Foundation
Oct. 21, 14:00 (10:00 a.m.) Coordinated release, as rescheduled PHP.net

How did the PHP2Shell CVE IDs get out early?

The first crack was the identifiers, not the bug itself. The PHP Foundation says the two CVE IDs “began circulating on online forums and social media” at around 15:00 UTC on Oct. 20. A CVE ID is the public tracking number assigned to a vulnerability; on its own it says nothing about how the bug works.

The leaked version was wrong in two ways. The Foundation says it carried “a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2)”, and adds that no technical details leaked at that stage. Infosecurity Magazine reported that the original post, since deleted, claimed two maximum-severity flaws would be disclosed on Oct. 22.

That was enough to start the clock. With the IDs public, PHP brought its pre-announcement forward to 19:30 UTC and moved the release from Oct. 22 to Oct. 21, keeping the 14:00 UTC slot. The php.net notice reads: “It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC.”

The video posted by mistake

That same evening (the Foundation’s wording places it around 20:00 UTC), Calif, one of the firms that had reported the bugs, published a video. The PHP Foundation describes this as a mistake, and says it “contributed to accelerated development of various PoCs”, the proof-of-concept exploits that then spread on Oct. 21.

Calif had been working on PHP since the summer. The PHP Foundation says Calif’s researcher Ryan A reported the core issue on Aug. 11, so the video landed after weeks of private work.

The Foundation adds one more possible gap: mitigation advice it had begun sharing with a few critical infrastructure providers around 23:00 UTC on Oct. 20 “may have leaked as well.” It does not say how.

The speed of what followed is visible in other data. AhnLab’s ASEC team found that nearly all of the top 100 “php2shell” repositories on GitHub were created on Oct. 21. VirusTotal says an archive referenced in one write-up was first submitted at 02:29 UTC that day.

Chainguard’s early release: what PHP says

The sharpest charge is aimed at Chainguard, which The Register describes as a supply chain security business. Linux distributions and long-term-support vendors received the PHP patches in advance so their packages would be ready at release time, and the PHP Foundation counts Chainguard among the distributors given that early access.

The PHP Foundation says that at 07:41 UTC on Oct. 21, “more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix.” Its objection is practical: “Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release.” The Foundation adds that this “disregarded weeks of work by many parties toward a coordinated disclosure.”

Chainguard’s side of the PHP2Shell leak story

Lorenc’s reply, as reported by The Register, is that the embargo had already failed. He told the outlet “It’s coordinated vulnerability disclosure, unless there’s evidence of active exploits in the wild,” and said “People were getting hit in advance” of PHP’s disclosure, “so we made the call to ship the fixes under that.” Asked whether he would act differently, he said no.

He also offered an account that is hard to check. According to The Register, Chainguard heard “something was coming in PHP” the previous Friday from one of the researchers involved, and later Lorenc’s team used an AI harness and a frontier model to independently find the same memory corruption bugs. In a LinkedIn post quoted by The Register, he said it took a “basic prompt” to do it.

That claim is Lorenc’s. PHP’s own experience with AI-generated reports is less flattering: in an Oct. 14 post, the security team wrote that AI has left reports “much cheaper to write”, and it reported closing 106 reports that were not vulnerabilities, were duplicates or did not reproduce.

What the early disclosure changed for defenders

The compressed schedule cut both ways. Cloudflare says its WAF rules were deployed about 9 hours ahead of public disclosure and switched on by default from 03:02 UTC on Oct. 21. Most site owners, though, had nothing to install until PHP’s own release went out. Our PHP2Shell guide for WordPress and hosting covers the fix itself.

Did the leak lead to real attacks? Firms report attempts, and Lorenc says people “were getting hit”, but PHP’s own reviewers say none of the leaked demonstration code they examined actually worked by release time. We compare every claim in is PHP2Shell being exploited, and the rest of that Wednesday is in our October 21 timeline.

PHP’s own timeline puts the first leak of the CVE IDs at about 15:00 UTC on Oct. 20, and Chainguard’s images at 07:41 UTC the next morning.

Frequently Asked Questions

How did PHP2Shell leak?

The PHP Foundation dates the first leak to about 15:00 UTC on October 20, when the CVE identifiers showed up online attached to an incorrect date and an inflated 10.0 severity score. PHP says no technical details leaked at that stage. A video posted by mistake that evening, and possibly some mitigation advice, followed.

Did Chainguard leak PHP2Shell?

PHP says Chainguard broke the embargo by publishing fixed images at 07:41 UTC on October 21, more than six hours before the coordinated release. Chainguard CEO Dan Lorenc told The Register he does not dispute the timeline but that his company did not leak, arguing that evidence of attacks justified shipping the fixes.

What is a security embargo?

An embargo is an agreement among the people who know about an unfixed bug to keep it private until a set release time, so every user gets the patch at once. Distributors such as Linux vendors often receive fixes early under an embargo so they can package them in advance.

Why did PHP release the fix a day early?

Once the CVE IDs were circulating, the PHP project published its pre-announcement early and moved the release from October 22 at 14:00 UTC to October 21 at 14:00 UTC, according to the PHP Foundation.

Is the leaked PHP2Shell exploit code real?

PHP’s security team reviewed the demonstration code that surfaced after the leak and, by its account, none of it was a working exploit when the patches shipped. Other firms have made different claims, which we compare in our explainer on whether PHP2Shell is being exploited.

Sources


This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.

Owed money from a settlement? Check what is open at OpenClassActions.com. Caring for someone with dementia? Find practical guides at HelpDementia.com. Working out a skin routine? Evidence-based answers at AcneAdvocate.com. Forgot the name of a movie? Identify it at FindThisMovie.com.

We use cookies to run this site, measure how it’s used, and show ads. Choose “Essentials only” to limit cookies to what the site needs to work. Privacy Policy. Cookie Policy.