Summary
Has it been affected?What if the new version behaves abnormally?using automation to improve efficiency while still verifying results;
PHPatch introduction video.
A Real Security Emergency, and a Story About Responsibility, Speed, and Protection
On October 21, 2026, a security vulnerability called php2shell was publicly disclosed.
To most people, a vulnerability may be nothing more than an unfamiliar technical term in the news. But for anyone running a website, it raises an urgent question: Is my site safe? Has it been affected? And if there really is a risk, how can it be fixed as quickly as possible without bringing the whole site down?
The internet never stops. News sites need to update, businesses need to take orders, communities need to talk. Behind every website are people's work, information, and daily lives. When security fails, it isn't just servers that suffer — it's the people who depend on those services.
It was in just such a moment that the PHPatch team went into action.
Japanese Prime Minister Sanae Takaichi's appeal on X on the evening of October 21. (Screenshot of the X post)
From an Urgent Problem to a Usable Service
The team faced a clear task: help website operators understand risk faster and find practical ways to respond.
At 00:35 Eastern Daylight Time on October 22, 2026, PHPatch.com officially launched.
The PHPatch.com homepage.
From the vulnerability's public disclosure to the service's launch, only 15 hours and 5 minutes had passed.
This is not a miracle that solves every cybersecurity problem, nor a publicity story built on a countdown. It records how a team, under intense time pressure, turned an emergency-response idea into a service that could be visited, used, and further verified.
The first live version offered an HTTPS website and a public scanner, giving website operators a chance to start from a simple question: What risks might my site face?
For professional security teams, this may be only the starting point of a workflow. But for small businesses, independent developers, and site administrators without dedicated security staff, this step can help them see their situation more clearly and know what to do next.
Step 1: Check Our Own Home Base First
Before helping others, the PHPatch team first dealt with its own portal website, mitbbs.ai.
At the time, the site ran PHP 8.3.35 with an Apache mod_php configuration. The team assessed this configuration as higher risk and in need of prompt attention.
Rather than leaving the problem at the discussion stage, the team began building and verifying a patched image, then switched over the running container.
The entire switchover took about 10 seconds of downtime.
After service was restored, the team checked the site's homepage and key services, confirming that pages loaded normally. Based on the checks performed at the time, the pre-patch logs showed no clear signs of intrusion.
That does not amount to absolute proof that the site was never breached. Security work must distinguish verified facts from what cannot yet be determined. But it does show that the team took real action on its own systems and recorded what it checked.
This step had special significance.
Because a security product should not only tell others what to do. It should also stand up to the same scrutiny itself.
Verify on your own systems first, then turn that experience into methods others can use.
That became an important principle of PHPatch's emergency operation.
Step 2: Not Just Fast, but as Safe as Possible
Fixing a website is not simply a matter of installing a patch.
What if the update leaves the site unable to start? What if the new version behaves abnormally? And if the operator is not familiar with servers, how can the risk of mistakes be reduced?
PHPatch's first service was designed around four steps:
Scan, Patch, Verify, Report.
Scanning identifies potential risks.
Patching takes appropriate action, rather than blindly modifying the system.
Verification checks that the updated service still runs normally.
Reporting leaves a record, so site owners know what was done, what was checked, and what still needs attention.
In this workflow, security controls are not decorative additions after the fact. Dry-run by default, explicit authorization, backups before changes, pre-update checks, service health checks, and automatic rollback when a health check fails are all important parts of the product's design.
For older PHP versions no longer maintained, the tool should not pretend the problem has been fully solved. It needs to state the limits of its own capabilities clearly and, where applicable, offer risk-reduction advice.
Because a truly responsible security tool must tell users not only what it can do, but also clearly state what it cannot determine.
Step 3: When Uncertain, Say So Honestly
Imagine a site administrator opening a security scan page, hoping to learn quickly whether they are affected.
If the system answers "safe" when it actually cannot even identify the site's PHP version, that answer is not only unhelpful — it may lull people into a false sense of security.
That is why, when a proxy server or other network configuration hides the necessary information so that an external scanner cannot reliably judge, PHPatch returns a result of Indeterminate — Unable to Determine, rather than guessing.
That may seem less reassuring than a definite answer, but it reflects an important principle of security work: without sufficient evidence, one should not manufacture certainty.
For ordinary site owners, this means a scan result should be more than a striking color or a simple "pass" or "fail." It should also help users understand what the result means, and when further checks are needed.
Real security is not about making people feel that everything is fine. It is about helping people understand problems more accurately.
Step 4: Leave a Record of Every Step
Many websites have no dedicated security department.
The person managing a server may also handle development, content updates, customer support, and even the company's day-to-day operations. What they need is not just technical jargon and warnings, but a work path they can understand, execute, and check afterward.
PHPatch aims to make this process clearer: identify potential risks, conduct deeper checks with authorization, take appropriate patching or mitigation measures, verify results, and produce a work report.
The value of that report is that security work stops being just a claim that "it should be fixed by now."
It helps site owners understand what measures were taken, what verification results were obtained, and what work remains.
The launch version also established basic trust mechanisms, including HTTPS, secure response headers, a security.txt contact entry, and a security information page describing access permissions and the vulnerability disclosure policy. The site also states clearly that PHPatch is not affiliated with the PHP Group.
The team also plans to open-source the external scanner under the MIT license, while keeping deeper inspection, patching, rollback, and reporting capabilities as proprietary products.
Together, these arrangements point to a single goal: a security service that can not only be used, but also understood, examined, and continuously improved.
After the 15 Hours, the Story Did Not End
15 hours and 5 minutes is a clear record of time.
But cybersecurity is never a race that ends once something launches.
Different websites use different servers, software versions, and operating environments. Some problems can be handled through automated processes, some require administrator intervention, and others must be investigated more deeply before conclusions can be drawn.
PHPatch launching its service did not mean every website could be automatically fixed.
What this operation truly demonstrated was a different way of working: responding quickly in an emergency without giving up verification; using automation to improve efficiency while still verifying results; reducing operational risk as much as possible while honestly stating the tool's capabilities and limitations.
From its own production website, to the public scanner launch, to building a product workflow around patching, verification, and reporting, PHPatch took its first step in those 15 hours.
Much work remains. Security capabilities need continuous testing, the product needs continuous improvement, and real problems users encounter need to be taken seriously.
Because real protection is not a promise made at a launch event. It is a willingness to face every problem seriously, each time one appears.
Why Did We Build PHPatch?
Because behind every website, there are people relying on it.
It might be a small business in operation, an independent developer, a forum serving a community, or a group of people who get information through websites every day.
When security problems arise, they may not know where to begin, and they may not have enough resources to solve them alone.
What PHPatch hopes to do is help them see risks earlier, act in a more organized way, and be able to check the results of their actions.
We believe security tools should not serve only enterprises with large technical teams. More websites should have the opportunity to receive clear, practical, and responsible security support.
In the AI era, cybersecurity cannot wait. Every step of protection should stand up to verification.
That is the story recorded by this PHPatch emergency operation.
At 00:35 Eastern Daylight Time on October 22, 2026, PHPatch.com and the first PHP Patch Assurance officially launched.
Only 15 hours and 5 minutes had passed since the php2shell vulnerability was publicly disclosed.
PHPatch — When CyberSecurity Can't Wait.
In the AI era, cybersecurity is urgent — there is no time to lose!
Around the time of the disclosure, OpenAI also released the open-source tool php2shell-checker, to help website operators judge whether the PHP version their site or server runs might be affected. Its method is to check visible PHP version information, rather than sending exploit requests. But version checks have their limits: they cannot confirm on version number alone that a system has been fully fixed; and when version information is hidden or unrecognized, the tool honestly returns "Unable to Determine" (UNKNOWN).
This context makes the PHPatch launch story all the more meaningful. With risk closing in, different teams were all working to help websites identify risk faster and take protective action: OpenAI provided a checking tool, while PHPatch focused on the complete emergency workflow — from risk identification to patching, verification, and reporting. Tools can help uncover problems, but real protection still requires reliable patching, verification, and sustained follow-up.
