Situation report from the evening of Wednesday, 21 October 2026, with Thursday morning updates at the end of each section. It started around midday when the website of the city of Mainz stopped loading, shortly afterwards the Charité hospital was gone, then Mittwald announced that every single customer website of the hosting company was offline, in the Netherlands the government switched off DigiD and MijnOverheid, Canada’s government took federal websites down, and in Japan Square Enix blocked logins to Final Fantasy XIV. The culprit is not an attack but two bugs in the core of PHP that have been given the name PHP2Shell and that affect practically every PHP installation of the last ten years, which means every WordPress, every TYPO3, every Nextcloud and, on top of that, quite a few firewalls and NAS devices. Since I run several WordPress sites in Docker on a VPS, I spent the day following the situation, bringing my servers up to date and reading status pages, government warnings and live blogs from all over Europe. Here is what I gathered: what the vulnerability is, how it was found, who pulled the plug as a precaution, which hosts have already patched, whether it is already being exploited and what you need to do now.
What is PHP2Shell, anyway?
Behind the name are two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 on CVSS 4.0 by the PHP security team. Both allow an attacker to run their own code on the web server without logging in, and not because of a bug in WordPress, Joomla or some plugin, but because PHP itself is sloppy when cleaning up after an aborted request. The name is a nod to Log4Shell from December 2021, and unfortunately the comparison is not that far-fetched.
Put simply, this is what happens: when a PHP request aborts unexpectedly, for example because it hits the memory_limit or runs into a fatal error, internal state is left lying around in the PHP worker, and the next request handled by the same worker keeps using it, even though the associated memory has long been freed or was only half initialised. So an attacker deliberately provokes such an abort, for instance with a crafted upload form or absurdly deeply nested field names, and then sends a second request that exploits the leftover state. The nasty part about the first bug is that the error already happens while the request is being read, that is, before a single line of application code runs, which is why it makes no difference whether there is a fresh WordPress or a simple “Hello World” behind it. The researchers at Wiz found four paths in the PHP core in total, among them the progress indicator for file uploads (session.upload_progress, enabled by default), the backtrace generation on fatal errors and the OPcache, and used them to demonstrate code execution against the current Docker images of WordPress, Drupal and Joomla.
| Vulnerability | What happens | Notable |
|---|---|---|
| CVE-2026-109618 (OOM corruption) | When the memory limit is reached, PHP aborts in the middle of initialisation and the cleanup treats the broken state as valid | A single unauthenticated request is enough, before any application code runs; confirmed against Apache with mod_php over HTTP with default settings |
| CVE-2026-109619 (stale global state) | Request data survives being freed and is used by the next request on the same worker | Needs at least two requests, first create the error state, then exploit it; confirmed via the upload progress path against both mod_php and PHP-FPM |
Why does the PHP team rate Apache with mod_php as the riskiest setup? Because after such an abort mod_php simply keeps using the worker, while PHP-FPM terminates the worker process and thereby throws the broken state away. FPM is not entirely off the hook, though, because the second bug was confirmed against FPM as well, according to the PHP Foundation, via code paths in the application. The advisory therefore suggests FPM operators consider pm.max_requests=1, so that two requests can no longer hit the same worker. According to the PHP team, every installation that serves web requests is affected, so mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, according to heise explicitly PHP on Windows too, and according to Wiz every version since PHP 5.4. The fix itself is a monster: the commit “Avoid state corruption via bailout” touches 423 files with more than 11,000 new lines, because PHP has to handle an out-of-memory abort in a fundamentally different way.
How big is the problem?
According to W3Techs, PHP runs on 69.3 percent of all websites whose server-side language is known, as of 21 October. Of those PHP sites, 65.2 percent run on PHP 8, but 27 percent still run on PHP 7 and 7.7 percent on PHP 5, so a good third are on versions for which there are no official releases at all any more. Cisco Talos therefore estimates that roughly half of all PHP systems will never get a patch. Censys, as reported by KrebsOnSecurity, counts 2.58 million hosts with PHP directly reachable from the internet and 54.9 million web properties serving PHP. That is the order of magnitude we are talking about, and it explains why maintenance pages went up from Helsinki to Tokyo.
The timeline: two years, one leak and a Wednesday in a state of emergency
On Wednesday evening the PHP Foundation published a remarkably candid blog post from which the back story can be reconstructed. The first trace of the memory bug reportedly surfaced as early as 2024 during an external audit by Quarkslab, funded by the Sovereign Tech Agency via OSTIF, but exploitability could not be confirmed at the time. On 30 July 2026 the company Calif started an audit as part of the “Patch the Planet” programme, on 11 August it reported code execution with no preconditions and exactly this root cause, and on the same day OpenAI independently reported the same root cause. On 24 August Wiz followed up with further attack vectors, on 18 September OpenAI did so once more. The Foundation admits that the long time until the fix was “a structural failure, caused by both the security team’s decision process and its lack of resources”, and announces that the security team will decide by majority in future, that leadership will step in earlier when discussions stall, and that it is asking hosts, cloud providers and public bodies for sustained funding. On the role of AI it says explicitly: “a person makes every call and works on every patch.” Wiz puts it this way: the bugs had been in the code for decades, but exploiting them required an extremely complex chain, and “Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.” The credits list, alongside Calif, Wiz, OpenAI and Quarkslab, also Alpha-Omega, the Sovereign Tech Agency and Anthropic.
The patch was actually meant to appear on Thursday, 22 October. Then things kicked off on Monday: around 5 p.m. our time the CVE numbers were circulating in forums and on social networks, complete with a wrong date and a wrong CVSS score of 10.0. At 9:30 p.m. the PHP team moved the release forward by a day to Wednesday 4 p.m., “the best compromise”, as the Foundation writes. Around 10 p.m. Calif accidentally published a video with a working proof of concept against several targets, copies of which spread immediately, and at 1 a.m. the mitigation hints that had been sent in advance to operators of critical infrastructure may, according to the Foundation, have leaked as well. According to the BBC, the White House had briefed US federal agencies as early as Friday and worked with the AI labs on the fix. On Wednesday at 5:02 a.m. Cloudflare switched on its WAF rules, nine hours before publication, and reports having seen attack traffic against customers even before that. At 9:34 a.m. hosting partners reported the first attack attempts to Patchstack, at 9:41 a.m. Chainguard published patched container images and thereby broke the embargo, more than six hours before the deadline, which the Foundation comments on with the words “unilaterally broke the embargo” and “disregarded weeks of work by many parties”. At 3:30 p.m., half an hour earlier than announced, the releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were out, at 3:34 p.m. the GitHub advisories went live. Release manager Volker Dusch told heise: “After many weeks of work I am very glad that we got the release out.”
Important for everyone still on older versions: official releases only exist for the four supported branches 8.2 to 8.5. For PHP 7.4, 8.0 and 8.1 the security team has, given the severity, exceptionally provided minimal source code backports in separate branches, but packages from those have to be built by the distributions or hosts. Ondřej Surý, whose packages most Debian and Ubuntu admins know, even ships builds from 5.6 to 8.5, according to Linux Compatible. And do not forget: PHP 8.2 reaches end of life on 31 December 2026.
What the authorities advise: patch or pull the plug
On Wednesday Germany’s BSI raised the alert level to 3 out of 4, orange, and vice president Thomas Caspers was quoted as saying they considered “short-term, large-scale exploitation within a few hours” of the patches appearing to be likely, because attackers with AI-assisted tools can analyse a patch and build an exploit from it in a short time these days. The security advisory contains a sentence you rarely read from the BSI: “Should patches not be installable immediately, the BSI recommends considering a temporary disconnection from the internet, since none of the workarounds provide complete protection against attacks.” Practically everyone else says the same: the US agency CISA writes that anyone who cannot patch immediately or is still running PHP 8.1 or older should take PHP systems offline, the NSA likewise, the UK’s NCSC advises taking systems “offline until it can be fully mitigated”, CERT-EU recommends isolation, CERT-FR wants affected devices isolated and, if necessary, multipart uploads blocked, and CERT.at in Austria wrote as early as Monday at 11:20 p.m.: “If possible, you may also consider shutting systems down.” Switzerland’s BACS sums up why a WAF alone is not enough and why the work continues after the patch: “An update does not remove a compromise that has already happened.” The reason for the unusual bluntness is that the PHP team itself writes that there are no complete mitigations, only the update is safe. Before you dismiss this as scaremongering: heise writes that an attack does not succeed on the first attempt but needs several thousand to tens of thousands of requests, yet according to the same report Calif executed system commands on a Laravel server after 38 seconds.
Germany: from the Interior Ministry to the police’s online station
That is what Wednesday looked like here, accordingly. At federal level, the Interior Ministry, the Federal Police, the RKI and customs were unreachable at times. Bavaria switched off numerous state websites, including ministries and police, and the spokeswoman of the State Office for Information Security called it “a pure precaution”, there were “no signs of a hacker attack”; in the evening bayern.de announced via Instagram that the restrictions had been lifted. Baden-Württemberg took its state government, ministries and regional councils offline for several hours, Interior Minister Hagel: “We must therefore be able at any time to take exposed systems offline at short notice in the event of acute threats.” Hesse and Thuringia suspended their state portals and ministries, plus the state offices for the protection of the constitution in Bavaria, Hesse and Thuringia. In Berlin it hit the state websites via the ITDZ, the state parliament, the fire brigade and the police’s online station, which tersely told its citizens: “In an emergency, please dial 110.” Among the municipalities, Mainz (“only affects the external web presence”), Dresden (“probably until Thursday”), Cologne, Düsseldorf, Schwerin, Munich, Augsburg, Potsdam, Halberstadt and the district of Dahme-Spreewald took their portals offline, and Deutschlandfunk reported in the evening simply: “Municipalities switch off internet services as a precaution.” At 10 p.m. Mainz, Dresden, Cologne, Düsseldorf and Schwerin were still dark.
Update Thursday, 22 October, 8:30 a.m.: Cologne and Düsseldorf are reachable again, as are the Federal Police, the Berlin fire brigade and the Berlin police. Mainz, Dresden and Schwerin are still offline, the district of Dahme-Spreewald still reports “access restricted”, and the city of Munich’s online services are, according to its town hall page, still unavailable.
Among the hospitals, the Charité went first, switched off its website and online appointment booking and stressed through its spokesman Markus Heggen that this had “no influence whatsoever on the work of the Charité”, the updates were to be installed by Thursday; in the evening the main site was back. It was followed by Vivantes (“Medical care in all our hospitals is fully assured”), the MHH Hannover, the Harzklinikum in Saxony-Anhalt, the university hospitals of Freiburg, Heidelberg and Mannheim, the Augsburg university hospital, the Nuremberg hospital and the Ernst von Bergmann hospital in Potsdam. The universities were particularly rigorous: the University of Hamburg switched off “all online services of the university that work on this basis”, RWTH Aachen made its services reachable only via VPN, the University of Mannheim took website, intranet, bwSync&Share and online applications offline, TU Dresden listed two dozen services in its status page, from Datashare via eduVPN to Matomo, as “unavailable until further notice”, Münster disconnected ILIAS and sciebo, Göttingen website, StudIP and newsletter, with the honest reasoning: “It is quite possible that this situation will be exploited in the coming days.” Added to that were the University of Freiburg, Potsdam, Kiel, Konstanz, Regensburg (“This is purely a precautionary measure, there are no indications whatsoever of an attack!”), the Ruhr University Bochum, the HU and FU Berlin and the WZB.
Update Thursday, 22 October, 8:30 a.m.: Charité, Vivantes, the University of Regensburg and the University of Potsdam are back. The MHH Hannover still shows “Service Unavailable”, the universities of Mannheim, Göttingen, Kiel, Konstanz and Bochum remain on their emergency or maintenance pages, and the University of Hamburg still points to the switched-off services on its home page.
Media and companies were hit as well. golem.de showed a 503 page all afternoon and evening, zeit.de was black at times, the invoicing software easybill, Checkmk and the SPD parliamentary group went into maintenance. ComputerBase, on the other hand, had, as the colleagues themselves write, “already taken precautions during the night” and was running on PHP 8.5.12 by 4:50 p.m., barely an hour after the release, but left its block on VPN access in place for now.
Update Thursday, 22 October, 8:30 a.m.: golem.de and easybill have been back online since the night, the SPD parliamentary group is still on its maintenance page.
Austria and Switzerland: universities, Voestalpine, Vienna’s public transport
In Austria the Interior Ministry circulated the CERT.at warning “in coordination with the new Federal Office for Cybersecurity”, and the universities reacted as in Germany: the University of Vienna (Moodle, u:cloud, webmail), WU, BOKU, MedUni Wien, JKU Linz and the University of Innsbruck together with the Innsbruck municipal utilities took services offline. Added to that were Voestalpine, whose website was still reporting late in the evening that updated and verified systems were coming back “progressively”, Novomatic, Cineplexx, the Chamber of Labour, the Burgenland state portal, the ÖAMTC, the city of Wels, the Wels-Grieskirchen hospital, Caritas, the NÖN newspaper and the real-time data of Wiener Linien, whose app failed, “but all the buses and trams are running normally”. In Switzerland the University of Geneva switched off, the EPFL suspended access to all of its websites “pour procéder aux vérifications de sécurité nécessaires”, the accounting software bexio paused completely, watson locked itself down for the most part and the host cyon took all of its customer sites offline. SRF editor Jürg Tschirren summed up the situation in the early evening: “There are no confirmed break-ins so far.”
Update Thursday, 22 October, 8:30 a.m.: NÖN, Voestalpine, the city of Wels, JKU Linz, bexio, the EPFL and watson are back. MedUni Wien, the Burgenland state portal and the University of Geneva are still offline.
Europe: The Hague, Helsinki, Copenhagen, Swindon
It was even more drastic in the Netherlands, where NOS ran a live blog all day. At 12:48 p.m. DigiD and MijnOverheid went offline, shortly afterwards the Tweede Kamer, the NCSC-NL and the data protection authority themselves, the portals of NotuBiz, through which more than a hundred municipalities publish their council information, the broadcaster RTL including its app, Tweakers, the football association KNVB with several first-division clubs, the Schiphol app, half a dozen hospitals, the charities from Amnesty to Oxfam and several political parties. The deputy director of the NCSC-NL, Corine Schipper-Derkse, put it in a nutshell in the live blog: this was “not so much an attack as a design flaw”, and people should install the patch so that the hole is plugged. In the evening most of them came back, MijnOverheid at 6:11 p.m., DigiD at 8:27 p.m., the Tweede Kamer around 9:30 p.m., overheid.nl was still dark as I wrote these lines.
In Belgium, Flanders switched off all government websites and the parliament, plus the foreign ministry, the school platform Smartschool, the Roularta magazines, parts of DPG Media and the Antwerp hospital AZ Monica, even the website of the cyber centre CCB was gone. Finland’s state IT provider Valtori took the government’s public web services offline completely, from the land registry via Oikeus.fi and the Meteorological Institute to the National Archives, and justified this by saying it only had a partial list of the affected services and would rather switch off broadly; parts of Yle were gone too. In Denmark, Kombit closed the school platform Aula, the weather service DMI switched off its digital services, library systems and the payment of social benefits were partly affected. France put the sites of the prefectures into maintenance, in the UK the councils of Swindon (“a precaution because of a worldwide issue with the underlying technology and is not a cyber incident”) and Edinburgh went offline and even individual programme pages of the BBC were unreachable. The CERTs of Sweden, Italy, Spain and Poland issued identical warnings, and ENISA lists the advisories of all 27 national CSIRTs in a joint notice.
Update Thursday, 22 October, 8:30 a.m.: NOS closed its live blog on Wednesday at 9:05 p.m. In the meantime overheid.nl, the Tweede Kamer, DigiD, MijnOverheid, the NCSC-NL, the KNVB, the Flemish government, Smartschool, Aula, the Danish weather service and Swindon Borough Council are back online. The Finnish land registry Maanmittauslaitos still shows a maintenance page.
And the rest of the world: Canada, Tokyo, Wikipedia
In the US the federal sites stayed online according to Newsweek, but Pinboard, Something Awful, DeviantArt and 4chan went into maintenance, 4chan has been read-only ever since, “while we await an urgent PHP security update”. The Wikimedia Foundation switched off Toolforge, Cloud VPS, Wikibase Cloud and temporarily Phabricator, and from 5 p.m. also confirmed outages of the wikis themselves, because volunteer-run services can only come back once their operators have dealt with the PHP version. Canada’s minister Evan Solomon confirmed that some federal websites were offline “as a precaution to protect government systems and Canadians’ information”, the economics ministry ISED among them, and Rajiv Gupta of the Canadian Cyber Centre simply called PHP “ubiquitous”. In Australia, of all sites, cyber.gov.au, the website of the cyber security agency, reported outages. And in Japan Prime Minister Sanae Takaichi asked the authorities to check whether their sites use PHP, while the games industry went into emergency maintenance one after the other: Square Enix blocked new logins to Final Fantasy XIV on all worlds and took the patch servers offline, Cygames sent Umamusume, Granblue Fantasy, Shadowverse and Princess Connect into maintenance, Pokémon Sleep, Pokémon HOME and Pokémon Champions followed, as did Sega with CHUNITHM, Bandai Namco ID and Niconico. Plus the host Sakura Internet, the shop platforms BASE and Color Me Shop and the nursery software Kodomon.
Update Thursday, 22 October, 8:30 a.m.: Something Awful, Pinboard and DeviantArt are back, 4chan sits behind a verification page whose status cannot be judged. Canada’s economics ministry ISED still reports “Service Unavailable”. At Wikimedia, Phabricator, translatewiki and doc.wikimedia.org are back, while Cloud VPS, Toolforge and all Wikibase Cloud instances remain offline according to Wikitech (as of 3:32 a.m.), because every operator there has to deal with their own PHP version.
Hosts: who has patched, who is still dark?
For most of you this is the question that actually matters, because anyone with a shared hosting plan cannot patch anything themselves but has to wait for the host to do it. Here is the state of play on Wednesday around 10 p.m., compiled from the status pages and from the reader comments at Günter Born and Caschy, which I mark as such because they do not come from the providers themselves:
| Host | Status Wednesday, 10 p.m. |
|---|---|
| Mittwald | All customer websites offline since the afternoon, only e-mail running; 9:28 p.m.: patches being rolled out, most systems should be back “by midnight”, first checks show no signs of exploitation; no solution yet for PHP 5.6, 7.0, 7.1 and 8.0 |
| netcup | Web hosting and managed servers taken off the net from 4:25 p.m. (“To protect you and your data, we have disconnected all potentially affected systems from the internet as a precaution”); 9:02 p.m.: managed servers complete, web hosting 60 percent patched and back online; root servers and VPS have to patch themselves |
| Hetzner | Patches for PHP 7.4 and 8.0 to 8.5 installed on all web hosting and managed servers, older versions in progress |
| IONOS | Nextcloud instances deactivated as a precaution since 2:26 p.m.; rollout of the PHP update since 5:44 p.m. with short outages, completion “within the next 24 hours”; one reader reported his site back on 8.3.36 at 6:33 p.m. |
| Profihost | Exemplary transparency: 10:36 a.m. information, 12:30 p.m. workarounds, 8:20 p.m. “8.2, 8.3, 8.4 and 8.5 have been updated across the entire Profihost infrastructure”, 5.6 to 8.1 not yet |
| manitu | 8:50 a.m. maintenance announced, 12:10 p.m. form uploads blocked, 8:05 p.m. all relevant systems updated, upload block stays for now |
| Timme Hosting | 3:31 p.m. all websites and ISPConfig interfaces deactivated because of reported active exploitation, 7:24 p.m. PHP 8.2 to 8.5 patched and released again, older versions remain on a maintenance page |
| Strato | No official notice found; patched at 7:10 p.m. according to a reader comment |
| all-inkl | Customer portal and home page unreachable in the evening, KAS login worked; according to a comment, webspaces were still running PHP 8.4.24 at 7:27 p.m. |
| DomainFactory | 6:46 p.m. restart of application services, 8:48 p.m.: “We are aware of the PHP vulnerabilities and have taken protective measures”; still unpatched at 8:09 p.m. according to a comment |
| checkdomain, Alfahosting, dogado | Identical status messages from the dogado group from 3:34 p.m.: installation “with the highest priority” |
| webhostone, webgo | webhostone reports the patches as deployed on all shared and managed systems, webgo is installing them according to its banner |
| Uberspace | PHP switched off completely at 3:45 p.m. according to heise, until the patches arrive |
| Host Europe | Status page: “Hosting maintenance” since 6:46 p.m., services are being restarted |
| easyname (AT) | Status from 9:34 a.m., 4:27 p.m. installation “with the highest priority”, webspace customers need do nothing |
| cyon, Metanet, Hostpoint, Infomaniak (CH) | cyon all websites offline until about 10 p.m.; Metanet patches shared and managed itself; Hostpoint without a notice; Infomaniak with protective measures in hosting until Thursday 3 a.m. and restricted file transfer at SwissTransfer |
| Kinsta, Cloudways, SiteGround, Laravel Cloud, Craft Cloud | Kinsta had its own sites on 8.5.12 at 4:38 p.m., PHP 8.3 customers were still waiting; Cloudways and SiteGround with interim protection; Laravel Cloud and Craft Cloud patched automatically, Laravel Forge customers have to do it themselves |
| Plesk, cPanel/CloudLinux, DirectAdmin, ISPConfig | Plesk ships updates for its PHP versions, CloudLinux patches alt-php 7.4/8.0, DirectAdmin offers 8.2.35 to 8.5.12 plus its own 7.4/8.0/8.1 backports, ISPConfig points to the PHP update and offers a temporary multipart block |
Three things stand out. First, speed does not depend on the size of the host, Hetzner and Profihost were done while Mittwald was still completely dark. Second, the comments at BornCity and Caschy show that some hosts were still serving old versions at 7 or 8 p.m., even though the patches had been available since 3:30 p.m., and that with a vulnerability where the BSI expects exploitation “within a few hours”. Third, switching off turned out to be the more honest option: those who took everything off the net like netcup, Mittwald, Timme or cyon imposed a few hours of downtime on their customers but left no window for attackers. By the way, anyone wanting to know whether their host is done should not trust the PHP version number in the customer panel, because distributions and hosts often backport fixes into existing package versions without changing the number.
Update Thursday, 22 October, 8:30 a.m.: netcup reported all web hosting plans as patched and online at 11:45 p.m., the web hosting control panel followed at 4:09 a.m. after a Plesk update, status “resolved”. Mittwald set its incident to “resolved” at 0:28 a.m., nearly all PHP versions are secured, only for versions below 5.6 is a solution still being sought. Hetzner has meanwhile patched PHP 5.6 and 7.3 on all web hosting and managed servers as well, Timme Hosting all versions from 5.6 to 8.5 since 10:20 p.m. IONOS released the Nextcloud instances again at 10:55 p.m., the security maintenance for web hosting, WordPress hosting and MyWebsite was still running at 6:53 a.m. DomainFactory has not published an update since 8:48 p.m., shared and web hosting are still “Under Maintenance” and the home page was unreachable in the morning. At Profihost PHP 5.6 to 8.1 are still unpatched, manitu keeps its upload block in place for now, Host Europe still lists the hosting maintenance as open, Infomaniak keeps file transfer at SwissTransfer and kSuite restricted (update 8:11 a.m.). The home pages of all-inkl, Uberspace, Hostpoint and Mittwald are running normally again.
And the blogosphere?
Being a blogger myself, I went through around 80 German and English blogs in the evening to see how things look there. The short version: the blogosphere is alive, but a few deliberately pulled their own plug. ifun.de and iphone-ticker.de went offline at 4 p.m. at their host’s decision, with the lovely reasoning that one would “briefly pull the plug before someone else does it for us”, and the 16 comments underneath consist mainly of crossed fingers. LinuxNews.de announced maintenance from 3:50 p.m. at 11:24 a.m. and was back, patched, 25 minutes later (“patching just takes its moment”). Particularly worth reading is the report by kernel-error.de, who runs his blog on FreeBSD jails: he stopped nginx before there was even a patch, then found that the binary package was still on 8.3.35 while the ports tree had the fix within minutes, built PHP including 43 extensions himself, stumbled over a missing CA bundle and afterwards searched through 15 days of logs. His lesson: a new version number does not prove the right fix, a new binary does not prove that the service uses it, and a green configuration test does not prove that the site works. Caschy, Günter Born (with more than 80 comments the best situation report on German hosts), Deskmodder, Dr. Web, Sir Apfelot, t3n, netzwelt, Apfeltalk and Notebookcheck all reported the same afternoon, WinFuture’s headline was apt: “No end of shift for admins”. Sir Apfelot, an All-Inkl customer himself, adds the important hint that maintenance mode plugins and WordPress’s .maintenance file are no use here because PHP has long since processed the request by then, the block has to happen via .htaccess or on the web server. Conspicuously quiet, on the other hand, were of all things the WordPress trade blogs: WP Tavern had not a single post by the evening, nor had the Wordfence blog, and at perun.net, Pressengers, WP Ninjas and Elmastudio there was nothing on the home page. golem.de was still dark at 10 p.m., with an outage page on which, according to a Mastodon user, the copyright still says 2014 and there is a Google+ link, and mwop.net, the blog of Laminas maintainer Matthew Weier O’Phinney, showed “Site Maintenance” too. Anyone blogging on WordPress.com or Tumblr was protected throughout according to Automattic, and anyone writing on Blogger, Ghost, Substack or Medium has nothing to do with PHP anyway.
Update Thursday, 22 October, 8:30 a.m.: ifun.de, iphone-ticker.de, LinuxNews.de, kernel-error.de, golem.de and mwop.net are all back online.
It was really loud on Mastodon. On mastodon.social alone, 200 posts with the hashtag #php2shell came in between 6 and 10 p.m., around 50 per hour, and on mastodon.online and tchncs.de another 40 each arrived in the last hour. Torsten Landsiedel from the German WordPress community summed up his day under #PHPocalypse: “I had imagined my holiday on the North Sea differently … all-inkl.com completely down, DomainFactory reachable but no update in sight. What are your experiences with your hosts?” The replies underneath are a small ranking of hosts from a developer’s point of view: Uberspace the fastest reaction, albeit with a forced upgrade from 8.1 to 8.2, netcup and Hetzner slower but informative, all-inkl with Instagram as its only information channel, webgo and checkdomain still on 8.4.26 at 9:40 p.m., a small host patched and online at 5:30 p.m. (“a gift basket is in order”), and a developer who had his own servers sorted “within minutes” but found “nothing to see so far” at the hosts. “Netcup also feel like the only ones who manage to keep customers informed”, wrote another, and got the most favourites of the evening for it. At Strato and IONOS one user still reported old versions at 5:22 p.m. and completion at 8:07 p.m., at all-inkl a terse “is done. Thanks!” arrived at 9:03 p.m. Less enthusiastic were Hetzner’s Nextcloud customers (“my Nextcloud has now been offline for 6h”, “What do I look like, an Office 365 customer?”), one admin waited three and a half hours for Hetzner’s Ubuntu mirror to sync the security updates at all, and Docker users counted the “long minutes” until the official images finally arrived, at 8:07 p.m. one cheered: “The official WordPress image on Docker Hub JUST updated to PHP 8.3.36!” In between, gallows humour (“I’m so glad my websites still run on Flash Player”), relief (“today we are really glad we switched off our old WordPress stack”) and operators who simply locked their sites: “Locked all my blogs and websites for now. Of my home office containers apparently only BookStack is affected.”
On Hacker News the Wiz post had collected more than 400 points and 160 comments by the evening, and the mood there is distinctly more sceptical than in the press releases. The most-discussed question was why two months passed between report and fix, the second most common whether “AI found it” is not mainly marketing, one commenter scoffed that the find was being marketed “as if it were the first RCE found in human history”, another commented on the 70 percent figure with “that’s my depressing statistic for the day”. In the thread on the delayed Docker images the spectrum ranged from “Never using docker hub ever again” to the sober observation that most PHP users get their PHP as a distribution package anyway and that exactly this route needed the work and got it. Worth reading from the PHP world itself: Alexandre Daubois from the PHP Foundation’s security team wrote up on his blog what was wrong about the rumours, the CVSS score was never 10.0, watchTowr listed a PHP 6 that never existed, the most-shared workaround applied to the wrong CVE and the one named first in the advisory, memory_limit=-1, did not appear in any of the articles. Nick Rogers argues on Substack that PHP2Shell had long been “in the training data”, because Stefan Esser described the mechanism as early as 2004, a bug report from 2019 touched on it and the 2024 audit found it, and that AI did not discover the vulnerability but lowered the cost of turning a known memory bug into an exploit. OpenAI, meanwhile, has put a small version checker called php2shell-checker on GitHub, which however only evaluates headers and php -v and itself warns that “UNKNOWN” does not mean “patched”, Wiz runs the information site php2shell.com, Josh Bowen describes how he patched his old PHP 7.4 containers himself with the backport branch, and Steve Grunwell, who lifted a 20-year-old PHP application to PHP 8 at Mailchimp, boils it down to the sentence that applies to everyone today: “Running a PHP application means regular upgrades.”
Platforms, containers and appliances: who else is affected
Automattic declared in the afternoon that WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr were “already protected”, customers need do nothing. WordPress.org itself made clear through John Blackbourn that the vulnerabilities are “not specific to WordPress”, that no WordPress update is required or planned and that operators of their own servers on PHP before 8.2 should consider taking their site offline. Drupal published a PSA along the same lines, Matomo declared its cloud protected and reminded on-premise users that a Matomo update does not fix the vulnerabilities, Laravel patched its cloud automatically, required a redeploy for Vapor and manual work for Forge. Nextcloud has no blog post but a pinned GitHub issue and a new All-in-One image 14.4.1 with patched PHP. From TYPO3, Joomla, Shopware and Magento I had found no statements of their own by the evening.
Among the distributions, Debian (8.4.27 for Trixie, 8.2.35 for Bookworm) and Ubuntu (all supported releases back to 14.04 via ESM) delivered in the afternoon, AlmaLinux had test packages at 5:11 p.m., Red Hat by 7:50 p.m. only the package for PHP 7.4 on RHEL 8, and the Remi repository that many use on the CentOS successors got no update at all on Wednesday, which php.net specifically pointed out. The official Docker images only appeared in the evening, after the corresponding pull request had been locked because of a heated discussion. It gets really unpleasant with devices that have a PHP interface: Palo Alto Networks confirms that PAN-OS 10.2 to 12.2 and Panorama are vulnerable, a fix has “ETA: TBD”, until then the management interface is to be locked down. Sophos declares its products unaffected but has taken the old MyUTM portal off the net because it used a vulnerable PHP version. For Synology, QNAP, pfSense, OPNsense, FortiADC, F5 BIG-IP, Citrix NetScaler and Juniper J-Web the product list of the Dutch NCSC says “Investigation” everywhere, and heise additionally names routers from DrayTek, ZyXEL, D-Link, TP-Link, Netgear and Tenda. Anyone who has such a device with a web interface hanging on the internet should lock the interface down now and wait for firmware.
Is the vulnerability already being exploited?
Yes and no, depending on whom you ask, and I took the trouble of laying the statements side by side. Cloudflare reports attack traffic even before publication and says attackers are constantly changing their payloads to get around the WAF rules. Patchstack reported at 9:34 a.m. that hosting partners had reported several active attacks, but qualified that at 3:57 p.m. to “only probing attacks, with no hard evidence of breaches yet”. Hadrian spoke of exploitation “at scale”, most attempts via the upload progress path, watchTowr saw the first attempts in its honeypot network practically at the same time as the patches and writes that nobody has been successful so far, but that it does not expect that to last long. The NCSC-NL reports massive automated scans by botnets within a few hours of the leak. On the other side are Huntress, Imperva, Check Point and Cisco Talos, who had seen nothing well into the afternoon, CISA, which had observed no exploitation at the time of its notice and did not add the CVEs to its catalogue of exploited vulnerabilities, the BSI, which speaks of unconfirmed reports, and Mittwald, which after initial checks found no signs of exploitation on its systems. Nobody had reported webshells found by the evening, and not a single one of the sources gives hard numbers on requests or IPs. In short: there is massive scanning and probing, it has not yet been proven that anyone has succeeded, and that is exactly the window in which you should patch.
And at my place? Docker images, logs and a five-hour window
My sites run as Docker containers with the official image wordpress:php8.3-apache on a VPS at netcup, and with a VPS what netcup says clearly on its status page applies: the update is my business. The problem with Docker is that you cannot simply type apt upgrade but have to wait until the Docker team rebuilds the base image and then builds the WordPress image on top of it. The php:8.3-apache image arrived around 7:24 p.m., the WordPress image around 8:40 p.m., and at 8:48 p.m. bitpage.de was running on PHP 8.3.36. So that was roughly five hours after the release during which the site was attackable, and almost two days since the leak on Monday. The same game with Matomo, which went to 8.4.27.
# back up the old image, pull the new one, recreate the container
docker tag wordpress:php8.3-apache wordpress:php8.3-apache-prev-20261021
docker pull wordpress:php8.3-apache
docker compose up -d # or docker rm + docker run with the old parameters
# check
docker exec wp_bitpage php -v
PHP 8.3.36 (cli) (built: Oct 21 2026 15:57:18) (NTS)I have to be honest: during those five hours I did not implement any of the workarounds but relied on Wordfence and the sheer number of requests required being enough, and that was more hope than plan. Afterwards I at least checked whether anyone had tried anything during that time. The logs of the nginx proxy in front show not a single rejected upload for 19 to 21 October, no accumulation of 500 errors apart from the usual scanners that call wp-settings.php directly, and no requests with the patterns that Wiz names as indicators. There is no foreign PHP file in wp-content/uploads, and Wordfence has blocked 47 requests since Monday, all routine such as directory traversal and known bot signatures. What I did learn, though: when the container is recreated, WordPress’s Apache log is gone, and that is exactly where the “Allowed memory size exhausted” messages that give away an attack attempt would have been. So anyone using Docker should collect the logs outside the container before the next incident comes along.
What you need to do now
The most important thing first: a WordPress update, a plugin update or a theme update does not help here at all, because the vulnerability sits in the PHP runtime. Wordfence points out that WordPress’s automatic updates cannot install this fix, and Patchstack explicitly warns against the “fix plugins” and code snippets currently circulating in forums, because they fix nothing and can break the site. So:
- Check the version. On your own server
php -vordocker exec <container> php -v, on a hosting plan in the customer panel or viaphpinfo(). You are safe from 8.5.12, 8.4.27, 8.3.36 or 8.2.35. For distribution packages the package version applies instead: Debian 13 has the fix in php8.4 8.4.27-1~deb13u1, Debian 12 in php8.2 8.2.35-1~deb12u1, Ubuntu 24.04 in php8.3 8.3.6-0ubuntu0.24.04.13, Ubuntu 22.04 in php8.1 8.1.2-1ubuntu2.28. After the package update, be sure to restart PHP-FPM or Apache, otherwise the old code keeps running. - Check with your host. Look at the status page, when in doubt ask support whether the fix is installed, not just planned. An unchanged version number does not automatically mean unpatched, but an old number like 8.4.24 without a host suffix is a bad sign.
- Docker and appliances. Pull images anew and recreate containers, and with derived images such as Nextcloud or Matomo make sure that they too have already received their base image. Plus everything that comes with a PHP interface: Nextcloud, NAS from Synology and QNAP, pfSense and OPNsense, firewalls from Palo Alto, router interfaces. There only a firmware update from the manufacturer helps, until then do not hang the interface on the internet.
- PHP 8.1 and older. There are no official releases for those any more. Either the distribution delivers a backport, or you take the packages from Ondřej Surý, or you use the occasion to jump to 8.3 or 8.4. Anyone who cannot do that immediately should, according to WordPress.org, CISA and the NCSC, take the site offline until then.
- Workarounds only as a stopgap. If you really cannot patch, the following settings reduce the attack surface, but the PHP team says explicitly that they do not make an installation safe. They belong in php.ini, the FPM pool or the Apache configuration, not in
ini_set()or a.user.ini, and afterwards all workers must be restarted. With PHP-FPM,pm.max_requests=1helps additionally, with nginx or a proxy in front, blocking multipart uploads, as CERT-FR and some hosts did temporarily.
; CVE-2026-109618
memory_limit = -1 ; via php_admin_value, so nobody can override it
post_max_size = 8M ; without file uploads, with uploads 32M
upload_max_filesize = 8M ; must stay smaller than post_max_size
; CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; PHP 8.5 onlyAnd once the patch is on, the work is not over, because, to quote the BACS once more, “an update does not remove a compromise that has already happened”. Look in the logs for unusual multipart POSTs shortly followed by “Allowed memory size exhausted” errors or series of HTTP 500, for conspicuously large PHPSESSID cookies in the responses and for PHP workers that keep restarting or, as CISA puts it, suddenly spawn shells and download tools. Use find /var/www -name '*.php' -newermt '2026-10-20' to search for PHP files that are new since Monday, especially under wp-content/uploads, and run Wordfence or a comparable scanner once in full. Anyone running Snort or Suricata gets the rules 67359 and 67360 from Cisco Talos in the community ruleset. And because the vulnerabilities can also disclose memory contents, Patchstack advises rotating credentials and API keys on any suspicion. If you find something, the usual order applies: site offline, restore a backup from before the leak, renew all passwords, keys and salts.
Conclusion
In more than ten years of blogging I have not seen a day on which so many authorities, hospitals, universities and hosts voluntarily pulled the plug at the same time, from the Berlin police’s online station via the Finnish government to Final Fantasy, and I think they were right to do so. When the PHP team itself says there is no complete workaround and the BSI expects exploitation within hours, a maintenance page for a few hours is the lesser evil compared to a webshell on the server. Three things strike me as remarkable: that a bug that has been in the code for decades and had already knocked once in 2024 only became a practicable exploit through AI models, that the PHP Foundation names its own failure so openly and asks for money even though two thirds of the web run on its work, and that the vulnerability does not hang on WordPress, Joomla or any plugin but on the language itself, so that the whole chain from the distribution via the host to the Docker image has to be run through before a single site is safe again. At my place that took five hours, and that was with constant checking.
So my advice: check your PHP version or your host’s status today, seriously take sites on PHP 8.1 or older off the net until you have a backport or a new version, lock down the web interfaces of firewalls and NAS devices, and look in the logs once after the patch. And anyone who uses Docker like me should keep the logs outside the containers from now on.
How was it for you? Which host was fast, at which one did your site hang in maintenance all evening, and have you found attack attempts in your logs? Let me know in the comments, I will gladly update the host table as soon as something changes.
Sources
- PHP: Critical remote code execution vulnerabilities, update now with the official workarounds, plus the advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp
- PHP Foundation: Today’s PHP security release and how we’re strengthening PHP security with the timeline since 2024
- Wiz: PHP2Shell, AI uncovers critical RCE vulnerabilities with the technical analysis and the indicators
- BSI press release and BSI security advisory 2026-297981-1132; CISA, UK NCSC, CERT-EU 2026-018, CERT-FR, CERT.at, BACS, ENISA CNW-2026-04
- Born’s IT and Windows blog: php2shell with many reader reports on hosts, Caschys Blog, Deskmodder, ComputerBase
- heise: php2shell, teltarif: authorities offline, Tagesspiegel: Berlin websites offline, diebayern.de, oe24, Blick, SRF
- NOS live blog, Brussels Times, Yle, DR, BetaKit (Canada), NBC News, KrebsOnSecurity with the Censys figures, ITmedia (Japan), ABC (Australia)
- Cloudflare, Patchstack, SecurityWeek, Cisco Talos, Huntress
- Automattic, WordPress.org, Drupal PSA, Matomo, Laravel News, Nextcloud issue, Palo Alto Networks, Sophos, NCSC-NL: list of affected software
- Blogosphere: ifun.de, LinuxNews.de, kernel-error.de, Sir Apfelot, Dr. Web, Alexandre Daubois: What the PHP2Shell rumors got wrong, Dead Neurons: PHP2Shell was in the training data, Josh Bowen: Patching PHP 7.4, Steve Grunwell, openai/php2shell-checker, Hacker News thread, Torsten Landsiedel on Mastodon
- Wikitech: Incidents/2026-10-21 PHP security update and Diff: Impact of PHP vulnerabilities on Wikimedia tools
- Status pages of netcup, Mittwald, Hetzner, IONOS, Profihost, manitu, Timme Hosting, DomainFactory, Infomaniak
- Debian Security Tracker, Ubuntu CVE tracker, W3Techs: PHP usage, Wikipedia: PHP2Shell
Featured image: Tim Mossholder on Unsplash. I took the screenshots of the status, maintenance and Mastodon pages myself on 21 October 2026 between 9 p.m. and 10:30 p.m. This is the English version of my German post; all times are CEST.
This post is also available in: 
Deutsch
