PHP2Shell will be remembered as an emergency patch. Two critical flaws in PHP, the language behind most of the web, let attackers take over servers without logging in. Organisations across Europe and the world took websites offline while they updated. Many are covering what to do about it now.
This article looks further ahead. The emergency will pass, but what made it possible will not. AI has removed one of the oldest and least discussed protections in technology: the effort needed to find and exploit a weakness. Organisations that respond by patching faster each time will be busy, but they will not be safer. Those that change how they choose, track and run their technology will be.
What PHP2Shell Actually Showed
The flaws were old and in plain sight. The vulnerable code dated from 2012 and sat in PHP’s public source code for 14 years, until researchers found it with the help of AI.
Attackers moved before the fix. Amazon traced the first exploitation attempt to 17 October, four days before PHP published its fix, and advises measuring patch timelines for critical internet-facing flaws in hours, not days. The UK NCSC is already warning of a wave of vulnerability fixes to come.
Many organisations could not answer basic questions. Where do we run PHP? Which version? Who owns that site? Is PHP built into any product we bought? Roughly half of PHP websites run versions that no longer receive fixes at all. For many teams, the first days were spent finding systems, not fixing them.
The Control Nobody Wrote Down
Every organisation can list its security controls: firewalls, passwords, patching. Most also rely on one that appears in no policy. It is the assumption that some systems are simply too much work to attack.
That assumption is now broken. AI tools can read every line of code, try every combination of input and probe every forgotten corner of a network, around the clock and at falling cost. Work a skilled person would dismiss as not worth the time is now routine.
We have seen this building for months. In August, an AI assistant asked to book a gym class found a booking API that let any user cancel anyone else’s reservation, a flaw that had probably sat unnoticed for years. In September, Check Point reported that attackers increasingly select targets by ease of access rather than value. PHP2Shell is the same shift at the scale of the whole web.
Where the Exposure Sits
The systems most at risk are those protected mainly by inconvenience:
- Out-of-support software. PHP 8.1 and older received no fix for PHP2Shell, and every platform has an end-of-support date.
- Current versions, dated designs. Fully patched systems still built on practices from a decade ago with poor built-in security.
- Forgotten systems. Sites, portals and test servers with no clear owner.
- Hidden components. Software inside supplier products and appliances, and libraries inside your own applications, that nobody tracks.
None of this is new. What has changed is that the cost of finding it has collapsed. Technical debt used to be an efficiency problem. It is now a security problem, and an organisation with a large, ageing and poorly understood estate will lose the patching race however hard its teams work. The goal is to change the race: fewer systems to patch, a precise view of where they are, the ability to update them quickly, and an architecture that limits the damage when something gets through.
Seven Shifts for the New Normal
1. Choose Technology for Its Security Record, Not Only Its Convenience
Technology choices are security decisions, and they last for years. Some platforms carry more risk than others by their nature, not just by their current patch level.
PHP’s engine is written in C, a language that leaves memory management to the programmer, and it has a long history of memory-safety flaws like the ones behind PHP2Shell. WordPress has a well-maintained core, but many of its reported vulnerabilities sit in third-party plugins and themes, many maintained by small teams or abandoned. Neither is unusable. Both demand more care than many organisations give them. National security agencies, including CISA and the NCSC, now recommend moving towards memory-safe languages.
When choosing or renewing technology, leadership should expect the team to answer:
- What is the platform’s security track record, and how quickly are flaws fixed?
- How long will each version be supported, and what will it cost to keep up?
- How many third-party components does it pull in, and who maintains them?
- Is there a simpler option? A marketing site rarely needs a database and a plugin ecosystem. A static site or a managed platform removes most of that exposure.
2. Manage Technical Debt as a Business Risk
Technical debt is rarely funded because its cost is invisible until an event like PHP2Shell. It belongs on the risk register, with an owner, a budget and a plan. For every legacy system, there are three options:
- Retire it. If nobody can name a business owner or a current purpose, switch it off. Unused systems carry all of the risk and none of the value.
- Replace or modernise it. Move to a supported version, or to a platform with a better security record, on a funded timeline.
- Contain it. Where a system must stay, take it off the internet, put it behind strong authentication, separate it from the rest of the network and monitor it closely. Record this as a formal risk acceptance, owned by an executive, and monitor the risk closely.
What is no longer acceptable is the fourth, unspoken option: leaving it as it is because it has always worked.
3. Know Exactly What You Run, at All Times
During PHP2Shell, the organisations that responded fastest could answer “where do we run PHP, and which version?” in minutes. The same gap appeared in the French supermarket refrigeration attack, where contractor-installed controllers appeared on nobody’s inventory, and in the keyv supply chain attack, where a compromised library reached organisations that had never heard of it.
An accurate inventory covers every internet-facing service with a named owner, hardware and appliances with firmware versions, software with end-of-support dates, sensitive data and where it flows, and the components inside your applications. Those components belong in a software bill of materials (SBOM), a machine-readable list of every component and version.
This inventory must update itself automatically, from build pipelines, cloud services, network scans and external attack surface monitoring. A list compiled by hand once a year is out of date before it is finished. When the next advisory is published, a single query should show every affected system and its owner.
4. Build Systems That Can Be Updated in Hours
If critical flaws must be fixed in hours, systems must be designed for it: automated build and deployment, environments rebuilt from code rather than repaired by hand, tests that give teams the confidence to release quickly, and passwords and keys held in a secured central vault so they can be replaced in one step. Plan for the moment no fix exists yet: which services can be taken offline, who decides, and how to bring them back safely.
5. Assume Something Will Get Through
No organisation will find every flaw first. Architecture decides whether one compromised web server becomes a contained incident or a breach of the whole organisation. Fix the dated designs listed above, give accounts only the rights they need, and monitor for what a compromise looks like, such as a web server opening unexpected connections. Then make sure someone would notice quickly, and knows they have the authority to act.
6. Use AI on Your Own Systems First
The capability that found PHP2Shell is also available to attackers. Point it at your own code, configuration and internet-facing estate on a regular cycle. The advantage goes to organisations that do this first, and leave little for anyone else to find.
7. Hold Suppliers to the Same Standard
Much of the PHP2Shell exposure sat in products and services organisations had bought, not built. Responsibility for that risk stays with your firm, and vague reassurance from a supplier is not an answer. Contracts should require an up-to-date SBOM, defined timelines for fixing critical flaws, prompt notification when one affects you, advance notice of end-of-support dates, and evidence on request of which versions they run on your behalf. The EU Cyber Resilience Act will make much of this a legal obligation for manufacturers. Buyers do not need to wait for it to ask.
What Leadership Should Do
| When | Action | Purpose |
|---|---|---|
| Within 30 days | List every internet-facing system with its software version, support status, and a named business owner | Establishes what you actually run |
| Within 30 days | Remove access that is no longer needed, starting with administrator and supplier accounts | Closes the easiest routes in, which automated tools find first |
| Within 90 days | Put technical debt on the risk register and agree a funded plan to retire, replace, or contain out-of-support, unowned, and outdated-by-design systems | Shrinks the estate an attacker can probe |
| Within 90 days | Assess core systems against current security practice, not only version support: login methods, key and password handling, network separation, exposed admin interfaces | Finds systems that are patched but built on older, weaker designs |
| Within 90 days | Test how quickly you would detect an attack on an internet-facing system, and who would decide what to take offline | Shortens the time between an attack and your response |
| Within 6 months | Automate the asset inventory, including SBOMs for your own applications | Lets you answer the next advisory with a query, not a search |
| Within 6 months | Add security criteria to technology selection and supplier contracts: track record, support lifecycle, SBOM, patch timelines | Stops new technical debt from being bought in |
| Within 12 months | Map where sensitive data flows and delete copies that serve no purpose | Limits what an attacker can take and what you would have to report |
| Within 12 months | Use AI-assisted testing on your own code and systems on a regular cycle | Finds your weaknesses before someone else does |
Regulators Already Expect This
Most of the above is already written into the rules many organisations operate under.
| Framework | What it expects |
|---|---|
| EU Digital Operational Resilience Act (DORA) | EU financial entities must identify, classify and document all their information and communication technology (ICT) assets and dependencies, and keep this inventory up to date |
| EU Network and Information Security Directive (NIS2) | Asset management and vulnerability handling are required security measures for essential and important entities |
| EU Cyber Resilience Act (CRA) | Manufacturers of digital products must handle vulnerabilities throughout the support period and draw up an SBOM. Reporting obligations apply from 11 September 2026, and the main obligations from 11 December 2027 |
| Swiss Financial Market Supervisory Authority (FINMA) | Supervised institutions must maintain an inventory of critical functions and the assets that support them, as part of operational resilience |
An organisation that cannot show an accurate inventory and a plan for its legacy systems will find this harder to defend after an incident than before one.
Questions for Your Next Board Meeting
- Which of our systems are safe mainly because they are awkward to attack?
- If a flaw like PHP2Shell were published tomorrow, how long would it take us to list every affected system and its owner?
- What do we run that is out of support or has no owner, and when will each be retired, replaced or contained?
- Do security criteria shape how we choose technology and suppliers, or only how we patch them afterwards?
- Are we using AI to test our own systems, or leaving that to attackers?
If these cannot be answered with evidence rather than reassurance, that is the finding.
Key message: PHP2Shell sat in public code for 14 years, protected only by the effort needed to find it, and AI has removed that protection. Patching faster is necessary but not enough. Choose technology for its security record, retire, replace or contain your technical debt, know everything you run down to the component level, and test it with AI before someone else does.
How DarkGuard Can Help
Years of technical debt cannot be cleared overnight and trying to fix everything at once rarely works. DarkGuard helps you start where the risk is highest, and make steady, measurable progress, one step at a time:
- Technical debt and security exposure rating. We assess your internet-facing estate, software versions, ownership and support status, and rate where outdated, unowned or over-permissioned technology creates the most risk. You get a prioritised plan to retire, replace or contain it.
- Asset inventory and SBOM readiness. We help you build an inventory that keeps itself current, covering systems, software, components and suppliers.
- Detection and response readiness. We test how quickly you would spot and act on an attack, from monitoring and alerting through to who decides what to take offline, and help you shorten that time.
- AI-assisted security testing. We run advanced AI models against your code and systems, beyond the limits of commercial tools, safely and in a controlled environment.
Contact our Advisory and Response Desk
If you would like an assessment or advice, contact us.
