The PHP Hack Explained: Why Every WordPress Site Was Exposed

On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws, nicknamed PHP2Shell, that let a stranger run code on a web server without logging in. The bugs are in PHP itself, not in WordPress. But WordPress runs on PHP, so every WordPress site on an unpatched server was exposed that morning, and its owner could not have fixed it by updating a plugin. Government agencies in several countries told website operators to patch or take their sites offline.

What actually happened

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 out of 10 on the CVSS v4.0 scale. They were found by researchers at Wiz, Calif and OpenAI's Codex Security team, and the code involved had sat in PHP for more than a decade (The Hacker News). Cybersecurity Dive reported that Calif found them using an OpenAI model, which is worth noticing: the same kind of tooling that finds a bug in ten-year-old code can also be pointed at your site (Cybersecurity Dive).

In plain terms, both bugs come from how PHP handles memory when a web request goes wrong. Cloudflare describes one as PHP running out of memory before it has set up its internal data, and the other as a fatal error that leaves stale memory behind where a later request in the same process can reach it (Cloudflare). The security firm Sansec adds that every known trigger is a file-upload style request, and that the memory leak can hand an attacker data from other visitors' requests, which it says can include passwords, session tokens, API keys and TLS private keys (Sansec). Researchers describe the technical details a little differently from each other, but the common core is the same: a crafted request, mishandled memory, and a server that can be made to run an attacker's code.

The week in order

The timeline matters here because it did not go the way a coordinated disclosure is supposed to go.

• August: Per Sansec's timeline, Calif found multiple code-execution paths on August 1 and reported the first bug to PHP on August 11. Wiz reported its findings on August 24.
• October 16: The White House says the U.S. government learned of the flaws (Cybersecurity Dive).
• October 20: A Hacker News post claimed the flaws were coming. PHP posted an advance notice that evening and pulled the release forward a day. Around the same time, one of the researchers accidentally posted a video of a working proof of concept (The Hacker News).
• October 21, 3:02 am UTC: Cloudflare switched on protective firewall rules for its customers by default, hours ahead of the patch.
• October 21, about 7:43 am UTC: Cloudflare reported early attacks.
• October 21, 2:00 pm UTC: PHP released the fixed versions, and the exploit tool and writeups became public.

So for a window of several hours, attackers knew what was coming, defenders did not yet have the fix, and a working demonstration was in circulation. That is the part owners should remember. The gap between "a flaw exists" and "you can patch it" was not under anyone's control but the PHP team's.

Who was exposed

Almost everyone running PHP on the web. W3Techs puts PHP at roughly 70% of websites, as Cybersecurity Dive reports. Estimates of how many were actually vulnerable vary a lot because setups differ: one researcher counted more than 1.3 million websites, while Palo Alto Networks estimated more than 22.6 million exposed instances. Censys counted about 2.58 million internet-facing hosts and 54.9 million web properties running PHP (Krebs on Security).

The flaws reach back to PHP 5.4. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get fixes from the PHP project, and the project says only minimal source backports exist for 7.4, 8.0 and 8.1 (The Hacker News). Cisco's Talos group estimated that roughly half of internet-facing instances run versions too old to receive the fixes at all.

That last number is the one we would underline. It means a large share of the web cannot simply click "update." Those sites are stuck on a runtime that is out of support, and the only real fix is migration.

Which platforms Calif showed could be hit

This is not a niche problem. According to Sansec, Calif demonstrated unauthenticated code execution against current releases of Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS. Sansec also notes that Magento, Shopware and WooCommerce stores are exposed even when their own code is clean, because the flaw sits underneath all of it and runs before store code does (Sansec).

For WordPress, Patchstack reports that Wiz demonstrated unauthenticated code execution against the latest WordPress container image (Patchstack). Nothing about that required a vulnerable plugin, a weak password, or any mistake by the site owner.

The part most owners miss: your update button does not help

The advisory coverage makes one point that deserves repeating: updating an application such as WordPress does not update the PHP runtime underneath it (The Hacker News). A WordPress owner can have every plugin current, a strong password and two-factor login, and still be exposed, because the weak spot sits in software their host controls.

So the fix depends on someone else. If you are on managed hosting, you wait for the provider to patch and hope they move fast. If you are on a cheap shared plan, you may not even know what PHP version you are on. If your host dropped support for your old PHP version years ago, your site may need to be rebuilt to run on a supported one, which is exactly the project nobody budgeted for.

Huntress made a related point about visibility. Most internet-facing PHP runs on web servers and shared hosting that are often not closely monitored, and an exposed Linux web server without endpoint monitoring is the kind of system where a flaw like this could be exploited quietly and go unnoticed (Huntress). Small-business sites are usually in that group.

What the governments did

The official response was unusually blunt. According to Cybersecurity Dive, CISA, the UK's NCSC, and agencies in Canada, Australia and the EU urged website operators to update or take sites offline until their PHP versions were patched. The Finnish government and the Dutch House of Representatives disconnected their sites from the internet that day, and the NSA urged its partners to update as soon as possible.

The Netherlands also saw the DigiD login system and the national MijnOverheid portal go offline, according to NOS as reported in the coverage above, though the country's cyber-security center said it had not seen the flaw abused. BambooHR took its service offline in the US, Canada and Ireland as a precaution. These were not responses to confirmed break-ins. They were organizations deciding that a few hours offline beat the alternative.

For a small business, the equivalent decision is awkward. You do not have a security team to say "take it down." You have a website that brings in calls, and a host that may or may not have patched.

What a stopgap looks like, and why it is only a stopgap

Cloudflare's firewall rules were switched on for customers on every plan, including free ones, and they use a new detection that looks at both the request and the server's response. That is real protection. But Cloudflare itself says the rules are defense in depth, that customers should still patch PHP, and that updating site code or plugins does not fix flaws in the runtime (Cloudflare). They also only help if your server accepts traffic only through Cloudflare.

The temporary measures in PHP's advisory are similar: turn off session upload progress, set memory limits as directed, keep request sizes small. Sansec's list goes further and includes blocking file-upload requests at the web server, which breaks uploads and may break some checkout forms. Both sources say these settings are not a complete fix. Only updating PHP fully closes the hole.

Why we stopped building client sites on WordPress

We should be fair first. WordPress did nothing wrong in this story, and a well-run WordPress site on a well-run host is a reasonable choice for plenty of businesses. If yours is one of them, patch PHP today and keep going.

Our reason for leaving is the pattern, and this week is one more example of it. Every WordPress site is a stack of parts, and each part has its own owner and its own patch schedule: the PHP runtime, the web server, WordPress core, the theme, and a pile of plugins written by strangers. Any one of them can be the way in. When the weak layer is the bottom one, as it was this week, nothing you do inside WordPress matters.

The plugin layer is where the volume is. Patchstack's own figures show more than 4,100 new vulnerabilities disclosed across the WordPress ecosystem in 2024, 13% of them highly exploitable. It says 33% of vulnerabilities in the ecosystem receive no patch at all, and that over 60% of attacks exploit flaws that already have a patch nobody applied (Patchstack). Patchstack puts the average window to update, test and patch at 120 days. Attackers do not wait 120 days. In its coverage of this same event, the firm notes that hosting partners were reporting active exploitation attempts to it the morning the patch landed.

What that means for a typical small business is three recurring costs:

• Someone has to watch and apply updates. Most owners cannot, so it becomes a retainer or it does not happen.
• Updates can break the site, so people postpone them, and the postponed ones are the ones attackers use.
• You learn about trouble late, usually from a customer, a hosting email, or a browser warning, not from a dashboard.

We wrote about the day-to-day side of this in The Hidden Fragility of WordPress SEO Plugins, and about the build decision itself in WordPress vs. Webflow for a Business Website. This week adds a fourth cost that none of those posts could have predicted: a flaw that lands in a layer the owner cannot reach.

What we build instead, and what it does and does not fix

The sites we build for clients are custom code that is compiled into plain pages ahead of time and served from Cloudflare's network. The page a visitor loads is a finished file, not a program running PHP on every request. Forms and logic run in small, separate back-end functions in a managed database service. There is no PHP runtime on the web server for us to patch, because there is no PHP.

That is why, when this story broke, our own sites were not on the list of things to patch. Nothing we run on our own sites needed the PHP update, and the sites we build this way had no host to chase and nothing to take offline.

We are not going to tell you that makes a site unhackable, because it does not. Code we write can have bugs. A third-party script can be compromised. A stolen password can hand over the whole account. We also use other people's services, and any of them can have a bad day. What changes is the size of the target: fewer moving parts you do not control, nothing executing on a server for each visitor, and no plugin directory to audit. A smaller surface is easier to defend, and when a flaw appears in the layer underneath, the answer for our clients is that the layer is not part of their site.

There is a trade-off, and it is only fair to say so. A custom or static-first site is not something an owner edits by installing a plugin, and it takes a team that knows how to build one. For a business that wants to change a page itself on a Friday night with no help, WordPress is easier. We think the reduced risk and the speed are worth it for the service businesses we work with, but it is a choice, not a law.

What to do this week if your site runs on WordPress

1. Find out your PHP version. In WordPress, open Tools, then Site Health, then Info, then Server. Or ask your host. Compare it to the fixed releases above.
2. Ask your host in writing. "Have you applied the October 21 PHP fix for CVE-2026-109618 and CVE-2026-109619?" Linux providers sometimes patch without changing the version number, so ask for the package changelog or a direct yes.
3. Do not install a "fix" plugin or paste a snippet from a forum. The flaw is in the PHP runtime, and unofficial fixes can break the site without protecting it.
4. Look for signs of trouble. New admin users you did not create, files you do not recognize in your uploads folder, or a hosting email about unusual traffic. Huntress also tells defenders to watch for web-server processes starting shells or downloading tools, and for new files, scheduled jobs or accounts. If you see signs, treat the site as compromised and change every password and key it holds.
5. If you are on PHP 8.1 or older, make a plan now. That is a rebuild or migration conversation, and it is much cheaper to have it before the next emergency than during one.
6. Put the site behind a firewall layer such as Cloudflare if it is not already, as a temporary shield. It is not a substitute for patching.

Frequently Asked Questions

Is WordPress itself vulnerable to PHP2Shell?

The flaws are in PHP, not in WordPress, but WordPress sites run on PHP, so they are exposed if the server's PHP is not patched. Wiz demonstrated code execution against the latest WordPress container image, according to Patchstack.

If I update all my WordPress plugins, am I safe?

No. Updating WordPress and its plugins does not change the PHP runtime on the server. Only your host, or you if you manage the server, can install the patched PHP version.

Which PHP versions fix the problem?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive official fixes, so they need a vendor backport or an upgrade.

Has anyone actually been hacked through this?

As of the sources we reviewed on October 21, attack attempts had been reported by Cloudflare and watchTowr, but no source had confirmed a successful break-in of a named server. That could change, and the vendors expect mass exploitation now that the exploit is public.

Does a static or custom-built site avoid this?

A site that is compiled into plain pages and served without a PHP runtime does not run the vulnerable code, so this particular flaw does not apply to it. Other risks, such as bugs in custom code or compromised third-party scripts, still exist.

Sources

• The Hacker News: PHP issues emergency patches for two critical PHP2Shell flaws
• Cloudflare: Protections against the php2shell vulnerabilities
• Krebs on Security: Widespread PHP flaw may cause many site outages today
• Cybersecurity Dive: Critical PHP vulnerabilities expose most websites to potential compromise
• Sansec: PHP2Shell research
• Huntress: Rapid response on the leaked critical PHP vulnerabilities
• Patchstack: Major security alert on PHP remote code execution
• Patchstack: WordPress security statistics

Limits: this is a fast-moving security event, and details may change after publication. The Valley Marketing Group is a marketing and web agency, not a security firm, and this is not a substitute for advice from your hosting provider.