AI Found the Bug in a Week. Could You Ship the Fix in a Day?

A bug sat inside PHP for about fourteen years. This summer, AI found it. Last week, a lot of IT teams across Europe spent their evenings patching it.

I wrote PHP and Laravel for years before I moved to Kotlin, so this one hit close to home. And the part that keeps me thinking is not the bug itself. It is the clock.

Fourteen years, then a few hours

The flaws are now called PHP2Shell: two critical bugs that can let an attacker run code on a server without logging in. PHP pushed emergency fixes around October 20 and 21.

According to Fortune, three groups found the issue independently over the summer, all using AI. A red-teaming firm called Calif, OpenAI itself, and Wiz, which used Gemini, GPT and its own tooling. Wiz said one researcher with these tools finished in a week what used to take a strong team months.

Then details leaked before the official release. Cloudflare reported tens of thousands of exploit attempts within 45 minutes and millions by the next evening. Government sites in the Netherlands, Finland, Denmark and France went offline while teams patched. So did some pages in Japan and an Irish news site.

So: fourteen years to find, a week to confirm, and a few hours before attackers were knocking.

The number that worried me more

Qualys looked at the PHP installations it can see across its customers. Around 71% run versions that are already end of life. Not "behind on a minor update". Out of support.

That is not a PHP problem. I have seen the same thing in Java shops, in Spring Boot services nobody wants to touch, in Python services pinned to a version from three jobs ago. We all have that one service.

For years this was a quiet risk. Upgrades could wait for "the next quarter" because finding a serious hole took time and talent. That buffer is gone. If AI can find the bug in a week, someone with worse intentions can too.

What I expect next

More of this, not less. OpenAI and others are openly running programs to point AI at widely used open source code. Good. But every find becomes a patch, and every patch lands on someone's desk with a deadline nobody chose.

I think the teams that suffer will not be the ones with the worst code. They will be the ones who cannot deploy quickly. The ones where a one-line version bump needs three approvals, a freeze exception and a person who left in 2023.

Being able to ship a boring fix fast is now a security feature.

What I would do this week

None of this needs a big program. It needs a few honest checks:

1. Know what you run. Can you list every service and its runtime version in five minutes? If not, start there.
2. Find your end-of-life list. Write down which services run unsupported versions. Give each one an owner and a date.
3. Rehearse the emergency patch. Pick one service and time how long a runtime bump takes from ticket to production. That number is your real exposure.
4. Remember the restart. For PHP2Shell, the advice was to restart all PHP workers after patching. A fix that is installed but not loaded is not a fix.
5. Managers, protect upgrade time. If upgrades only happen when someone fights for them, they will lose every time to feature work. Make it part of the normal plan.

I used to think of upgrades as hygiene. Nice to have, slightly boring, easy to postpone. After this week I see them as a reflex. And reflexes only work if you train them before you need them.

Sources: Fortune, Axios, ABC7, Qualys