On the afternoon of 21 October, French users trying to reach their prefecture's website found a maintenance page instead, and the CNIL and impots.gouv.fr showed similar messages. None of these sites had been reported as breached. The Interior Ministry had taken its exposed sites offline as a precaution, because two flaws in PHP, the language behind about 70% of websites whose server-side language is known, could let an attacker take control of a server without logging in. The severity alone would have made it a hard week for IT teams. What made it unusual was how the flaws were found, how fast the details leaked, and how quickly attackers followed.

What happened

On 20 October, the PHP project announced a security release for the next day at 14:00 UTC. Details leaked the same day, including a proof-of-concept video published by mistake. The advisories went out on 21 October at 13:34 UTC, slightly ahead of schedule, with fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Branches 8.1 and older are no longer supported, so they get no official fix.

CERT-FR, ANSSI's operational arm, published alert CERTFR-2026-ALE-014 the same day and has updated it several times since. Its advice is clear: only the update fully protects. Temporary workarounds reduce exposure, and systems on unsupported versions should be isolated and then migrated. The Interior Ministry's shutdown came at ANSSI's request. Universities, local authorities and several public agencies took similar steps, and Cybermalveillance.gouv.fr published an alert for organizations of every size.

Attackers didn't wait long. CERT-FR now reports exploitation attempts, and on 26 October the US Cybersecurity and Infrastructure Security Agency (CISA) confirmed active exploitation and gave federal agencies three days to patch.

How AI changed the story

The underlying defect wasn't new. It had been flagged during an audit in 2024 and left unfixed, because nobody had shown a practical way to exploit it. The PHP Foundation has since described the delay as a structural failure.

This year, AI-assisted research closed that gap. A researcher at Calif found a working attack path using GPT-5.6 Sol as part of OpenAI's Patch the Planet initiative, and Wiz found both flaws independently with several AI models and its own tooling. OpenAI says that, to its knowledge, "frontier AI found these vulnerabilities before attackers did." The picture is less tidy than that: Amazon reported an exploitation attempt four days before the disclosure.

Three shifts stand out.

• Old bugs become exploitable. Defects judged harmless for years can turn critical once AI tools test them at scale. OpenAI says it expects similar findings "to increase sharply in the coming months."

• Disclosure gets harder to control. The leak, the accidental proof of concept and early attack traffic shrank the window between announcement and exploitation to hours.

• Attackers use the same tools. One campaign described by the research firm Dream combined PHP2Shell with a Linux flaw to compromise 25 firewall servers in the US and Asia, using a custom exploit and AI-assisted tooling, as reported by The Hacker News.

Finding flaws is getting faster. Fixing them still depends on people. As Biswajeet Mahapatra, principal analyst at Forrester, told CSO Online, the reliance on scarce expertise "moves to triage, exploitability judgment, patch safety, disclosure timing, and production rollout."

What this means for your organization

Know where PHP runs

PHP doesn't only run on your own web servers. It ships inside control panels, vendor appliances and products your teams may not think of as PHP at all, and on servers your hosting provider manages. CERT-FR points to a list of potentially affected products maintained by the Dutch NCSC. An asset inventory that includes components, not just systems, is what lets you answer "are we affected?" quickly.

Plan for patching in hours

An emergency change process works best when it's agreed before the emergency. Decide who can apply an out-of-cycle patch, who can take a service offline, as ANSSI recommended, and which compensating measures you accept while you wait. Treat web application firewall rules and configuration changes as a way to buy time, not as the fix.

Expect supplier questions in both directions

Within a day, customers, including ours, were sending questionnaires to their suppliers: are you affected, when did you patch, and can you show there was no exploitation? Prepare a factual answer you can reuse, with a timeline and the checks you ran. Ask the same of your critical suppliers, and record their answers. Under NIS2, supply chain security is part of the risk-management measures, and DORA expects the same scrutiny of ICT third-party providers.

Check your reporting duties

A patched vulnerability isn't a reportable incident in itself. Exploitation with impact can be. If personal data was breached, the GDPR generally gives you 72 hours to notify your data protection authority, the CNIL in France. Financial entities assess the event against DORA's criteria for major ICT-related incidents. Entities in scope of NIS2 face an early warning within 24 hours for significant incidents, although in France the Résilience bill that transposes NIS2 is still pending. And since 11 September 2026, manufacturers must report actively exploited vulnerabilities in their products within 24 hours under the Cyber Resilience Act.

Document the decisions

Taking a site offline, accepting a workaround or postponing a migration from PHP 8.1 are risk decisions. Record who decided, when and on what information. That record is what management will need to show it oversaw the response, and what an authority or customer will ask for later.

How we handled it at Formalize

The Formalize platform runs on PHP, so the flaws affected us too, until we patched them at 13:45 UTC on 21 October. We were fully protected 11 minutes after the vulnerabilities went public. Before that, firewall rules we had put in place hours in advance blocked the main attack route. We found no sign that anyone got in or saw customer data. Customers received our written statement the next day, and they didn't need to do anything.

Keep incidents, suppliers and decisions in one place

Formalize gives each incident a record with owners, decisions and evidence, and turns the 24-hour, 72-hour and one-month reports into tasks with due dates. Supplier questionnaires and their follow-up sit next to your risks and controls, so your answer to the next "are you affected?" question starts from records you already keep.

This article is for information only and doesn't constitute legal advice.