Trust & transparency
Evidence & disclosures
Not yet classified. This article has not yet been classified under the current editorial standard. It may predate the policy; do not assume a product was owned, tested, supplied, or independently verified unless the article says so.
Linked references: 17 explicit sources in the article.
The part of this PHP story that gets my attention is the age of the software underneath it. A website can look perfectly modern while the machinery serving it has been carrying a problem for years. Now AI is helping researchers turn some of those old problems into working attacks.
If you run a WordPress blog, a business website, or an older online store, here is the useful part first: ask your hosting provider whether the PHP runtime serving your site has been patched for CVE-2026-109618 and CVE-2026-109619, collectively called PHP2Shell. PHP published emergency fixes on October 21. Updating WordPress alone does not replace the PHP engine underneath it. PHP’s release notice
What actually happened?
Researchers disclosed two critical vulnerability classes in PHP, the software that runs server-side code for many websites. Their severity is rated 9.2 out of 10. Successful exploitation can let someone run code on an affected server without signing in. The PHP team identifies risk across web-serving installations, including PHP-FPM and Apache’s mod_php. It considers mod_php the highest risk because a demonstrated attack can trigger before the website’s own code runs. PHP security advisory
Think of PHP as the kitchen behind a restaurant’s dining room. Changing the menu does not repair a broken lock on the kitchen door. A plugin update may be necessary maintenance, but this repair belongs deeper in the stack.
These are memory-safety problems: PHP can mishandle internal data during out-of-memory failures or reuse stale state across requests. The official advisories explain the two classes separately. We do not need to reproduce an attack to understand why the repair matters. Out-of-memory advisory, stale-state advisory
This disclosure is not evidence that every PHP site has been hacked. It establishes a serious vulnerability requiring action; determining whether a particular site was compromised requires investigation.
The NSA warning about files and databases
The NSA’s October 21 advisory warns that the vulnerabilities can give attackers a route to server files or databases. It recommends taking systems offline when an immediate update is not feasible, until they can be fully mitigated. That describes potential access, not a finding that everyone’s files have already been accessed. NSA advisory
I located the NSA Cyber post on X, but X blocked direct retrieval during this research. The warning above is verified against the NSA’s own published advisory rather than a screenshot or an unverified tweet transcript.
Where AI fits—and what “14 years” means
OpenAI says Calif identified a critical flaw using its models through Patch the Planet, while Wiz independently discovered and reported both vulnerabilities. PHP maintainers led the fixes, with researchers and infrastructure providers contributing to the response. That is a more useful account than treating AI as a lone hacker that suddenly broke the internet. OpenAI’s disclosure account
Wiz reports affected releases dating back to PHP 5.4 and says AI substantially reduced the work needed to develop and adapt complex exploits. PHP’s release history dates 5.4.0 to March 1, 2012—roughly fourteen years ago. This is a family of related flaws with longstanding roots; the evidence does not establish one identical hole introduced on one date. Wiz research, PHP 5.4 release timeline
My takeaway: software surviving for years is not proof that every dangerous interaction has been found. AI can help defenders examine those interactions, and the same capability can shorten the time attackers need to adapt.
How much of the web still uses PHP?
On October 21, W3Techs reported PHP on 69.3% of websites whose server-side programming language it could identify. That last part belongs in the headline conversation. It is not a census of every website, every server, or every compromised system. W3Techs PHP survey
Two separate measures, not slices of one pie. Sources: W3Techs PHP and WordPress surveys, October 21, 2026.
WordPress accounts for 39.6% of all websites in W3Techs’ survey, or 58.3% of sites with an identified CMS. That explains why this matters well beyond developer circles. These populations overlap; adding the percentages would be misleading. W3Techs WordPress survey
For a concrete count, BuiltWith lists 23,961,854 detected live PHP websites, plus 5,499,455 redirects. The combined 29,461,309 figure includes those redirects. Its 80,459,242 historical sites are not current live sites. This is one provider’s detected population, not a worldwide total or a count of vulnerable installations. BuiltWith PHP statistics
Separate categories; redirect domains do not represent additional independent live sites. Snapshot retrieved October 21, 2026.
The older software is still out there, too. W3Techs’ PHP breakdown is 65.2% version 8, 27.0% version 7, 7.7% version 5, and 0.1% version 4. That makes 34.8% pre-8, calculated by adding the older major versions. This chart measures versions, not exploitability. Even “PHP 8” is too vague to confirm a fix. W3Techs version breakdown
Major-version shares cannot establish patch status. Survey data may not reveal provider backports.
What to do if you own a WordPress site
Start in Dashboard → Tools → Site Health → Info → Server and record the PHP version. This screen provides information; it does not install the server update. Contact your host if you cannot access it. WordPress Site Health documentation
Send the host this message today:
Please confirm that every PHP runtime serving my domain, subdomains, staging sites, and scheduled jobs is patched for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell). Please provide the running PHP version or vendor package revision, the security notice confirming both fixes, and confirmation that affected workers were restarted or replaced. If patching cannot happen immediately, please explain how you will isolate the affected service from public traffic until it is safe to restore.
Copy and adapt this message for your hosting provider.
Keep a backup and involve your host or developer in compatibility checks. Test the things people actually use afterward: login, forms, uploads, checkout, and scheduled tasks. WordPress’ PHP update guide explains the host-level process; use the emergency versions below rather than relying on generic minimum-version advice on older documentation pages. WordPress PHP update guide
Which PHP versions contain the fixes?
The October 21 upstream security releases are:
- PHP 8.2 → 8.2.35
- PHP 8.3 → 8.3.36
- PHP 8.4 → 8.4.27
- PHP 8.5 → 8.5.12
These are the first fixed releases in those branches, not permanent recommendations to stay on those exact versions. Later supported security releases may supersede them. A distributor may backport the fixes under an older-looking version string; obtain its package advisory covering both CVEs. PHP 8.1 and older have no normal upstream update support. PHP also supplied emergency source backports for 7.4, 8.0, and 8.1, intended for qualified builders and vendors—not a simple dashboard repair. PHP update and backport guidance
Older stores and self-hosted servers need the same question
For an old store or custom application, ask whoever maintains its server to inventory every PHP installation, including forgotten staging sites and bundled copies. European cybersecurity agencies advise coordinating with hosts and vendors and prioritizing internet-facing systems. A different storefront theme cannot resolve an underlying runtime flaw. Joint European advisory
Administrators should use their distribution or hosting vendor’s security packages, replace outdated container deployments, and verify the web-serving runtime after restarting affected workers. A command-line version check alone may describe a different PHP installation. Keep evidence of the installed package and the vendor notice for both CVEs.
If an old application cannot run on a supported, patched environment, isolate it while a developer evaluates an update, a vendor-supported backport, or a migration. Do not leave it exposed indefinitely because the store still appears to work.
What if you cannot patch immediately?
The UK’s NCSC advises considering taking the system offline until fully mitigated if immediate remediation is not possible. Have the host enforce isolation before requests reach PHP; a maintenance plugin still depends on the vulnerable runtime. NCSC guidance
Cloudflare has deployed WAF protections, but an edge firewall is an interim layer. Confirm the relevant protections apply to your service and that the origin cannot be reached around them. It does not replace the runtime fix. Cloudflare’s PHP2Shell response
Avoid copying a random php.ini “fix” and calling the job done. PHP lists temporary controls for specific attack paths, with explicit limitations; configuration changes require an administrator who understands the availability tradeoffs. The official advisories say a patched PHP release is the complete mitigation. OOM advisory, stale-state advisory
If you suspect a break-in, involve your host’s incident-response team. Preserve logs and evidence before cleanup; assess files, accounts, and exposed secrets. Installing a patch closes the vulnerability but does not establish that earlier compromise has been removed. That is the distinction between repairing a door and checking whether someone already came through it.
Final Thought
The AI part is fascinating. The useful part is getting a real answer about the software running your site.
Ask your host for the patch confirmation today. Save the answer. Then put PHP updates on the same maintenance list as WordPress, plugins, and backups. “The website still loads” is a very low bar for knowing the machinery underneath it is healthy.