The PHP flaw had been known for two years. AI found the key in one summer.

This weekend, I checked which version of PHP runs the form on my website.

Paranoid? Maybe. But on Wednesday 21 October, at the request of ANSSI, the French cybersecurity agency, the French Ministry of the Interior took its exposed websites offline, including the prefectures’ sites.

What happened

On 21 October 2026, PHP released fixes for two critical flaws, and CERT-FR published alert CERTFR-2026-ALE-014 the same day. Both flaws allow code to be executed remotely on a server, without authentication. In plain terms, an outsider can take control.

PHP is everywhere. It runs most WordPress sites, plenty of client portals and internal tools built ten years ago. According to ANSSI, more than 600,000 servers run it on the French internet alone.

The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Every older branch, from 5.x to 8.1.x, gets no fix at all: they are no longer maintained. CERT-FR recommends isolating affected servers, then moving to a maintained version.

Why AI changes the picture

What struck me was not the flaw. It was the timeline.

According to ActuIA, the defect behind one of the two flaws had been reported as early as 2024, during an audit. Back then, nobody knew how to exploit it. It stayed that way for two years: known, but with no demonstrated danger.

This summer, several teams went back to it. A remote code execution was reported on 11 August. Wiz Research, which brought further attack paths in late August, says it worked with AI models from Google and OpenAI, and claims a single researcher did in one week what an expert team would have needed months for. That is Wiz’s claim and I take it as such. But the direction is clear.

AI also speeds up the people looking for your weaknesses. The gap between “a defect is known” and “an attack is possible” is shrinking. An old version that had been sleeping quietly can become an open door in one summer.

The risk is not knowing what runs

On my own site, the only code that runs server-side is a PHP form. At the top of the file, I wrote a comment: “written for PHP 7.4 and above”. It was a compatibility choice. PHP 7.4 is one of the versions that will never get a fix.

The flaw is not in my code, it is in PHP. What matters is not the version the code was written for, it is the version that runs it. And that comment says something simple: even on a small website, you can lose track of what actually runs.

In a small or mid-sized company, it is rarely one form. It is the marketing site rebuilt in 2019, the client portal from a contractor who left long ago, the little quoting tool an intern wrote, the WordPress site from the 2022 event that was never switched off. Nobody is hiding anything. Nobody knows, that is all.

My position: a company that cannot list its internet-facing servers in ten minutes is not ready to connect an AI agent to its systems. An agent that reads your databases and writes into your tools adds exposure. You do not add it on ground you have not mapped.

Three steps, this week

1. List. Everything reachable from the internet: websites, portals, forms, internal tools open to the outside. For each one, who is responsible.
2. Ask. The PHP version of each one, from the host or the contractor. With most shared hosting providers, you can read it or change it in the customer area in a few clicks.
3. Isolate. Anything running on an unsupported version that cannot move right away: switch it off or put it behind a web application firewall until it is migrated, as CERT-FR recommends.

This is not an AI project. It is a mapping exercise. It is the same one you do before automating a process: know what exists before deciding what to change.

The lesson

Before you automate, you map. Including what runs.