<strong>What happened, in the order it happened
Start with the number that sets the scale. PHP is the server language of 69.3% of websites whose language is known, as of today (W3Techs). It is the engine under WordPress and WooCommerce, Magento, Drupal, Joomla, most portals and most of the quiet business software nobody thinks about. So picture the person who runs your marketing. There is a company store a vendor operates, a dealer portal somebody built in 2019, a media producer with your artwork on a WordPress site, and a marketing-email system holding your whole customer list. She has never asked what any of them run on. Nobody has ever told her she should. Most of them run on PHP, and this is what happened to that engine this week.
Monday, 20 October, about 11 a.m. Eastern. Two CVE numbers for unreleased PHP flaws appeared on forums and social media, with a wrong release date and a severity score of 10.0. No technical detail leaked, but the existence of the flaws was now public. The PHP Foundation moved its pre-announcement up to 3:30 p.m. Eastern: fixes tomorrow, "All PHP users are encouraged to prepare now."
Monday, about 4 p.m. Eastern. Calif, one of the firms that found the flaws, mistakenly published a video of its proof of concept running against real applications. It was deleted. Copies had already spread, and the Foundation later said the video "contributed to accelerated development of various PoCs." watchTowr reproduced one flaw the same evening.
Tuesday, 3:02 a.m. UTC. Cloudflare, which sits in front of millions of other people's websites as a proxy and firewall, switched on rules to catch the attack for every customer, about nine hours before the fix existed. Those rules protect PHP servers that customers run elsewhere and route through Cloudflare; sites built on Cloudflare's own platform have no PHP and were never in the picture. Within hours Cloudflare saw attackers "mutating the attack payload to try to bypass our protections," and its chief technology officer called the rules a stopgap until the patch.
Tuesday, 7:41 a.m. UTC. Chainguard, a container vendor, published images with the fix built in, more than six hours before the coordinated release. The Foundation's words: it "disregarded weeks of work by many parties toward a coordinated disclosure" and let attackers study the patch in binary form while everyone else waited.
Tuesday, 7:43 a.m. UTC. Cloudflare's network recorded the first exploitation attempts, aimed at customers' PHP servers behind its proxy. Cloudflare was the lookout, not the target: it is the one place with a view of enough of the web's traffic to see the attacks start.
Tuesday, 14:00 UTC, 10 a.m. Eastern. The PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, a day earlier than planned. The advisory says the flaws allow an attacker to run commands on the server "before any application code runs," with no password, on "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed," the risk "highest for mod_php." Sansec, which has tracked attacks on online stores for a decade, wrote at the same hour: "We expect mass exploitation now that the patch and the writeups are public." By 14:19 UTC watchTowr's honeypots were reporting exploitation attempts against both flaws. (PHP security advisory, PHP Foundation, Cloudflare, Sansec, watchTowr, SecurityWeek)
Tuesday, all day. Every website on PHP 8.1 or older learned that the fix does not apply to it. That is more than one PHP website in three by W3Techs' count, and about half by Detectify's. The only hard census of machines, Mallory's Shodan count on Monday night, found 883,717 servers announcing an unfixable version, and that is a floor: another 740,000 hide their version, most servers send none, and one shared-hosting server carries hundreds of sites. VirusTotal's estimate of exposed PHP hosts is 5.1 million. (Mallory, The Record, BleepingComputer)
Tuesday, 12:40 p.m. Eastern. CISA published its alert, "Critical Vulnerabilities in PHP Require Immediate Patching": "Apply the patch immediately, prioritizing internet-facing systems." Organizations that cannot update at once, or that still run PHP 8.1 or earlier, should "take PHP-based systems offline until they can be patched or updated." A web application firewall "may provide some protection" in the meantime, which is the agency's way of saying what section 1 says below about Cloudflare. CISA also said it had not itself observed exploitation at the time of publication, and as of this evening the flaws are not yet in its Known Exploited Vulnerabilities catalog; when they are added, federal agencies get a dated remediation deadline and most large buyers' procurement questionnaires follow within weeks. (CISA alert)
The sort, before anything else. Whether this touches your own site depends on one question: does the site run PHP? Sites built on Cloudflare Pages or Workers, Shopify, Squarespace, Wix, Webflow, or any static or hosted platform that does not run PHP are not affected, because there is no PHP there to exploit. Sites on WordPress, WooCommerce, Magento, Drupal, Joomla, a Laravel portal or ordinary shared hosting are. One distinction matters, because "on Cloudflare" means two different things. A site built on Cloudflare Pages or Workers runs no PHP and is exempt. A PHP site that merely routes through Cloudflare's proxy, or any other firewall, is not: the engine still sits on the origin server, the firewall can only recognise and block the attack shapes it knows, and Tuesday showed attackers changing shapes within hours. The firewall slows the attack; it does not remove the flaw. Exempt means the engine is not there.
The thirty-second check. On a WordPress site, Tools, then Site Health, then Info, then Server, shows the PHP version. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A WordPress update, a plugin update or a security plugin does not apply this fix; only the host, or whoever runs the server, can. Some Linux distributions ship the fix without changing the version number, so the host's own word, or the package changelog, is the only reliable source (Meow Apps).
How it was found, and how long it had been there
The flaw is not new. The vulnerable code has been in PHP since version 5.4, released in 2012; Wiz's phrase is "every PHP version released in the last decade is affected by at least one of these vulnerabilities." It was found twice in one month, both times by small teams working with AI models.
Ryan Austin of Calif, a California security firm, was invited into OpenAI's Patch the Planet program and began auditing PHP around 30 July. "Only a few days after starting the audit," his write-up says, the first bug surfaced, on 1 August; Calif reported it to PHP on 11 August and began coordinated disclosure. Wiz Research, four researchers in Israel, found the same class of flaw independently on 19 August, confirmed it against Drupal on the 20th and WordPress on the 21st, and reported on the 24th. OpenAI's Codex Security team joined the work. Wiz's own assessment of what the models changed: "a single researcher completed in a week what previously would have taken a world-class team months of work." Calif's is drier: "'know your target' is still as applicable as ever," and "No model is simply capable of unearthing" every bug "with simple prompts." (Calif, Wiz)
The sharpest reading of what the models actually did comes from a security essay published Tuesday: every ingredient was already public. The underlying technique was described by Stefan Esser in 2004, a related bug was filed in 2019, and the audit flagged the area in 2024. What changed is the cost of turning a known, tedious memory bug into a working attack across eleven applications, which used to take a team months and now takes a steered researcher days. The essay's line: "AI has erased the buffer between a 'harmless' memory corruption bug and a 9.2 remote root shell" (Dead Neurons). Kevin Beaumont, who has watched these for two decades, called it "one of the biggest vulns in years" (Help Net Security).
Here is the part a CMO should sit with. PHP's own team had seen the first signs of this flaw in 2024, during an external audit paid for by Germany's Sovereign Tech Agency. "A potential exploit for the OOM problem was theorized, but no concrete vectors were found," the Foundation wrote on Tuesday, and other problems "overshadowed these concerns." When the team returned to it, it had several competing fixes, one that broke backward compatibility, one that opened a denial-of-service path, one that forced changes on thousands of third-party extensions. A small team working by consensus could not choose. The Foundation's verdict on itself: "the delay was a structural failure, caused by both the security team's decision process and its lack of resources." (PHP Foundation, The Next Web)
What a stranger can do with it, in her terms and in yours
Two different things, and the first is the quieter one.
Read what is in the server's memory. The first flaw lets one request read leftovers from other people's requests. Sansec compares it to Heartbleed: "passwords, session tokens, API keys and TLS private keys." In her terms: logins; the cookies that keep people signed in; the keys that connect the site to payment and email services; the certificate that makes the padlock in the browser mean something. Nothing is installed. Little is logged. On shared hosting, where thousands of small businesses rent space on one machine, the memory being read belongs to all of them at once.
Take the server over. Both flaws let the attacker run commands. The NSA's advisory puts it in one sentence: these vulnerabilities "often provide a direct path to the server's file system or database." What follows is the pattern of the last ten years, not a theory:
— The customer database leaves: order histories, pricing, employee records.
— A card skimmer goes onto the checkout page, invisible to the store owner, copying every card typed until someone's bank calls. Online stores are where this will be used first.
— Pages are altered, spam pages added, links planted. Search engines and AI assistants read the altered site and describe the brand from it, and corrections never travel as far as the damage (House Edge file 040, section 2).
— The server becomes a base: email sent under the company's own domain from a compromised marketing system, malware served to visitors, a path into whatever else the server can reach.
Why attackers care so much about this one. Four reasons, and together they explain why governments took their own sites down.
— No password, no login, no mistake needed. The attack arrives as an ordinary web request and runs before the website's own code starts; there is nothing the site owner could have configured wrongly.
— One exploit, most of the web. Because the flaw is in the engine, the same attack works on WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel, Nextcloud, webmail, and the admin pages of routers and storage boxes. An attacker does not study your site; they scan for anything running PHP.
— The quiet version steals without breaking anything. Memory read, nothing installed, little logged, and on shared hosting the memory belongs to every business on the machine.
— A third of the targets can never be fixed. Sites on PHP 8.1 or older get no patch, which leaves attackers a permanent population to work through long after the headlines end.
Why "nothing reported" may mean "nothing visible." As of Tuesday evening no organization had confirmed a successful compromise, and that sentence deserves a second look. The takeover path leaves traces: new files, new processes, a changed page, something a scan can find. The memory-read path leaves almost none. It is one request that looks like any other in the server's log, and the stolen material rides back inside the response. No file is written. No account is created. A password or an API key taken this way is used days or weeks later, from an ordinary-looking login, and the first sign is a customer's bank, an invoice paid to the wrong account, or email leaving under the company's name. The precedent is the one Sansec reached for: the original Heartbleed disclosure in 2014 said plainly that exploitation "leaves no traces of anything abnormal happening to the logs," and nobody ever established how long that flaw had been used before it was found (heartbleed.com). The only parties who could see Tuesday's attempts were the firewalls watching for the known request shapes, which attackers began changing within hours, and the honeypots. A successful quiet read on an ordinary server would not have been seen by anyone. Jake Knott of watchTowr, on the loud path: "Whilst nobody has been successful to date, we don't expect that will last long."
The practical consequence is the one the UK's NCSC put in its guidance: patching is the start, not the end. A server that faced the internet on an unpatched version between Monday evening and its update should be treated as read. Rotate the passwords, the session cookies, the API and payment keys that passed through it, and look for backdoors before trusting it again.
Why the best-run store was just as open
Calif confirmed pre-authentication code execution against current versions of WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento 2.4.9, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. Sansec confirmed it on a fully updated Magento store. The flaw sits below the application, so the application cannot close it: "You cannot fix PHP2Shell from within your store code." The thing you pay a good vendor for, keeping the software current, did not matter on Tuesday.
It also sits under the systems that run corporate brand programs: Pimcore and Akeneo, which hold product data and brand assets; Mautic, which sends a company's marketing email; and the company-store platforms, WooCommerce, PrestaShop, OpenCart and Magento, behind thousands of employee and dealer stores. Those are the systems holding the artwork, the price lists, the customer and employee files, and the logins. And it sits in places nobody calls a website: heise lists routers, firewalls and storage devices from QNAP, Synology, Netgear, pfSense, OPNsense, DrayTek, ZyXEL and others whose admin pages run PHP, along with appliances from Citrix, Palo Alto, Ivanti and F5 (heise). Hal Pomeranz: "So many embedded installations out there that will never be patched. Too many forgotten, unmaintained apps."
The quiet store. Think of the stores that are everywhere and watched by no one: the university's spirit shop and the departmental uniform store behind it; the corporate brand store where employees order a jacket with the logo and new hires get their welcome kit; the office-supplies and promotional portal a procurement team ordered through for years because the link was in the onboarding email. Added up across a country they are used by very large numbers of people every day. Taken one at a time, each sees a few dozen visitors, a handful of orders, and a dashboard nobody opens between seasons. That profile is the problem. A store with low daily traffic never earns a security budget, never sets off an alarm when its traffic changes, and is almost always one of hundreds of near-identical stores a vendor runs on a single aging platform, built when the contract was signed and frozen at the PHP version of that year. It holds employee names, shipping addresses, department codes, sometimes student IDs, and a payment page. Joviane Jardim of Detectify said it for the whole category on Tuesday: "Those sites haven't been updated in years, which usually means nobody is watching them either." On Tuesday morning every one of those stores was as open as the busiest site on the internet, and the quiet ones are the last to be patched.
Why more than a third of them can never be fixed
This decides who is still breached in December, and the villain is a calendar, not a hacker.
The calendar. PHP stopped fixing version 8.1 on 31 December 2025, 8.0 in November 2023, 7.4 in November 2022, and everything older years before that (php.net). Tuesday's fixes are built only for 8.2 through 8.5, and 8.2 itself stops getting fixes on 31 December, ten weeks away. For 7.4, 8.0 and 8.1 the project published "minimal source-backports": raw code that helps a team that compiles its own PHP and helps nobody on ordinary hosting. The project's own advice for anyone older: "contact your vendor, or upgrade to a supported version."
The count. Measured in websites, W3Techs has 27% of PHP sites on version 7 and 7.7% on version 5, so more than a third of PHP websites, out of 69% of the web, cannot take Tuesday's fix, and that is before the 8.0 and 8.1 sites hidden inside the version-8 share; Detectify's estimate is about half. Measured in machines, Mallory's census of servers that announce a version found 59% on 8.1 or older: version 5.6, unfixed since 2018, on 187,154 servers; 7.2, unfixed since 2020, on 184,302; 8.1 on 106,834; 883,717 in all. Read that number as the ones that admit it. Another 740,000 servers hide their version, most send no version at all, and a single shared-hosting machine carries hundreds of small-business sites. The honest scale is tens of millions of websites, not hundreds of thousands of servers.
The trap. Why are so many servers old? Because the software on top of them will not run on anything newer. Magento 1, the platform behind the first generation of corporate and dealer stores, reached its end of life on 30 June 2020 and runs on PHP 5.6 and 7; it cannot move to a fixed version at all. Mautic 5.0's published requirements are PHP 8.0 and 8.1, both unfixable. Current Akeneo needs PHP 8.3 and current Pimcore needs 8.4 or 8.5, so an older installation must first upgrade the whole application, with its database and custom code, before it can take a PHP that has a fix. Magento 2.4.6 and 2.4.7 stores still on 8.2 meet the same wall on 31 December (Mautic, Akeneo, Pimcore, Elogic). An application upgrade is weeks or months. Exploitation began Tuesday morning.
So "we will patch" is not a sentence every vendor can truthfully say. For many, the honest choices are three: take it offline, rebuild it, or leave it open. The NSA said as much on Tuesday: if an immediate update is not feasible, "it is recommended that organizations take the system offline until it can be fully mitigated." The UK's NCSC said the same more gently, and added a line every vendor should hear: if a system cannot be updated or disabled right away, assess it for evidence of compromise and look for backdoors. (NSA, NCSC)
The partial measures, for the CISO. The advisory lists settings that reduce exposure without making a server safe: memory_limit=-1 set where applications cannot override it, post_max_size held to 8M (32M where uploads are needed) with upload_max_filesize below it, session.upload_progress.enabled=0 applied before request parsing and every worker restarted, and on 8.5 fatal_error_backtraces=0. It warns that RLIMIT_AS and RLIMIT_DATA can trigger the vulnerable allocation failure, and that hiding diagnostics with error_reporting, display_errors or @ does nothing. Sansec adds blocking multipart/form-data at the web server or restricting a server to GET and HEAD, each of which breaks uploads or orders, and notes that its own Shield product does not cover these paths and that the Remi repository had no packages on release day. Distributions received the patches in advance; Ubuntu shipped fixes for all supported releases on Tuesday; check the vendor's packages. One suggested workaround was withdrawn within hours: the Japanese firm that first proposed a single configuration setting said by 05:00 UTC that it is not a complete fix and bypasses are expected, and Joe Ferguson, release manager for the next PHP, put it in four words: "ini settings won't save you" (The Hacker News). PHP core developer Gina Peter Banyard, asked what else works: "the only mitigation is patching/upgrading PHP. I sadly know too much."
What Tuesday looked like from outside
Hundreds of websites were down by Wednesday, most of them on purpose. The Dutch national cyber-security centre took its own website offline, and NotuBiz, which hosts the document portals of Dutch municipal, provincial and water-board councils, took those portals down. The Finnish government's site was only partly available. Nintendo, Charité hospital in Berlin and the OBS Project took services offline while they patched; Something Awful closed its forums. The EU, the United States, Germany, Japan, Australia, the United Kingdom and the Netherlands each issued warnings; CISA, the NSA and the FBI's cyber division all told operators to take PHP systems offline if they could not update at once. The German host Uberspace switched PHP off entirely for its customers at 3:45 p.m. rather than serve it unpatched. None of those organizations has reported a breach. They went dark because they could count their PHP versions and did not like the answer, which is more than most companies can say about their vendors. PHP's release manager Volker Dusch, to heise, once the fix was out: "After many weeks of work, I'm very glad we got the release out." (The Record, Boston Globe, Malwarebytes)
Who this touches, and how
You, with your own PHP website. On 8.2 or newer: Tuesday was an update and a restart, and a good host has already done it. On 8.1 or older: the site is on the wrong side of the count. The menu is an upgrade, an isolation using the partial measures above, or an outage, which is the choice several governments made.
What the hosts had said by Tuesday evening, in UTC (compiled by Meow Apps from each host's status page):
— SiteGround, 11:30: server-level protection on, nothing for customers to do.
— Kinsta: protections rolling out, patched PHP following; customers emailed when applied.
— WP Engine, 13:40: CDN protection in place, PHP updates rolling out.
— Namecheap, 13:31: fixed PHP installing platform-wide; VPS and dedicated customers update themselves.
— DreamHost, 13:46: protections on all platforms, updated PHP ready to deploy.
— Pantheon, 14:36: fixed versions available and rolling out.
— OVHcloud, 14:50: firewall rules on all clusters, fix deploying through Wednesday.
— GoDaddy: VPS customers must update PHP themselves, or pay GoDaddy to do it.
— Cloudways, Flywheel, Liquid Web, InMotion, Pressable, Rocket.net: protections in place, updates in progress.
— cPanel (EasyApache 4) and Plesk: fixed packages available. Debian 12 and Red Hat had no fix yet on Tuesday.
— Cloudflare: firewall rules on for every plan, including free, since 03:02. Cloudflare's own platform has no PHP and was never affected; the rules shield customers' PHP servers hosted elsewhere, which still need the update.
If your host is not on that list, its status page or a one-line ticket answers the question in minutes.
You, with vendors holding your data. This is most businesses, and the exposure arrives through someone else's server. The brand vendor's ordering portal, the company store, the media producer's WordPress with the brand's artwork in the uploads folder, the marketing-automation system with the customer list, the dealer portal: each is a PHP application on somebody's machine, and this week its version is the question. The duties after a breach do not transfer to the vendor. Regulators hold a business answerable for the service providers it chose (file 040, section 3), breach-notification laws name the owner of the data, and an insurance policy written on an application that promised vendor due diligence is tested at the first claim.
You, taking cards. The card industry's rule, PCI DSS 6.3.3, requires critical patches within one month of release. A store whose platform cannot run a fixed PHP cannot meet that by 21 November, whatever its scan report says, and the bank is entitled to ask (TrustedSec).
You, at a listed company. If a vendor's server holding company data is exploited, the question becomes whether it is material under Form 8-K Item 1.05, four business days from that determination, and the company's own statement about overseeing third-party risk becomes the exhibit (file 040, section 7).
The one email, today
To every vendor who runs a website, store or portal with your files, your customers or your logins on it. Three questions, in writing. Keep the answers with the contract.
1. Which PHP version is the system running right now, and when was it updated to 8.2.35, 8.3.36, 8.4.27 or 8.5.12? A version number and a time are the only acceptable answer.
2. If it is on 8.1 or older: what is the plan, and is it offline until then? "We are working on it" means it is open.
3. What of ours is on that server, and when was the last backup tested? You are asking for the inventory you should already have.
A vendor who answers within the hour had read the advisory before you wrote. A vendor who cannot name a version has just told you where your file is. Nothing else you do this week will sort your vendors faster.
The quieter point
The engine under most of the web is maintained by a small team that saw the first sign of this flaw two years ago and, by its own account, could not decide what to do about it. That is not a scandal. It is what maintenance looks like when the people doing it are few and the people depending on it are everyone. Your vendors are smaller teams still, and the habit that saved the organizations that went dark on Tuesday was a plain one: they knew what version they were running. That habit was visible last month. It is the diligence file that file 035 argued for, and this is the week it is read.
Sources. PHP security advisory, 21 October 2026 · The PHP Foundation, Today's PHP Security Release, 21 October 2026 (credits, the 2024 audit, the disclosure timeline, "structural failure") · php.net supported versions and end-of-life table · Calif, php2shell write-up (discovery, confirmed applications) · Wiz Research, PHP2Shell (discovery timeline, AI methods) · Sansec, PHP2Shell (platform tests, memory-leak description, timing, mitigations) · Cloudflare, protections against php2shell · watchTowr FAQ · SecurityWeek · BleepingComputer (VirusTotal estimate) · The Hacker News (Cloudflare timing, Banyard quote) · The Next Web · The Record (sites offline, Knott, Jardim) · The Boston Globe · Malwarebytes · NSA advisory · UK NCSC · Mallory, 20 October 2026 · W3Techs, 21 October 2026 · Ubuntu · Meow Apps, PHP2Shell and your WordPress site (the version check and the host status table) · The Hacker News, what actually protects you · Help Net Security (Beaumont, Pomeranz) · heise (appliances, Uberspace, Dusch) · Dead Neurons, PHP2Shell was in the training data · Sansec on Magento 1 · Mautic, Akeneo, Pimcore · TrustedSec on PCI DSS 6.3.3 · CISA alert, Critical Vulnerabilities in PHP Require Immediate Patching, 21 October 2026 · CISA Known Exploited Vulnerabilities catalog (not listed as of the evening of 21 October) · House Edge files 035, 039 and 040. Times are as the sources give them; Eastern times are converted from UTC. The census counts servers that announce a version, not organizations. Offered from the standpoint of a tenured marketing and manufacturing house, not a security or legal adviser: general commentary, not advice. Confirm your own exposure with your host and counsel.