PHP, the programming language behind WordPress, Drupal and Adobe's Magento, got emergency updates for two critical flaws that let someone with no password run commands on a web server. Some government websites in Finland and France, and the Port of Rotterdam's site, went offline while their owners waited for the fix. The flaws had been in PHP for more than a decade, and AI models helped find them and turn them into attacks.
The slack in patching came from how hard attacks were to build
Most businesses update their software on a calendar, monthly or when someone has time, and for years that worked well enough. After a fix was published, an attacker still had to study it, work out the bug, write an attack and then rework it for each version and setup of the target. Memory bugs like these are the worst for that, because an attack that works on one server often fails on the next. That work cost days, and the days were the slack everyone else lived in.
AI takes that cost away. Models can adapt an exploit to different PHP versions, settings and memory layouts, and keep trying when a version fails. The slack was already shrinking: attacks on serious flaws now begin about three days after the fix on average. With PHP, attacks were showing up before the fixes were even published, after details leaked, and security firms expected mass attacks within minutes of the release.
A bug in the front door does not care what the site is
PHP reads every file upload before the website's own code runs. So the flaw is in a part of the site that the shop owner, the agency and the plugin makers never wrote, and an attacker does not need to know what software a site uses. The site's own logs may show little, and no plugin on top can fix it. Updating PHP itself is the only complete fix.
The old code had been public for years, and nobody read it closely enough. Reading old code carefully is exactly what AI makes cheap, and it works for defenders too. As far as anyone knows, AI found these flaws before attackers did, and OpenAI led two months of work helping maintainers, hosting and security companies and governments prepare before release. A site on a good managed host probably had its protection ready before most owners heard anything. The leak shortened that head start.
OpenAI expects many more findings like this in the coming months. I expect emergency patch days to come several times a year, for old software hidden inside all kinds of products. A business that treats each one as a crisis will lose a lot of days, and one that treats a same-day update as routine will barely notice.
What a small business can do now
Take a family furniture shop that runs WooCommerce at a hosting company, and a recruiter whose website a freelancer built five years ago. Neither owner needs to understand the flaw. They need three answers from the host or the freelancer.
First, which PHP version does the site run? The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Second, is it on one of them yet? Anything older than 8.2 gets no fix from PHP itself, though some hosts and software vendors patch their own copies, so ask whether theirs is covered. Third, who updates it the day the next fix ships, and by name.
For an old site on an old PHP version, the real job is moving to a supported one. I would count that at a day or two of a developer's time, mostly to check that old plugins still work. That is cheaper than a week offline, and it has to be done anyway. If the answer to the third question is "whenever we get to it", that is the answer to change before the next fix.