In October 2026 a critical PHP vulnerability put a question in front of every organisation that relies on software: when a serious flaw appears, who is able to act? Many organisations could only wait for a supplier. We own our code and used AI to improve security under pressure. Our response reached production about 6 hours before the official fix was released on .
This case study shows that AI has the potential to improve security while also offering organisations a competitive advantage. Custom software has long been too slow and too expensive for most organisations to justify. AI has significantly reduced the time it takes to develop software and that changes the calculation for both speed and protection.
The case in brief
The risk is rising
Software flaws are being published and exploited faster and many organisations take weeks to respond.
Control decides who can act
Organisations that own their code can decide and act. Others depend on the timetable of a supplier.
The economics have changed
AI has cut the time to build software and custom code is now a practical strategic option.
How to use AI to improve security
Organisations can use AI to improve security in four practical ways. Each works best with a person accountable for the decision and with code the organisation controls.
- Research each new threat: AI reads security advisories and compares them with your own systems to show where you are exposed.
- Scan your code: AI security scans run across your code base and a person confirms each finding before anyone acts on it.
- Build and test the change: AI drafts the change and tests it in a safe environment before a person approves its release.
- Test as a user would: Agents such as Claude in Chrome click through the running site and try to break it.
| Measure | What happened |
|---|---|
| Organisation | Hypergen, an Australian AI consultancy, on its own website |
| Incident | The php2shell vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) |
| AI tools | Claude Fable for research and analysis, Claude for the changes and an agent testing in a real browser |
| Human role | The site owner authorised each release |
| Time to respond | About four hours from learning of the issue |
| Result | Protective changes reached production at 07:56 UTC on , about 6 hours before the official PHP release at 14:00 UTC |
What happened in plain English
PHP is a programming language that sits beneath much of the internet. W3Techs reports that it runs about seven in ten websites whose language is known and WordPress alone runs almost four in ten of all websites. Many organisations also run older internal applications built in PHP.
Researchers found flaws that could let an outsider with no login run their own commands on a company's server. Security agencies in Europe, the UK and the United States all responded. For most business leaders the flaw itself was invisible. The practical concern was whether anyone was responsible for acting on it and how quickly they could do so.
The answer often sat outside the organisation. A hosting provider had to act for its customers. A contract developer maintaining an older application had to notice the issue and reprioritise their work. Until that happened the organisation carried the risk.
Why this belongs on the leadership agenda
Attackers are moving faster as defenders slow down. Published software vulnerabilities rose by about a fifth in 2025. The typical organisation now takes 43 days to fix a known flaw, according to Verizon. The UK National Cyber Security Centre describes how narrow the window has become:
"The time between disclosure and exploitation has shrunk to days and AI will almost certainly reduce this further."
The Australian Signals Directorate's Essential Eight model applies critical patches to online services within 48 hours of release. A gap of weeks against a standard of hours is a business risk that leaders can ask about directly.
How the events unfolded
The timeline below shows the public events beside our own response. Times are in UTC where the source gives one.
Amazon records a first attempt against a honeypot, a decoy system built to attract attackers. Success is not confirmed.
The release moves forward one day to 21 October.
The PHP Foundation reports that a security firm published the video by mistake.
The issue reaches a wide technical audience.
CERT-EU publishes version 1.0 of its advisory.
Amazon reports multiple proof-of-concept exploits and more attempts over the following hours.
Our change reaches our live website about 6 hours before the official PHP release.
Patched versions of PHP become available for organisations to install.
The UK national agency urges organisations to act.
BleepingComputer reports successful exploitation on a honeypot.
United States federal agencies receive a remediation deadline of 29 October.
Case study: how Hypergen used AI to respond
We run our website on PHP in an environment we own from source code to deployment. A month earlier we had completed a full AI-led security review across the site and its hosting and delivery pipeline. That review gave us a current picture of our own systems when the news broke. Our team moved within about four hours of learning of the issue.
- Assess: Claude Fable researched the advisories and analysed our site against them and showed us where we were exposed.
- Change: Claude built and applied the changes to our site.
- Test: We checked each change on a development environment and then a test environment. An agent submitted our forms in a real browser as a customer would.
- Release: The site owner authorised each release. The change reached production at 18:56 AEDT on 21 October.
We have left the technical detail out of this article for good reason. A public description of our defences would only help an attacker.
What this means for your organisation
The response took a small team hours. The lesson for leaders sits well above the technology: an organisation that owns its software holds the decision in its own hands. Custom code now offers three advantages together.
Your business moves faster
Software that fits your business can change as quickly as your priorities do, with no wait for a vendor roadmap.
Your business is better protected
When an urgent issue arrives your team can assess it and act on it, with AI doing much of the work.
Budget moves to critical functions
Lower spending on SaaS licences and on the support teams around slow products frees budget for functions such as security.
Budget often goes on SaaS licensing and on support teams who take a long time to make small changes in click-based products. Security will need more of that investment as the risk grows. Custom software also aligns to your business, so it works better over the long term and gives you competitive differentiation. These advantages have become practical because the time to develop software has fallen so far. Our article on the build versus buy equation sets out the commercial factors to weigh.
| How the software is run | Who acts | What this means for you |
|---|---|---|
| Managed hosting | The hosting provider | Often a quick response on the provider's timetable and with limited visibility |
| Older custom application | A contracted developer | Depends on their availability and on how quickly they can reprioritise |
| Smaller SaaS product | The vendor | No view of the code and no ability to change it |
| Code you own | Your team and its AI tools | Immediate action and the duty to scan and maintain the system |
Many hosting providers responded well. Reported host responses range from protection before the release to more than two days after it. Smaller SaaS vendors deserve particular thought. Large vendors have well-resourced security teams and smaller players may not. Published data on this comparison is thin so we offer it as our judgement. The adjacent evidence is informative: Verizon finds third parties in nearly half of all breaches.
AI is both the threat and the opportunity
Security leaders see both sides. Bruce Schneier describes the near term plainly: "In the short term, though, attackers benefit more because existing legacy code is vulnerable." His long-term view favours defence: "My long-term bet is that AI will offer more net benefit to defenders because attackers are already attacking at computer speeds and defenders will eventually be able to match them". He expects "a rocky road" along the way. Richard Horne of the NCSC said in his Annual Review 2026 speech: "AI has the potential to be one of the greatest opportunities in cyber defence."
Caution is warranted. Schneier and David Lie cite independent researchers who found that "AI that detects nearly every real bug also hallucinates plausible-sounding vulnerabilities in patched, correct code." We therefore treat AI findings as leads for a person to confirm.
Smaller teams can respond faster
Large software programs often have many developers working on separate copies of the code at once. An urgent change across an application collides with that work in flight, and combining and retesting it takes time when hours count. AI software development can reduce an application team to one or two people who own the source code. They can pause what they are doing and make the urgent change and then return to where they were.
Steve Yegge has described the wider effect on software teams. In an interview with The Pragmatic Engineer he said AI is "enabling engineers who have seen the light and believe the curves are going to continue to go up to actually get together in groups and start to do things that rival the output of big companies that are tripping over themselves." Yegge was speaking about software output. Our own inference is that the same small-team speed applies to security response.
Four questions for your leadership team
Owning code is a commitment and it brings real duties. Veracode found that AI-generated code introduced flaws in 45% of test cases in a 2025 benchmark, so review and testing stay essential. These questions help identify where custom code would earn its place.
Which systems could stop the business?
Identify the software your organisation depends on most, and consider owning the source code for those systems.
Who acts and how quickly?
Name an owner for each critical system and ask how quickly an urgent fix could reach production.
Who is checking our code?
Ask whether AI security scans run regularly over your code base and whether a person confirms each finding.
Who tests it as a customer would?
Agents such as Claude in Chrome can click through a site and try to break it as other agents read the code.
Our Hypergen Rails platform is built around these practices and it runs our own website. Our AI search optimisation page covers how the same platform supports a public website.
Frequently asked questions about using AI to improve security
How can I use AI to improve security?
You can use AI to research new threats against your own systems, scan your code base for vulnerabilities, draft and test fixes, and test a running application as a user would. A person should confirm each finding and approve each release. These uses work best when your organisation controls its code, because AI tools such as Claude can then read that code and propose changes directly.
What evidence shows AI can improve security?
Hypergen used Claude to research and respond to the critical php2shell PHP vulnerability in October 2026. Protective changes reached production on its own website about 6 hours before the official PHP release on 21 October 2026, within about four hours of the team learning of the issue. This is one organisation's experience. National agencies such as the UK National Cyber Security Centre also see AI as a major opportunity for cyber defence.
What was the PHP vulnerability in plain English?
PHP is a programming language behind a large share of the world's websites and many business applications. In October 2026 researchers found two critical flaws known as php2shell, CVE-2026-109618 and CVE-2026-109619. They allowed an outsider with no login to run their own commands on a server. PHP released fixes on 21 October 2026. Organisations running PHP can ask their provider or developer to confirm the fix is in place.
How can custom code improve security and competitive advantage?
Software risk has become a question of who can act and how quickly. Organisations that rely on suppliers wait for those suppliers to respond. Organisations that own their code can decide and act themselves. AI software development has significantly reduced the time it takes to build software, so custom code is now a practical option for many more organisations seeking both speed and protection.
Is owning your code more secure than using a SaaS product?
Owning your code gives you more control and security still depends on how you run it. Large SaaS vendors have well-resourced security teams and can respond quickly. Smaller vendors may have less capacity and their customers cannot see or change the code. An organisation that owns its code can act immediately but also carries the duty to scan it, maintain it and review changes.
How quickly should a critical vulnerability be patched?
The Essential Eight model from the Australian Signals Directorate applies online services patches within 48 hours of release when vendors assess vulnerabilities as critical or when working exploits exist. The Verizon 2026 Data Breach Investigations Report puts the median remediation time at 43 days. Organisations often seek to close that gap through automated deployment, a clear owner for each system and regular AI-assisted code scans.
Would your organisation be ready for the next urgent patch?
Talk to us about how much control you hold over your critical systems and where custom code could help your business move faster.