Blog
Our site is all static HTML, so the PHP vulnerability does not concern us. That is what you want to conclude. Then you remember the contact form.
Our site is all static HTML, so the PHP vulnerability does not concern us. That is what you want to conclude. Then you remember the contact form, and the conclusion falls apart.
On 21 October 2026 two vulnerabilities were disclosed in PHP that allow an unauthenticated attacker to execute code on the server (CVE-2026-109618 and CVE-2026-109619, scored 9.2 out of 10). Fixed releases — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — came out the same day.
What makes these two awkward is where they trigger: upstream of your application code. It does not matter how carefully your PHP is written. The condition is met at the point where PHP accepts an incoming request and begins processing it.
So "there are no holes in my code" is not a defence here. The fact that PHP is running is enough.
Picture a common setup. Every page is static HTML, and the only PHP on the server sends the contact form by email. Add a document-request form and that is two. If an address lookup or an email-validation script survived from an older version of the site, you are at four or five.
Now the property above starts to bite. It does not matter what those scripts do. PHP files sit in a directory that is served, and the server is configured to execute them — that is the whole condition.
There is a second problem: PHP files that nothing calls any more tend to stay. You rebuild the site and forget to delete the old handler. A feature gets dropped but its script remains. Nobody notices, because nothing uses it. It is still reachable from outside if it sits in a served directory.
One form, and the entire site becomes "a server running PHP". What you have to defend is not the one file. It is the server.
There are two ways to respond. Update to the fixed release and carry on using PHP, or remove PHP altogether.
Updating is obviously the right thing to do, but it is a relationship built on the assumption that this will happen again. That is not specific to PHP. As long as something executable is exposed, every disclosure creates the same round of work.
We chose to remove it. The only thing PHP did on our corporate site was handle form submissions, so we rebuilt it with the receiving end moved elsewhere and no PHP in any served directory. The forms look and behave exactly as before. The only thing that changes is that the method no longer involves PHP — that is all.
The rebuild itself was done by the AI that works inside our business platform. Reading the original PHP, producing a receiving routine with the same behaviour, writing the tests and running them — that is the AI's part. The human part is to open the result, submit a document request and an email through the form, and check that nothing is broken. That is the part I value most. Knowing you ought to rebuild something is useless if you have no hands to rebuild it with; you end up getting by on the patched release instead. Of course, updating to the patched release is the right answer in plenty of cases. In ours, keeping PHP secure indefinitely for the sake of a contact form alone simply did not add up.
What lets us respond flexibly like this, case by case, is that the business platform itself is our own product, miraiGen.™Cube. The AI runs inside a server on our own premises, so the site content and the rebuilding of the programs themselves live in the same place. I find it genuinely convenient. And this server still has plenty of room to grow alongside the AI.
Once it is gone, the next disclosure of this kind can be dismissed in one line: this does not apply to us. I think being able to reach that conclusion is worth more than the fix itself. The exhausting part of an urgent vulnerability is not the work — it is the investigating, deciding and scheduling.
For a static site, going PHP-free is more often possible than people assume. It is worth counting what you actually have.