PHP2Shell: How an AI-Assisted Discovery Pulled Governments Offline, and What It Means for Law and Global Security
Key takeaways
- What it is: PHP2Shell is a pair of critical flaws, CVE-2026-109618 and CVE-2026-109619, each scored 9.2 on CVSS v4.0. They allow an unauthenticated attacker to run code on a server that runs PHP.
- The fix: PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026. The maintainers say updating is the only safe choice, because no complete mitigation exists.
- AI’s role: Researchers used frontier models to find the bugs and to build and adapt exploits. The extent to which AI was decisive is disputed.
- Banking: I have found no verified evidence that any major bank was breached through these flaws. The realistic exposure sits in web tiers, vendor portals, payment plugins and smaller platforms, and in the fraud that follows any scare of this size.
- The bigger point: The patch is a technical event. The leak, the preventive shutdowns and the speed of exploitation are governance events, and governance is where we are failing.
Why I am writing about this
Most of my work concerns the point where machine speed collides with human law. I research autonomous systems, and I have argued on my AI stance page that AI-enabled cyber operations against critical infrastructure are a near-term risk that doctrine and regulation have not caught up with. This week supplied a live case study. I want to treat it with the precision it deserves, which means separating what is verified from what is being shouted on social media.
What happened
The sequence matters, because the order of events is where the lessons are.
Calif, a security firm working through OpenAI’s “Patch the Planet” initiative, began auditing PHP at the end of July. Its researcher Ryan Austin reported the first bug to the PHP team on 11 August, according to the published timelines. Wiz reached related findings independently and reported on 24 August. OpenAI reported the same root cause independently as well, and sent further attack vectors in September. A small group of maintainers, researchers and vendors then worked quietly on fixes for roughly two months.
On 20 October the arrangement collapsed. CVE identifiers appeared on forums and social media with the wrong release time. That evening Calif mistakenly published a video of a working proof of concept, and copies spread after it was deleted. TechTarget’s account describes an embargo that unravelled on several fronts at once. Separately, Chainguard released patched builds early, which per the Wikipedia summary of the incident let attackers see exactly which code had changed.
Patches reached the public on 21 October, about a day ahead of schedule. The NSA warned organisations to take sites offline if they could not fix quickly. The UK’s National Cyber Security Centre told organisations to find every internet-facing PHP system and to consider taking systems offline where immediate remediation was not feasible. CERT-EU, Australia, Singapore and Japan issued comparable alerts.
Then Cloudflare’s CEO tweeted this warning:

Then the internet visibly flinched. Reuters reported that Dutch bodies including the Port of Rotterdam, the government portal Overheid.nl, hospitals and the websites of the five largest political parties went dark. French prefecture sites were pulled. Belgium’s foreign ministry, the Czech government and Finland’s state IT provider did the same, and a Reuters factbox lists many more. Japan’s Prime Minister, Sanae Takaichi, made an unusually direct appeal to operators on X, and the cloud provider Sakura Internet suspended a database function.
Exploitation was real and fast. Cloudflare deployed protective rules in the early hours of 21 October and reported exploitation attempts. watchTowr observed in-the-wild exploitation. Amazon’s threat intelligence team traced an attempt in its honeypot telemetry to 17 October, four days before the public patch.
Read that last sentence again. The “Defender’s Window” that AI developers have celebrated was, for at least some hosts, already closing before defenders were told the door was open.

The technical picture, without the hype
Both flaws are memory safety defects classified as CWE-824, access of an uninitialised pointer, per Imperva’s analysis. CVE-2026-109618 arises when PHP runs out of memory at the wrong moment, leaving internal structures half built for cleanup code to trust. CVE-2026-109619 involves stale global state that carries over between requests when PHP workers are reused. Researchers demonstrated exploitation through session upload progress handling, OPcache class caching and fatal-error backtrace generation.
The practical consequence, as BleepingComputer reported, is code execution as the web worker account, with possible memory disclosure, across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The flaws sit in the engine itself. A site can run impeccable application code and still be exposed. Ubuntu published backports for releases as old as 14.04 under extended support, which tells you how old the lineage is.
Two caveats deserve space. First, the often-quoted “70 to 75 percent of websites” figure comes from W3Techs and refers to sites whose server-side language can be identified, so the denominator is narrower than “the whole web”. Second, code execution as the web worker account is serious without being total control of a machine. What an attacker does next depends on how well the host is isolated. That distinction is the difference between a defaced brochure site and a breached payment system.

Did AI really find it?
The headline says yes, and the truth is more contested than the headline.
OpenAI credits GPT-5.6 Sol for Calif’s discovery. Wiz says it used its own Wiz Atlas agent plus Gemini 4 Argon and GPT-5.6 Sol, and that AI helped with discovery, exploit development and patch validation. The DEV Community write-up records that Calif’s own account credits a human theory about where PHP’s old bugs hide and says no special harness was needed, while Chainguard’s chief executive told The Register his team independently found the same bugs with a basic prompt over a weekend.
I read those accounts together as follows. Human insight pointed models at a promising class of failure. Models then compressed work that would have taken human teams months, particularly the porting of exploits across PHP versions and configurations. The most defensible reading of the evidence is that AI cut the cost of finding and weaponising memory-safety bugs in mature code, rather than conjuring a capability from nothing. For defence and for offence, cost is what matters.
This is dual-use technology in its purest form. A model that can find a 14-year-old bug for a defender can find it for an attacker, and the attacker does not need to observe an embargo.
The leak is the scandal
I will say what the polite commentary will not. The vulnerability is a flaw in code. The leak is a failure of people, and it was repeated across several organisations.
Coordinated disclosure is built on trust and discipline. Here the chain broke at the forum post, at the video, and at the early release of patched builds that allowed patch diffing. None of those is exotic. All are ordinary lapses at the exact moment ordinary lapses cannot be afforded. If a flaw this consequential cannot be held under embargo for a day, then the premise that frontier-lab safety programmes will manage the offence-defence transition through goodwill and good intentions needs serious re-examination. My view, set out on the AI stance page, is that voluntary arrangements are the performance of governance rather than its substance. This episode is another data point.
Fairness requires one more observation. The researchers did report responsibly, the maintainers did coordinate, and a very large number of systems were patched before worse could happen. The criticism is of the process, and the process has been under-resourced for a decade.
Online banking: what is known, what is not, and where the risk actually sits
The premise of many viral posts this week, that “banks are down” or “your bank is hacked”, needs care.
What is verified. Major financial institutions did not announce breaches attributable to PHP2Shell. One crypto-industry analysis explicitly cautions that there is no verified evidence that named exchanges or payment providers were compromised. A markets-focused analysis found that the viral market-impact stories were largely wrong, and that PHP2Shell produced no measurable equity market effect. Separately, a Japanese market commentator reported that some banking and payment services paused preventively, though I have not seen that confirmed in a primary source and I flag it as unverified.
Where the exposure plausibly sits. Core banking systems and mobile banking back ends are rarely built on PHP. But a bank is a perimeter of many surfaces: marketing sites, onboarding and appointment portals, customer-support systems, content management systems run by agencies, and third-party platforms. Small lenders, credit unions, fintechs and crypto exchanges are likelier to have PHP closer to the money. So are merchants whose checkouts run on PHP e-commerce platforms. Code execution on a checkout server enables card skimming of the kind that led the UK Information Commissioner to fine British Airways £20 million in 2020. For the customer, the weak point is often the shop, not the bank.
Preventive shutdowns are rational and costly. Taking a system offline before an attack lands is the correct instinct for an operator that cannot patch in hours. It also converts a security event into an availability event. In the financial sector, availability is regulated as seriously as confidentiality, which is why the shutdowns will be examined.
The fraud wave. I expect the larger harm to customers to arrive through social engineering. Mass news coverage of a “critical flaw” is an ideal pretext for phishing emails and texts claiming your account needs an urgent security update. Criminals do not need PHP2Shell to exploit the fear of PHP2Shell.
What to do now, by audience
If you are a bank customer or user of online services. You cannot patch PHP, and you do not need to try. Sensible steps:
- Use your bank’s official app or type its address yourself. Ignore links in messages about “security updates”.
- Turn on multi-factor authentication, preferably passkeys or an authenticator app rather than SMS codes.
- Use a unique password for every financial service, held in a password manager. If you reused a password on a smaller site that was affected, change it.
- Switch on transaction alerts and check statements this week.
- If something looks wrong, contact your bank immediately. In the UK, 159 connects you to your bank’s genuine fraud line.
- Know your rights. Under regulation 76 of the Payment Services Regulations 2017, UK payment providers must generally refund unauthorised transactions promptly, subject to limited exceptions.
If you run a WordPress, Drupal, Magento or custom PHP site. Wordfence warned that automatic WordPress updates will not install the PHP engine fix. PHP is updated at the server level. Work out who controls it, which in many cases is your host, and ask them in writing which PHP version you are on and whether it contains the fix. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you are on anything older and out of support, treat migration as urgent. Restart services after updating, because running processes keep the vulnerable code in memory, as Qualys notes. Review logs from 17 October onward for suspicious requests to session upload progress endpoints and unexpected files or processes.
For transparency on how this applies here: this site runs on WordPress and is hosted with Hostinger
. Because the vulnerability sits in the PHP runtime rather than WordPress core, engine-level remediation had to happen at the host level. Hostinger mitigated the initial leak by pushing deny-mode firewall rules and disabling session.upload_progress ahead of the patch, before rolling out the official PHP updates across all managed servers yesterday (22 October). I have checked my PHP build date and audited my configuration to confirm that aviperera.com is fully patched and secure. If your current provider has left you guessing about your server’s patch status this week, I recommend moving to Hostinger’s managed hosting so server-level security is handled automatically.
If you run security or risk at a financial institution. Build an inventory of every internet-facing PHP instance, including vendor-managed and agency-managed ones, using the NCSC-NL inventory of products with a PHP dependency as a starting point. Assume that exploitation predates disclosure. Hunt, rather than only patch. Document your decisions and timestamps now, because regulators will ask for them (see the law section).
For everyone. You should be careful accessing any website for the next few days. Especially when inputting credentials. Don’t log in to particular platforms or obscure or old websites. Wait for patches.

The law
Here I wear my other hat. Incidents like this are where the abstract duties of cyber law turn concrete.
UK. The Computer Misuse Act 1990 criminalises unauthorised access and impairment, so every opportunistic exploit attempt this week is an offence under section 1 or section 3. The same Act contains no express defence for good-faith security research, a gap researchers have complained about for years and one that this episode, where researchers demonstrated live exploit chains, illustrates. Operators of essential services and digital service providers face the Network and Information Systems Regulations 2018, and the Cyber Security and Resilience Bill introduced in late 2025 would widen that regime, so readers should check its current stage. Any compromise of personal data triggers UK GDPR duties, including notification to the ICO within 72 hours of becoming aware under Article 33. Financial firms add the FCA and PRA operational resilience framework and, for key suppliers, the Critical Third Parties regime.
EU. The NIS2 Directive requires risk-management measures including vulnerability handling (Article 21) and staged incident reporting (Article 23), and it encourages coordinated vulnerability disclosure (Article 12). For banks, insurers and many fintechs the Digital Operational Resilience Act, applicable since January 2025, is the sector-specific regime. It imposes ICT risk management, major-incident reporting and tight oversight of ICT third parties. The GDPR requires security appropriate to risk under Article 32 and carries fines of up to 4 percent of global turnover under Article 83. The Cyber Resilience Act brings mandatory reporting of actively exploited vulnerabilities for covered products from 11 September 2026, with a lighter regime for open-source stewards. How it applies to a foundation maintaining a global language runtime deserves scrutiny, and I do not think the answer is settled.
United States. The SEC requires public companies to disclose material cyber incidents on Form 8-K within four business days of determining materiality. New York’s 23 NYCRR 500 requires regulated financial entities to notify the Department of Financial Services within 72 hours. The FTC’s authority to police unreasonable security practices was confirmed in FTC v Wyndham Worldwide Corp, 799 F.3d 236 (3d Cir 2015), a case in which outdated software and weak patching featured prominently.
Civil liability. In England, Lloyd v Google LLC [2021] UKSC 50 closed off most opt-out damages claims for mere loss of control of data, so claimants must usually show actual damage or run a different cause of action. WM Morrison Supermarkets plc v Various Claimants [2020] UKSC 12 shows that organisations can still face vicarious liability for data breaches in some circumstances. Neither case will reward a defendant who knew about a critical, publicised, patchable flaw and did nothing for weeks.
International law. The foundational authority on territorial responsibility remains the ICJ’s judgment in the Corfu Channel case (1949), which recognised that a state must not knowingly allow its territory to be used for acts contrary to the rights of others. The Tallinn Manual 2.0 extends that logic to cyberspace as a due diligence rule (Rule 6), though states disagree about its scope. The 2015 UN Group of Governmental Experts report endorsed norms including not knowingly allowing ICT attacks on another state’s critical infrastructure (13(f)) and responsible reporting of ICT vulnerabilities (13(j)). The principle of non-intervention articulated in Nicaragua v United States (1986) frames when hostile cyber operations cross a legal line. None of these instruments obliges a state to patch the web. That is the gap.
History says we have been here before
Every piece of this episode has a precedent, and the precedents are not flattering.
- Heartbleed (2014). A flaw in OpenSSL, CVE-2014-0160, exposed memory on servers securing a very large share of the web. It revealed that critical infrastructure was maintained by a handful of underfunded volunteers. Wiz itself compared PHP2Shell to Heartbleed.
- Equifax (2017). Attackers exploited an Apache Struts flaw, CVE-2017-5638, for which a fix had been available for months. The breach exposed data on roughly 147 million Americans and led to a settlement of at least $575 million with the FTC, the CFPB and states. The UK ICO fined the company £500,000, then the maximum under the Data Protection Act 1998. The lesson was that known and unpatched is the worst legal position to occupy.
- WannaCry (2017). The NHS was hit by ransomware exploiting a flaw with an available patch. The National Audit Office’s investigation documented the failure to apply it and the operational consequences for patients.
- TalkTalk and Capital One. The ICO fined TalkTalk £400,000 in 2016 for a breach through basic, well-known weaknesses, and the US OCC penalised Capital One $80 million in 2020 over its cloud security failures.
- Log4Shell (2021) and xz (2024). Log4Shell showed how a flaw in a ubiquitous library cascades through supply chains. The xz backdoor, CVE-2024-3094, showed that the maintainer, rather than the code, can be the attack surface.
What changes in 2026 is the economics. In each earlier case, the gap between disclosure and mass exploitation was measured in days or weeks, and defenders used it. When models can read a patch and generate a working exploit for each supported version, that gap shrinks. The sociologist Charles Perrow argued in Normal Accidents (1984) that tightly coupled, complex systems will fail in ways their designers cannot foresee. We have now tightly coupled the web to a single runtime, and the disclosure process to the speed of human error.
International relations: what this means beyond the server room
I want to flag five implications I think policymakers are under-weighting.
1. Infrastructure dependency is a sovereignty problem. The PHP Foundation, a small organisation, maintains code on which governments, hospitals and financial systems depend. Dependency without accountability, funding or oversight is a strategic vulnerability. States that call digital sovereignty a priority should ask why they do not fund and audit the foundations of their own web presence. The world’s governments just discovered they share a single point of failure.
2. Preventive shutdown is a new, double-edged norm. When the NSA, the NCSC and a prime minister all advise taking services offline, defence becomes self-inflicted denial of service. The logic is sound. The precedent is worrying. An adversary now has an incentive to announce, or fabricate the credible threat of, a flaw to induce disruption. Imagine the same dynamics with a disinformation campaign layered on top.
3. Dual-use AI is now an arms-control question. The same capability that gave maintainers a head start gives states and criminal groups a faster path from patch to exploit. I have argued for years that legal frameworks must follow capability, and the AI Safety page on this site sets out why binding obligations matter more than voluntary pledges. A frontier lab’s “defender’s window” is a promise about timing that no treaty enforces.
4. The law of armed conflict is reaching the web tier. Under Article 49 of Additional Protocol I, an attack is an act of violence against an adversary, and Tallinn Rule 92 defines a cyber attack as an operation reasonably expected to cause injury, death, damage or destruction. Hospitals and civilian services being rendered unavailable, or exploited, sit very close to that line once a state actor is involved. The distinction principle, the protection of medical facilities and the duty to take precautions in attack all apply to cyber means. A state that mass-exploits a flaw like this against civilian networks during an armed conflict will face questions it cannot answer with ambiguity. Readers who follow my work on autonomous weapons will recognise the pattern: machine speed, thin human control, and an accountability gap. My AI Weapons database documents how those problems appear in kinetic systems. The cyber analogue arrived first.
5. Attribution and escalation risk rise with speed. Mass exploitation within hours makes it harder to know who is doing what, and easier to blame the wrong actor. Where states already distrust one another, that is a recipe for misjudged escalation. The lesson of NotPetya, which the UK publicly attributed to Russia’s military intelligence service in 2018, was that collateral damage from state tools can dwarf the intended target.
A sociological note on infrastructure we forget to see
The scholar Susan Leigh Star observed in 1999 that infrastructure becomes visible mainly when it breaks. PHP is the epitome of invisible infrastructure. Many people use it daily without knowing its name. This week it surfaced because councils, hospitals and ministries went dark. There is a psychological dimension here as well. The public’s reaction oscillates between indifference and panic, and institutions oscillate with it. Long-term resilience needs steady funding, audit and drills, none of which win headlines.
My position
I do not think this episode shows that AI is dangerous in some abstract sense, and I do not think it shows that AI saved the day. It shows something more useful. Powerful tools are now being used by competent defenders and by indifferent institutions in the same fortnight, and the gap between the two is a governance gap.
This website is a small illustration of that divide in practice. Because aviperera.com runs on WordPress—and therefore on PHP—it sat directly in the path of this week’s disclosures. I host the site on Hostinger, which did what a competent infrastructure provider is supposed to do when an embargo collapses: before the official patches even landed, they deployed ModSecurity firewall rules to block circulating exploit patterns and disabled session.upload_progress across their LiteSpeed and PHP-FPM setups to close off CVE-2026-109619. By early yesterday morning (22 October), they had rolled out the patched PHP builds across their managed servers. I have independently verified my build date and configuration to ensure everything here is updated and secure, and if you want managed WordPress hosting that handles engine-level emergencies at machine speed, you can use my referral link here. The wider lesson, however, is that resilience should not depend on whether an individual site owner happened to pick an attentive host.
I want to be clear about where I stand because it is consistent with everything on my stance page. I am enthusiastic about AI that finds vulnerabilities before attackers do. I want it funded and I want the maintainers of critical open-source code paid properly. I am equally clear that disclosure discipline, mandatory patching duties for critical infrastructure, personal accountability for executives who ignore known flaws, and binding international norms on the weaponisation of AI-discovered vulnerabilities cannot remain voluntary. The people who profit from the vacuum will not fill it.
If you want the longer arc of how I came to this work, you can read my story, browse my other articles, or look at my law and international relations writing. A parallel argument about foreseeable failure and legal accountability for AI products appears in my analysis of the Character.AI bankruptcy.
What to watch next
- Regulator reactions. Expect questions from financial supervisors on inventories, decision logs and third-party exposure.
- Post-incident reporting. Whether any organisation discloses a confirmed breach attributable to PHP2Shell, and when.
- Exploitation by capable actors. Watch for confirmed state-linked activity and ransomware campaigns.
- Policy on embargoes and AI. Whether the leak prompts new rules or merely new apologies.
- Funding for the PHP ecosystem. Whether the money follows the attention.
This is a developing situation. I will update this post as verified information emerges.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, in the PHP engine that let an unauthenticated attacker execute code on a server serving PHP web requests. Both score 9.2 on CVSS v4.0.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Older releases need to be upgraded or patched by a vendor with extended support.
Was my bank hacked because of PHP2Shell?
I have found no verified evidence that a major bank was breached through these flaws. Smaller institutions, vendor portals and merchant checkouts carry more of the realistic exposure. Use your bank’s official app, enable multi-factor authentication and watch for phishing.
Do I need to update PHP on my own computer?
No. PHP runs on website servers. The responsibility sits with the operators of the sites and services you use.
Did AI find the PHP vulnerabilities?
Researchers used AI models including GPT-5.6 Sol and Gemini 4 Argon to help find the flaws and to build and adapt exploits. The degree to which AI was decisive is contested.
Why did governments take websites offline?
Agencies including the NSA and the NCSC advised taking systems offline where patching could not be done immediately, because exploitation had begun and no complete mitigation existed.
References and further reading
- PHP 8.5.12 release notice and PHP 8.4.27 release notice
- NCSC alert on PHP (UK)
- Reuters via CNBC: Government websites go dark
- CNBC: PHP2Shell explainer
- Reuters factbox on sites taken offline
- Krebs on Security
- BleepingComputer
- watchTowr technical analysis
- Imperva technical analysis
- Qualys threat research
- TechTarget on the disclosure failure
- Ubuntu security notice
- NSA warning reported by AFP
- Jiji Press on Japan’s response
- Perrow, C. (1984) Normal Accidents. Star, S.L. (1999) “The Ethnography of Infrastructure”, American Behavioral Scientist 43(3).
Avi is a researcher educated at the University of Cambridge, specialising in the intersection of AI Ethics and International Law. Recognised by the United Nations for his work on autonomous systems, he translates technical complexity into actionable global policy. His research provides a strategic bridge between machine learning architecture and international governance.







