We hear quite a lot about what AI might break. Fair enough. We should also notice when it helps us repair something important.
On 21 October 2026, PHP released fixes for two critical security vulnerabilities. AI-assisted research helped get us there. These were problems in software already running websites, not problems that suddenly appeared because someone asked a chatbot to build an app.
That distinction matters. In this case, AI was helping people find the holes, understand the danger and get them closed. I think that deserves a thank you.
What happened with PHP?
PHP is a programming language used behind the scenes to run websites and web applications. You do not need to know how to write it to depend on something built with it.
On 22 October 2026, W3Techs put PHP at 69.3% of websites whose server-side programming language it could identify. That is a substantial part of the web. It is not 69.3% of everything on the internet, and it does not mean every one of those websites was compromised. Source: W3Techs' PHP usage survey.
According to OpenAI's account, Calif identified a critical flaw using GPT-5.6 Sol. Wiz independently discovered and reported both vulnerabilities. PHP's maintainers led the fixes and release, supported by a wider group of researchers and infrastructure providers. This was a collaborative security response, not a model quietly repairing the internet by itself. Source: OpenAI's coordinated-disclosure account.
The two advisory numbers are rather less memorable than the story:
- CVE-2026-109618: an out-of-memory problem. If PHP ran out of memory at a particularly awkward moment, it could leave internal data unfinished, then use that data as though it were valid. Under certain conditions, that could let an attacker run their own code on the server. PHP's first security advisory.
- CVE-2026-109619: old state surviving into later work. PHP could retain references to memory from a previous request after that memory had been released. A later request handled by the same worker could use those stale references. The Foundation reports demonstrated remote code execution in a real-world application running on Apache with mod_php. PHP's second security advisory; the Foundation's explanation.
In ordinary language: something went wrong, the software did not clear up safely, and an attacker could potentially turn that failure into control. These were flaws in the PHP engine, rather than simply a badly written page on one website.
There is an important human part to this story
This is not a story about humans doing nothing until AI arrived.
The PHP Foundation says an external audit by Quarkslab took place in 2024. While addressing an audit finding, a PHP core developer found early signs of the memory problem. A possible exploit was considered, but concrete attack paths had not been found at that point. Fixes also presented difficult compatibility and reliability trade-offs, and progress stalled.
The later reports made the danger concrete. PHP's 21 October releases supplied fixes in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. That history is worth reading because it shows that finding a worrying piece of code, proving its impact and safely repairing a widely used system are different jobs. Source: the PHP Foundation's account of the audit, research and fixes.
For me, that makes the AI contribution more interesting, not less. We want tools that help good people get difficult work over the line. We also need to support the maintainers who have to decide whether a fix is safe to ship.
The security problem did not begin with AI
A vulnerability is a weakness. An exploit is a way of using it. The Canadian Centre for Cyber Security defines a zero-day vulnerability as one not yet known to the software vendor and therefore not yet mitigated. That is different from an available update you have not installed. Discovering a vulnerability does not automatically tell us who else knew about it. Source: the Canadian Centre's security glossary.
Pegasus gives us a documented example of the danger that already existed. In September 2023, Citizen Lab reported an exploit chain called BLASTPASS being used to deliver NSO Group's Pegasus spyware. It could compromise an iPhone running the then-current iOS 16.6 without the owner clicking anything. Citizen Lab disclosed the findings to Apple, which issued updates. Source: Citizen Lab's original BLASTPASS report.
That is a separate case, not evidence that Pegasus used these PHP flaws, or that criminals had been exploiting them for years. But it explains why I care about giving defenders better tools. Finding a serious weakness before it is used against people is a worthwhile aim.
This is not just one PHP story
There are other concrete examples. They are not identical experiments, and their numbers should not be added together as some grand AI security score.
SQLite: catching a problem before release
In November 2024, Google's Project Zero and DeepMind described Big Sleep finding a memory-safety vulnerability in SQLite's generate_series extension. It was reported in October and fixed by developers that day, before it appeared in an official release. Google said users were therefore not affected by that particular bug. That is an especially useful outcome: finding the problem before shipping it. Source: the Big Sleep team's original report.
OSS-Fuzz: helping tests reach more of the code
In November 2024, Google's security team reported 26 new vulnerabilities to open-source maintainers following work with AI-generated and improved fuzz tests. Fuzzing means testing software with many varied inputs to see where it fails. Here, AI helped build better tests, rather than simply reading code and declaring it safe. Those were reported findings, not a claim that all 26 had already been fixed. Source: Google's OSS-Fuzz research account.
Firefox: researchers and maintainers working together
In March 2026, Anthropic reported that Claude Opus 4.6 had found 22 Firefox vulnerabilities over two weeks, with Mozilla rating 14 as high severity. Mozilla's own Firefox 148 security advisory credits researchers using Claude for numerous fixes. Source: Anthropic's collaboration report; Mozilla's Firefox 148 security advisory.
These are accounts from organisations involved in the work, not a neutral measurement of the entire internet. Even so, they describe something more substantial than a chatbot confidently announcing that it has checked your website.
A discovered bug is not yet a protected business
Here is the catch. The useful outcome is not the announcement. It is the fix actually running.
Find the weakness. Validate it. Develop and test a fix. Install it. Check that the fixed software is running.
That is the chain I would want a business to care about. A press release cannot do the last two steps for you.
There is also a race. Cloudflare reported attack traffic targeting these PHP vulnerabilities around the disclosure and said attackers were changing their approaches to evade protections. It explicitly advises patching PHP even where its firewall protections are in place. AI helping defenders does not mean attackers have stopped working. Source: Cloudflare's operational account.
I would not promise that bad actors have a year or two left. I would like the next year or two to give defenders a much better chance: earlier discovery, better testing and faster, more dependable updates. That is my hope, not a prediction that cybercrime is about to disappear.
What should a website owner actually ask?
You do not need to become a PHP engineer. You do need a sensible conversation with whoever runs your website.
- Do we use PHP, directly or inside another product? Ask your host or technical supplier to check, including systems you may not think of as your main website.
- Have the relevant fixes been applied? Ask for confirmation against PHP's current advisory or your software distributor's security notice, rather than relying on an old version number alone.
- Has someone checked the running system? Downloading an update and actually running the corrected software are not necessarily the same thing.
- If we cannot update immediately, what is the temporary plan? Ask what protection it provides, what it does not cover and when the permanent fix will be installed.
The joint European cyber-agency statement calls for organisations to identify affected applications, work with providers and apply updates, prioritising exposed systems. That is a useful place to start. A vulnerable PHP engine is not repaired just by updating a website's content or a plugin. Source: ENISA and partner agencies' PHP guidance; Cloudflare's distinction between application updates and PHP fixes.
This is also why you should never reuse a password
Your password might be excellent. Long, complicated and practically impossible for someone to guess. That does not make it safe to use everywhere.
If a breach exposes that password, an attacker can try it on your other accounts. They no longer have to guess it. One site's failure can become your email problem, your shopping problem or your business problem. This is a general risk of password reuse, not a claim that these PHP flaws have exposed everyone's passwords. Source: the NCSC's password guidance.
Use a different password for every site and account. Let a password manager generate and store long, unique passwords. Switch on two-step verification where available, including on the password manager itself.
Do not build passwords around your name, birthday or other personal details someone could discover. And do not solve the problem by adding another number to the same old password. If a password is known or suspected to be compromised, change it, including anywhere you reused it. The aim is not constant, predictable password changes. It is strong, separate credentials that do not let one breach open everything else. Source: NCSC guidance on password reuse, personal information and when to change passwords.
And please, install the updates
Patching is not just getting new features or moving the buttons around. Updates often repair security weaknesses. Finding a hole is useful. Leaving the fix waiting on your computer is not.
Keep your browser, operating system and apps up to date. Enable automatic updates where available. If the browser itself says Update or Relaunch to update, save your work and do it today. Complete the restart when it is requested. Use the browser's own controls or the official settings, not a random website pop-up offering a download. Source: NCSC guidance on software updates; Google's explanation of why applying Chrome updates matters.
Servers need patching too. For a production business system, I want a prompt, tested rollout, backups and a recovery plan, not someone blindly pressing buttons. But having a process must not become an excuse for leaving known vulnerabilities untouched.
AI can help find the problems. We still have to use the fixes.
Perhaps we could have an AI appreciation day
I am not asking anyone to stop questioning AI. I spend plenty of time asking what an agent is doing, whether it has the right context and who is responsible when something goes wrong.
But we should be capable of holding two thoughts at once. AI can create new risks. It can also help us deal with risks that were already there.
In these examples, researchers used AI to investigate weaknesses in software people depend on. Some problems were caught before release; others led to published fixes. The benefit depends on maintainers turning validated findings into safe repairs, and on providers and users getting the relevant updates installed.
That is AI helping people solve a real problem. Not a promise about a distant future. Work that is happening now.
So, thank you to the researchers, the maintainers and the people doing the unglamorous work of applying the updates. And yes, thanks to the AI tools helping them.
More of that, please.
For a shorter, non-technical version focused on what to ask your team, read AI Is Finding the Bugs. Here's What Leaders Need to Do.
Sources and notes
Evidence checked on 22 October 2026. Primary sources are linked beside the relevant claims: PHP's own advisories and Foundation history; OpenAI's research-coordination account; W3Techs' usage survey; Citizen Lab's original investigation; Google and Anthropic's research reports; Mozilla's maintainer advisory; Cloudflare's operational report; ENISA's guidance; the Canadian security glossary; and the UK's NCSC guidance on passwords and updates.
This is an opinion piece about documented examples, not an estimate of AI's overall effect on cybersecurity or a security assessment of any particular website. Vendor accounts are attributed as such. Exposure, available updates and provider guidance can change; use the latest maintainer or distributor notice for operational decisions.