2026-10-30 Takeshi Kashihara

Why did information get out before the fix? Looking back at how php2shell unfolded

Hi, I'm Takeshi Kashihara ("Kassy") at exc-D inc., the company behind Dixlase.

In an earlier post, I covered what we ask of everyone running Dixlase in response to the PHP vulnerabilities known as php2shell.
In "Which layer did the vulnerability occur in?", I explained that this problem occurred in the layer of PHP itself.

This post looks at another side of it.
With php2shell, part of the information got out before the fixes were released. Why did that happen?

What made the commotion so big wasn't only how severe the vulnerabilities were. More than that, I believe information that couldn't be verified circulating ahead of the fixes added fuel to it.
Releasing fixes quickly and updating right away matter, of course. Just as important, I think, is looking back at why information got out before the fixes, and checking what happened.

Let me say up front that this post isn't meant to blame anyone.
I won't name the companies or people involved, and I'll write from published information and news reports, with sources.
Where the parties' accounts differ, I'll present both. Where I give my own view, I'll make that clear.

This post is based on information available as of October 30, 2026. If more comes to light, I'll add it.

How it's supposed to work: why fixes are kept quiet until release

Software vulnerabilities aren't announced the moment they're found.
The usual order is to prepare a fix, hand it to the people who distribute the software first, and then publish everything at once at a set date and time.

If the details get out early, attackers get clues before defenders are able to update.

PHP, too, asks people who report issues not to post them in public places (issues, pull requests, or social media). Once a fix is ready, it publishes an announcement and CVEs on a set schedule.
This time as well, the fixes had been handed in advance to Linux distributions and long-term support providers.

This time, though, several factors overlapped, and part of the information got out before the fixes were released.
In the sections that follow, I'll look back at how that happened, based on what's known so far.

Sources: PHP Foundation, "How the PHP Security Team Handles Your Reports" (October 14, 2026) / PHP security advisory

What happened

On October 21, the day it released the fixes, the PHP Foundation published a look back at what happened.
Based on that and on news reports, here's what happened, in order (times in UTC).

August 11: A researcher's company and one other organization separately reported problems with the same root cause, on the same day.
August 24: Another researcher's company also reported it.
October 17: Amazon observed exploit attempts before public disclosure. How the attackers got the information is unknown.
October 20, around 15:00: The two CVE IDs began circulating on forums and social media, along with an incorrect disclosure date and severity. No technical details were included.
October 20, 19:30: PHP pre-announced a security release for October 21 at 14:00, covering two vulnerabilities each rated 9.2. It said it might release earlier if details became public or if there was evidence of exploitation.
October 20, around 20:00: The researcher's company that had reported the issue published a proof-of-concept video by mistake. The video was taken down, but copies spread.
October 20, around 23:00: Interim mitigations shared with critical infrastructure operators may have leaked.
October 21, 7:41: One of the distributors that had received the fixes in advance published images containing the fixes more than six hours before the coordinated release.
October 21, around 14:00: PHP released the fixed versions, one day earlier than originally planned.

According to the PHP Foundation, no working exploit code had been confirmed at the time of release.

Later, on October 23, PHP disclosed a third vulnerability (CVE-2026-115560). It only occurs with an unusual combination of settings, and the fix will come in the next regular release. Until then, PHP recommends disabling session.upload_progress.enabled.

Sources (third vulnerability): The Register (October 23, 2026) / BleepingComputer (October 23, 2026)

Sources: PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security" (October 21, 2026) / PHP Foundation Discourse, "Upcoming Critical PHP Security Release" (October 20, 2026) / Amazon Threat Intelligence / Infosecurity Magazine / Techzine

Why it couldn't be kept quiet

More than one thing happened.
Here, I'll sort them by how certain we can be.

A clear mistake

In the PHP Foundation's words, the proof-of-concept video was published "by mistake."
The PHP Foundation says the video revealed some new clues, though limited, and sped up the development of exploit code.

Source: PHP Foundation

Where accounts differ

About the distributor that published images containing the fixes early, the PHP Foundation says it unilaterally broke the agreement. Its point is that this made the fixes available to analyze in binary form while other users were still waiting.

The company's CEO, on the other hand, denied leaking anything in interviews with the press.
According to his account, a researcher told him on October 16 that "something is coming for PHP," the company found the same vulnerability with its own AI system that night, received a full briefing on October 17, and then worked with PHP developers to test the fixes.
He gave three reasons for releasing early: how easily the company had found and exploited the bug, how much information was already circulating, and signs of exploitation. He also said, "We're not always going to get it right, and not everyone is going to agree with our decisions."

In response, the PHP Foundation's executive director said there was no evidence of successful exploitation before disclosure.

There seems to be no dispute about the time the images were published. I won't judge here which account is correct.

Sources: PHP Foundation / Techzine / The New Stack (October 22, 2026) / The Register (October 23, 2026)

What has partly come to light

The person who posted the CVE IDs and the planned disclosure date on October 20 later came forward on the same forum and apologized.

According to their own account, they didn't know an embargo (an agreement to hold information until release) was in place when they posted, and had been told by an acquaintance that "there's no embargo." That acquaintance had heard the same thing from someone else.
They say they posted because they wanted to let people in the same position, those who build PHP from source, know that the update was urgent.
They acknowledged that they affected the disclosure schedule and said the responsibility was theirs.

Source: The person's own post on Hacker News

What we don't know the source of

The following things aren't known:

Where the information that "there's no embargo" originally came from
Whether the interim mitigations actually leaked
How the people behind the October 17 exploit attempts got their information

Neither the PHP Foundation nor Amazon has identified these sources.
I'll leave what isn't known as unknown.

Sources: PHP Foundation / Amazon Threat Intelligence

What lay underneath

I think this is the heaviest part of the PHP Foundation's look back.

Signs of one of the causes had already been found during an external audit in 2024.
But several proposals for fixing it came up, each with its own problems, and partly because decisions required everyone's agreement, the work stalled for months.

The PHP Foundation calls this a "structural failure." It names both the way decisions were made and a shortage of people and funding as causes.

Sources: PHP Foundation / The Next Web

What made the commotion bigger

The information that circulated first made things look worse than they were.
The severity was given as the maximum, 10.0 (PHP rates it 9.2), the disclosure date was wrong, and it was said to affect versions all the way back to PHP 5.

About four and a half hours passed between the IDs starting to circulate and PHP's pre-announcement. During that time, there was no way to check whether the circulating information was true.
The pre-announcement officially confirmed that serious vulnerabilities existed. But it gave no details or interim mitigations, only a call to "prepare now so you can update as soon as it is available."
For more than 18 more hours, until the fixes came out, many people who use PHP didn't know what to do. On top of that came the proof-of-concept video.

Sources: Infosecurity Magazine / PHP Foundation / PHP Foundation Discourse, "Upcoming Critical PHP Security Release" (October 20, 2026)

Beyond the severity of the vulnerabilities themselves, information that couldn't be verified until PHP's security team announced it circulated ahead of the fixes. That there were serious vulnerabilities turned out to be true, but parts of it, such as the severity and the disclosure date, were inaccurate. I believe that's what made the commotion bigger.

My view

Looking at it all together, I don't think this came from one person's mistake.
I think human mistakes and judgment calls overlapped with weaknesses in the structure that let the fix stall for so long.

AI has made secrets harder to keep

This is the part that gave me the most to think about.

Problems with the same root cause were reported separately by several organizations that were using AI in their research.
The distributor that published images early also says it found the same problem with its own AI system.
And Amazon points out that AI-assisted analysis is making it faster and cheaper to turn a fix into an attack.

Sources: PHP Foundation / Techzine / Amazon Threat Intelligence

From here on, this is my view.
The more people know about the same problem, the harder it is to keep it secret until a fix is out. And the longer a fix takes, the longer that secret has to be kept.
Now that more people find vulnerabilities with AI, I think the very practice of "keeping things quiet until the fix" is under more strain than before.

This time, the information itself passed from person to person, but the understanding that it "should still be kept quiet" didn't travel with it. As more people know a secret, it also gets harder to make sure that understanding reaches all of them.

Node.js on the same day

On the same day, October 21, Node.js, a JavaScript runtime, also released security fixes.

By October 19, Node.js had announced, without details, that it would ship security releases on October 21 and that the highest severity was HIGH.
Then, as planned, it released 22.23.4, 24.22.1, and 26.12.1.
One of the 10 fixed issues (remote code execution in Brotli handling) was found by a security team that uses AI.

Node.js's official announcement says nothing about leaked information or actual attacks. Within what I could find, I saw no reports of a leak either.

Sources: Node.js, "Wednesday, October 21, 2026 Security Releases" / Private DevOps

Compared with PHP's case, the Node.js release seems to have gone quietly. Here are some differences:

How widely it's used: According to W3Techs, among websites whose server-side language is known, PHP is used by 69.3% and JavaScript by 8.1%. Among the top 1,000 sites by traffic, though, JavaScript rises to 31.8% (PHP is 59.2%). These figures are about websites only and don't include uses outside websites, such as APIs and developer tools.
How broad the vulnerabilities were: PHP's two vulnerabilities affected every PHP installation that handles web requests. Node.js's 10 were each tied to specific features, such as DNS resolution, TLS certificate verification, and Brotli decompression.
How the release went: Both projects put out pre-announcements without details. But PHP's came after the CVE IDs had already started circulating. Node.js went from its announcement to a release on schedule, and I saw no reports of information getting out early.

Sources: W3Techs, "Usage statistics of server-side programming languages" (as of October 22, 2026) / Node.js, "Wednesday, October 21, 2026 Security Releases"

I haven't found a source that measures how much each of these mattered. In my view, the difference in scale and in how broad the impact was, combined with following the process through to release, is what made it a quiet release.

This isn't about which one is better. The severity of the vulnerabilities and the number of organizations involved were different.
Still, I want to remember it as an example of vulnerabilities found with AI that went from announcement to release by the book.

What the PHP Foundation is doing

In its look back, the PHP Foundation lists improvements such as these:

It created an ecosystem security team in May 2026
Security decisions will be made by majority vote rather than requiring everyone's agreement
It will add more developers
It's asking companies, hosting providers, governments, and others that depend on PHP to help with funding

Source: PHP Foundation

I think publishing what went wrong, in its own words as a "structural failure," is an important step.

What this means for Dixlase

Dixlase runs on PHP. What we could do this time was tell people quickly what to do, and fix our installers so they're easier to update. The details are in our earlier post, "The PHP vulnerabilities (php2shell): how Dixlase is responding."

The PHP vulnerabilities (php2shell): how Dixlase is responding

This has left me thinking about two things.

One is that information won't always come out on schedule.
That's exactly why it matters for users to have a way to update as soon as fixes are out. We'll keep building that into Dixlase.

The other is that Dixlase, too, is on the receiving end of vulnerability reports.
[To confirm: one line on where to report vulnerabilities in Dixlase (SECURITY.md, etc.) and how reports are handled]
Whatever the scale, the work from receiving a report to deciding, fixing, and telling people can't be allowed to stall. This look back isn't someone else's problem for us either.

Closing thoughts

I don't think information getting out before the fixes is something that ends with blaming one person.
The big commotion may also have pushed many people to update sooner. But that speed was also made possible by the people who prepared the fixes before disclosure and handed them to distributors.
With AI, both finding vulnerabilities and building attacks are getting faster. I believe those who receive reports, those who distribute software, and those who use it all need to build, together, systems that make this less likely to happen again.