Edition history

PHP2Shell: how AI helped expose old flaws in PHP, and why Swiss providers chose to go dark.

The Wednesday the websites went dark

On Wednesday 21 October, at 15:45, the Basel hoster cyon took its web hosting off the public network. My.cyon, Webmail, the managed and agency servers and Sitebuilder went with it. Mailboxes kept accepting messages. The websites simply disappeared.¹

SRF later put a number on it. Cyon hosts more than 100,000 websites, for clubs, small firms, private blogs and large companies, and it had taken all of them offline for a few hours.² Bexio, the accounting software that runs the day of many Swiss small businesses, had already paused at 11:08 that morning.³ The Canton of Basel-Stadt switched off its websites that evening. Parts of ETH Zurich did the same.⁴⁵

The reaction was predictable. Why did you go dark? Was this not proof of poor planning? Was WordPress to blame? Had AI broken the internet?

The facts point the other way. The interruption was visible. The compromise it helped prevent would not have been.

AI-assisted discovery helped expose serious defects that had sat in PHP for years. Professional isolation and patching helped manage a real emergency. And where disclosure failed, it was people who made the mistakes, not the discovery technology.

What actually broke

The fault sat below the application layer.

PHP is the language underneath a large share of the web. On 21 October the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities. Each is rated 9.2 out of 10 under CVSS v4.0. Early rumours of 10.0 were wrong.⁶⁷

The first, CVE-2026-109618, concerns memory corruption. When a request hits PHP’s memory limit at exactly the wrong moment, PHP can leave partly initialised data behind and later treat it as valid. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs. Remote code execution was demonstrated with default settings, and confirmed on PHP-FPM through application-level paths.⁶

The second, CVE-2026-109619, involves stale state after a fatal error. Memory that belonged to one request can be used by a later request handled by the same worker. A use-after-free and a worker crash were confirmed, and the reporter demonstrated code execution against a real application on mod_php.⁶

Both sit in memory management and error handling, the parts of PHP that nearly every request touches. That places the root cause below the CMS, the theme, the plugin and most application code. It does not mean every installation was equally exploitable. That depends on the integration mode, the versions and the actual request paths.⁶⁸

An administrator should still update WordPress, themes and plugins for their own flaws. But replacing WordPress with another PHP product would not have removed these engine flaws. The sound response was to patch and verify the runtime, not to stigmatise a CMS.⁶⁸

A problem first seen in 2024

The revealing story starts in 2024, not in a Wednesday outage.

In 2024 PHP had its first external security audit in years. The Sovereign Tech Agency funded it, and Quarkslab carried it out. While fixing one of its findings, a PHP core developer found the first signs of the out-of-memory problem. An exploit was considered, but no concrete path was found.⁶

The fixes on the table all hurt something. One broke backward compatibility. One opened new denial-of-service risks. One required changes to third-party extensions that seemed impossible to coordinate. A small team, deciding by consensus, could not choose, and the work stalled and restarted for months.⁶

The PHP Foundation did not hide this. It called the delay a structural failure, caused by its decision process and by too few engineers with deep knowledge of the engine.⁶ Security work is not “find bug, change one line, ship”. Some deep flaws need a redesign and careful testing across releases.

Then 2026 changed the evidence. In May the Foundation set up an Ecosystem Security Team. On 30 July the security firm Calif began a PHP audit under the Patch the Planet programme. On 11 August a Calif researcher, Ryan A, reported an unconditional remote code execution with the same root cause, and OpenAI independently reported the same. Wiz reported its own exploit chains on 24 August. OpenAI supplied further attack vectors on 18 September.⁶⁸

AI did not create the defective code. AI-assisted research raised the demonstrated severity and urgency of a defect that already existed.

Where AI helped, and what it did not do

AI-assisted analysis changed three practical things. Models helped researchers find their way through a large, mature native-code runtime whose error handling was hard to reason about. Researchers could try, revise and test exploit ideas across many configurations faster than before. And the resulting demonstrations made the risk legible to release managers: a theoretical memory hazard became an observed route to code execution.⁶⁸⁹

According to the PHP Foundation, Calif’s work used a frontier OpenAI model. Wiz describes frontier models working alongside expert researchers and its own systems. The maintainers also describe an earlier scan with Anthropic’s Claude Mythos and OpenAI tooling in triage. This was not one brand’s miracle. Models extended specialist teams. They did not replace them.⁶⁸⁹

What AI did not do matters just as much. It did not write the vulnerable code; that code was years old. It did not own triage, the patch decision or compatibility review. The Foundation says a person made every call and worked on every patch.⁶ It did not package fixes for distributions, build firewall rules or roll them out at hosting companies.¹⁰⁹ And it did not prove that no attacker knew first.¹¹

So the honest conclusion is not that AI makes defence effortless. AI raised the chance that defenders would find and prove an old hidden risk. It also lowers the effort for attackers. Getting safe fixes into production before cheap exploit capability spreads is the design problem of the next decade.

The defender’s window

A capable model can produce a useful finding in hours. A widely deployed runtime takes weeks to patch, test, distribute and roll out. The gap between those two clocks is the defender’s window.

If the window closes before operators have a practical fix, even a responsibly disclosed finding becomes an urgent exposure. The PHP case shows both the value of early notice and how brittle coordination becomes when a demonstration or a revealing binary leaves the embargo early.⁶⁹

OpenAI has announced 1 billion dollars of subsidised access to a security model programme for frontline defenders. That is a stated future commitment. It is not money already paid to the PHP Foundation or spent on this incident.⁹

The measure of a good discovery is not the absence of a visible emergency. It is the number of future compromises that verified fixes avert. Those are harder to count than outages, and they should not be turned into an invented figure.

Four events, not one leak

The coordinated release was set for Thursday 22 October, 14:00 UTC. On Tuesday 20 October, around 15:00 UTC, the two CVE numbers began circulating with a wrong score of 10.0. No technical details leaked, and the source of that first leak is still unknown. PHP brought its pre-announcement forward to 19:30 UTC and moved the release to Wednesday 21 October, 14:00 UTC.⁶

Around 20:00 UTC that evening, Calif mistakenly published a video showing its proof of concept against several targets. It was deleted, but copies circulated, and the Foundation says the video sped up the development of further demonstrations. Mitigation advice shared with a few critical infrastructure operators around 23:00 UTC may also have leaked.⁶

On 21 October at 07:41 UTC, more than six hours before the release, Chainguard published container images with the fixed binaries. The Foundation criticised the move: anyone could now study the fix while everyone else waited. Chainguard’s chief executive said the company published early on purpose, citing reports of active exploitation.⁶¹² The trade-off is real in both directions. The sources do not settle it.

And Amazon’s threat intelligence team found what it classed as an exploit attempt against its honeypots on 17 October, before any public leak. Whether such attempts would have worked against real systems is unclear.¹¹

These are four different events with four different conclusions. “A human leaked everything” is not a causal account. Nor do any of them show that AI caused the underlying flaws.

Thirty hours in Switzerland

All times here are Swiss summer time (CEST, UTC+2), as each operator published them. ENISA records the fixed releases at 13:40 UTC, which is 15:40 in Switzerland. Many providers worked to the announced 16:00.¹⁰¹³¹⁴

This is a ledger of what operators said in public, not a league table.^{11531617181920142122} The operators run different products, support models and old PHP versions. A short shutdown is not proof of better protection. Staying online is not proof of carelessness.

Put as bars, the windows look like a ranking: bexio 20 h 49 min, cyon about 12 h 15 min, MvA 6 h 09 min for its PHP webservers, Onlime about 46 minutes.^13162014 They are not. Bexio is a business application. Cyon is a large shared hosting estate. MvA ran packages stratified by PHP version. Onlime had a geofence as an earlier control. A shorter bar is not a security award, and a longer bar is not negligence.

Going dark, staying online

Bexio’s status log opens the emergency at 11:08 and names the critical PHP threat. Website, office, cockpit, payroll, API and banking functions were affected. The incident closed at 07:57 the next morning with the update deployed. The company later said its own checks found no unauthorised access. That is the operator’s statement, not an independent audit.³¹⁶²³

Cyon waited for security packages adapted to its own infrastructure, including backports for older PHP versions, rather than treating the source releases as enough to restart production.¹¹⁵ Its founder, David Burkhardt, told SRF the measure was drastic but a weighing-up: with hacked websites, jobs would be at stake, customer data could leak, whole systems could be destroyed.²

Onlime limited web access to Switzerland, Liechtenstein and Austria at 14:50, took its webservers offline at 16:00, patched between 16:20 and 16:45 and had everything back at 16:46.¹⁴²¹ MvA disconnected all webservers at 15:35. Current PHP versions returned from 18:17; older ones at 21:44; its Plesk panels only the next day.²⁰ One had a fast package source. The other waited for old-version backports. Neither proves that a finance application should restore in 46 minutes.

Others stayed online. Hosttech says its Imunify360 tooling applied protective measures automatically on 20 October, that it installed the official fixes from about 16:00 on 21 October and finished overnight, without a general shutdown. It also says an extra security layer does not replace runtime updates.¹⁷ METANET hardened server settings first and patched in phases, waiting in places for CloudLinux packages.¹⁸¹⁹ Green ran a 12-hour maintenance window from 18:05 to 06:05 and confirmed the last patches at 10:16. It expected brief interruptions for particular systems, not a 12-hour outage.²² A maintenance window is not downtime.

Public institutions faced the same choice. Basel-Stadt’s crisis team decided on Wednesday evening to switch off the cantonal websites. By 11:45 the next day patched sites were returning and no security-relevant incident had been registered.⁴ ETH Zurich’s main site and Staffnet were not directly affected; individual WordPress and other PHP pages run by units had to be shut down and fixed.⁵ “No incident registered yet” is a dated observation, not forensic proof.

Attempts are not breaches

Amazon recorded an apparent attempt on 17 October and more attempts on 21 October from more than one source, some before broad disclosure. It said it was unclear whether those payloads would succeed against real targets.¹¹

Imperva counted 482,342 requests, 122,311 attack sessions, 21,998 targeted websites and 103 countries in its first 24 hours.¹³ That is automated attention at real scale. It is not a count of intrusions, and Imperva says so itself.

Cloudflare switched on default protections for its firewall customers at 03:02 UTC on 21 October and watched attackers mutate their payloads to get past them. Its message is plain: patch PHP anyway.²⁴

For Switzerland, the Federal Office for Cybersecurity told SRF on 22 October that it knew of no attacks in Switzerland that could be attributed to these flaws, and warned that unrecognised or unreported cases might still surface.² “No known cases” does not mean “zero compromises”.

The other Swiss numbers need the same care. SRF’s “over 100,000 websites offline” is cyon’s estate, not a census of Swiss sites.² At 05:37 on 22 October a public scanner showed 16,128 of 466,383 Swiss websites flagged, 3.5 per cent. It put 437,288 into one bucket labelled patched or no PHP, which mixes two very different states.²⁵ And the 69.3 per cent PHP share from W3Techs applies only to sites whose server-side language it can identify. In retellings it became “70 per cent of the internet was vulnerable”.²⁶

There is no honest national loss in francs, no count of Swiss hacks, and no security winner among unequal services. Those unknowns are a research agenda, not blanks to fill.

Why WordPress was blamed

WordPress is so widespread that a PHP problem shows up as a WordPress site being down. People see the application, not the interpreter underneath. So the call to abandon the CMS is understandable. Technically it is wrong. Wiz used WordPress, Drupal and Joomla to demonstrate exploitability while the defect sat in the PHP engine.⁸ A well-kept application can still run on an unpatched runtime.

The better question is not which CMS never has flaws. None can promise that. It is who owns the lower layers, how quickly they patch, whether they carry older branches, what edge protection and recovery plans they have, and how they communicate when a dependency fails. WordPress on well-managed PHP may carry less risk than a bespoke system on a neglected stack.

A firewall buys time; it does not replace the fix.²⁴ And “nothing was announced, so it was an overreaction” confuses the absence of an observed intrusion with the absence of exposure.

How to judge a provider fairly

You can measure a disruption in minutes, lost sales and delayed invoices. You cannot easily measure the attacks that did not happen because a system was isolated. That imbalance pushes public judgement towards treating containment as failure and invisible risk-taking as competence.

A customer who could not invoice for a day suffered a real harm. But a provider who knowingly left customers open to unauthenticated server takeover, just to avoid that interruption, could have caused a far worse one. ENISA and its European partners advised temporary isolation from public networks where patches could not be applied quickly.¹⁰

A provider with credible layered protection may be right to stay online, as hosttech reports. A provider without a tested shield, or with exposed old runtimes, may be right to disconnect, as cyon and bexio did.¹⁰¹³¹⁷ The failure is to choose blindly, or to claim “protected” without an explanation anyone can test.

So the question is not “why did you go dark?” It is “what safer alternative did you have, and how quickly did you verify the fix?” Ask for the last known exposed time, the controls active before the patch, where the packages came from, how the fix was verified, whether old workers were restarted, which customers were affected and what the logs showed afterwards. Outage duration is one line in that audit, not its final grade.

The next crisis needs this ready as a standing runbook: a map from each application to its PHP runtime, a record of who approved isolation and why, tested backport channels for older versions, logs kept from before the first known probing date, and a public post-mortem by component.⁶¹⁰¹⁸

Two budgets, not one

PHP’s timeline is an unusually candid case of public digital infrastructure carried by too few people. A flaw in complex software is not exceptional. What should trouble everyone who depends on PHP is how a security issue could stay stuck on compatibility trade-offs while the value built on top kept growing. The Foundation asks companies, hosting platforms and public bodies to fund its security work in proportion to how much they rely on it.⁶

AI did not simply find what humans had missed. It raised the rate of discovery and exposed a mismatch in the capacity to fix. The Foundation published 15 CVEs since 1 July and worked through more than 100 reports that were invalid, duplicates or not reproducible.⁶ That is a real capacity problem, not a footnote.

So a serious programme has two budgets. One funds model access and security research. The other funds maintainers, test infrastructure, downstream coordination and independent verification. One without the other just fills an inbox.

Method and limitations

This Field Note is built from public sources available on 23 October 2026 around midday Swiss time: maintainer statements, advisories, vendor telemetry, provider status pages and reporting. It does not scan systems, reproduce exploits, inspect intrusions or certify any provider. Operator statements are reported as their own accounts. Status windows, maintenance windows and customer downtime are kept apart.

Still open: who caused the first leak on 20 October; whether the attempts of 17 October reached production systems; how many compromises, if any, are confirmed; what real downtime individual customers saw; and whether Chainguard’s early release protected more people than it exposed.⁶¹¹¹² A statement attributed to Marcel Salathé on LinkedIn is not quoted here, because the original post could not be verified. Should audited compromise figures or provider post-mortems appear, they belong in a dated addendum, not a silent revision.

The outage was visible

The first misunderstanding of this crisis is to take a deliberately unavailable service for a defenceless one, and a service that stayed online for a safer one. The second is to see an AI-assisted disclosure and conclude that AI created the defect. The third is to talk about WordPress when the vulnerable code was in PHP itself.⁶¹⁰⁸

The harder truth is more interesting. Human experts saw warning signs two years before the crisis but lacked the attack path and the capacity to finish a difficult fix. AI-assisted defenders turned that obscure risk into evidence. Human engineers built and shipped the patches. Hosters and public bodies decided who should stay online while the fixes spread. And people mishandled parts of the disclosure, while attackers may already have been probing.⁶⁹¹¹¹²

Machines did not save a helpless internet, and they did not ruin a safe one. Discovery is speeding up, coordination is getting harder, and competent human stewardship is worth more, not less. The answer is not to retreat from AI. It is to fund and govern AI-enabled defence well enough that the next defender’s window opens before the lights have to go out.

A responsible shutdown is an act of protection, not proof of failure.

Sources