Key Takeaways
- Two critical PHP vulnerabilities went unnoticed for more than ten years until researchers using AI found them.
- Attackers reportedly targeted the flaws before public disclosure, so a patched system may already have been compromised.
- Forgotten sites, such as old microsites or supplier-hosted pages, are often the weakest point, especially on unsupported PHP versions.
- The NCSC advises checking for backdoors as well as patching, because a patch does not remove an attacker who is already in.
- AI is shortening the gap between a flaw being found and exploited, which makes annual testing on its own less effective.
On this page
Has anyone asked you yet whether your organisation is exposed to the PHP flaws? For many security teams, that question arrived from leadership before the patch did. It is harder to answer than it sounds.
On 21 October 2026, the PHP project released emergency fixes for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619). In short:
- The risk: an attacker could run code on a web server without logging in.
- The reach: PHP sits underneath WordPress, Drupal, Joomla, Magento and many bespoke sites.
- The advice: the UK’s National Cyber Security Centre (NCSC) told organisations to patch straight away or take sites offline.
- The impact: Edinburgh council, several Scottish councils and health boards, and parts of the BBC did exactly that.
Researchers at Wiz and Calif found the flaws using AI tools. They had been in the code for more than ten years.
Patching is the urgent job. But if your board asks “are we safe now?”, a confident answer needs more than “we’ve updated”.
So, what does the PHP scramble tell us about how AI is changing the way flaws are found, and what does that mean for how you protect your estate?
Why did AI find the PHP vulnerabilities when humans missed them?
The bugs were not new. What changed was the ability to look for them at scale.
PHP is mature, widely used code that thousands of developers have worked on. Normally, that is reassuring. But large codebases are complex, and some flaws only appear when several unusual conditions line up. Wiz says these were complicated enough that a human attacker would have struggled to exploit them.
AI tools can read and reason across vast amounts of code far faster than a person. They test combinations that a manual review would rarely reach. But finding a possible weakness is only half the job. Judging which ones matter, and how a real attacker would use them, still takes human expertise.
If your estate includes software that has run quietly for years, its age is no longer evidence that it is safe. We expect more long-hidden flaws to surface in the coming months, in PHP and elsewhere.
Does AI help attackers or defenders more?
In this case, defenders found the flaws first. But attackers have access to the same tools, and the gap between discovery and exploitation is shrinking.
This incident shows how short that gap can be:
- Details of the discovery leaked online before the PHP project was ready, forcing an early announcement.
- Amazon has said it saw several attempts to exploit the flaws in the days before public disclosure. It is not yet clear how those attackers knew.
Which side benefits more depends on who moves faster. AI can help you find and fix weaknesses earlier. It can also help attackers turn a published flaw into a working exploit within hours. If your patching takes weeks, or you are not sure what you are running, you are on the wrong side of that race.
What do the PHP flaws mean for legacy systems in your estate?
The biggest risk is usually not your main website. It is the systems nobody is actively looking after.
Most organisations patch their flagship site quickly in an incident like this. The harder part is everything else, such as:
- old campaign or event microsites
- a recruitment portal set up by an agency
- a booking page hosted by a supplier
- a device with a web management screen that runs PHP
PHP 8.1 and earlier no longer receive standard security updates, so some of these may have no simple fix at all.
In practice it could look like this: Imagine an organisation that patches its corporate WordPress site within hours of the alert. Its IT team tells leadership the job is done.
But in 2019, the marketing team launched an event microsite through an agency. It is hosted separately and still runs PHP 7.4. No one on the current team knows it exists, and it is not in the asset register. That site is now an unpatched, unsupported way in, carrying the organisation’s name and possibly linked to a shared database or mailing list.
It is a common gap, and an easy one to miss. Whether it applies to you depends on how complete your picture of your own estate is. If you cannot list every internet-facing system you own, including those run by third parties for you, start there. Our OSINT service can help identify externally visible assets and potential exposures that warrant further investigation.
Why isn’t patching PHP the end of the story?
A patch closes the vulnerability. It does not tell you whether someone used it before you closed it.
That is why the NCSC’s advice goes further than “update now”. It also asks organisations to check for backdoors, hidden ways back in that an attacker may already have planted. Given the reports of attacks before disclosure, that step matters. A server that was compromised and then patched is still compromised.
This is where the board question gets harder. “We’ve patched” tells leadership whether you are exposed today. It does not tell them whether you were breached last week.
What a compromise check looks like will depend on your environment. Typically, it means:
- reviewing web server and application logs from the days before you patched
- looking for unfamiliar files or automated tasks on PHP servers
- checking for new or changed admin accounts on your website platform
If you find something, treat it as an incident, not a clean-up job.
How should security testing change now AI finds flaws faster?
If weaknesses can be found faster, a once-a-year view of your security leaves a bigger gap than it used to.
An annual penetration test is still valuable. It gives you a deep, expert look at a defined scope at a point in time. But between tests, new vulnerabilities are published, systems change and forgotten assets drift out of view. When the time from disclosure to exploitation is measured in hours, a twelve-month cycle on its own can mean months of unseen exposure.
The answer for most organisations is not to replace point-in-time testing but to add continuous checks around it. In practice, that means three things working together: knowing what you have exposed, knowing which new threats matter to you, and testing whether your defences actually stop them. Continuous adversary emulation platforms such as WRAITH bring these together.
WRAITH pairs AI-led intelligence with human-led execution:
- Exposure discovery: the platform continuously finds what you have exposed externally, from domains and services to cloud resources you may have lost track of.
- Threat intelligence: it watches breach data, ransomware leak sites and criminal forums for information about your organisation.
- Human-led campaigns: experienced red team operators use that intelligence to run unannounced, ongoing campaigns that replicate real threat groups.
When a new exposure appears, such as a forgotten site running vulnerable PHP, it can be brought straight into a live campaign. That way, you see whether your defences hold up as your systems and the threats change.
The right mix depends on your size, risk profile and how quickly your environment changes. The question we would ask is this: if a flaw like this were published tomorrow, how long would it take you to know where you were exposed?
What to do now about the PHP vulnerabilities
Start with what is exposed today, then look at how you work.
This week
- List every internet-facing site, including microsites and anything run by an agency or supplier
- Confirm which run PHP, including inside WordPress, Drupal, Joomla, Magento or MediaWiki
- Get confirmation the PHP fix is installed, not just scheduled
- Find anything on PHP 8.1 or earlier, then upgrade, isolate or take it offline
- Check logs from before you patched for signs of exploitation
- Warn staff about phishing that uses the PHP news as a lure
Over the next quarter
- Keep a live asset inventory with a named owner for every system
- Retire campaign and event sites when projects finish
- Agree critical patching timeframes with every third party
- Review whether your testing keeps pace with how fast new flaws are found
Based on PHP project and NCSC guidance, October 2026
What does the PHP scramble mean for your security long term?
The PHP flaws will be patched, and most sites taken offline this week will come back. The shift behind them will not go away. AI is making it faster and cheaper to find weaknesses in code we have trusted for years, and attackers have the same tools.
For security teams, three things follow:
- Know your whole estate, including the systems other people run for you.
- Stop treating old as safe. Long-running code still needs checking.
- Test often enough to keep pace with how fast new flaws are being found.
Then, when leadership asks whether you are exposed, you can answer with evidence rather than hope.
Not sure what an attacker can see? Talk to our team of experts.
This article reflects information available on 22 October 2026 and will be updated as guidance develops.
Ready to achieve your security goals? We’re at your service.
expertise to help you shape and deliver your security strategy.
About the author
