Skip to content
All insights

Website Security / FIELD NOTES

PHP2Shell: Why 70% of the Web Was Exposed This Week (and What to Do About Your Website)

PHP2Shell critical PHP vulnerability October 2026

Your website probably runs on PHP. This week, that became a problem.

On Tuesday 21 October 2026 the PHP project shipped an emergency fix for two flaws in the language itself, not in a plugin, not in a theme, in the engine underneath roughly seven in ten websites on the internet. Attackers can use either one to run their own code on a web server without logging in. Security researchers have already watched people try.

If your site is built on WordPress, Drupal, Joomla, Magento or any custom PHP build, it was exposed. If it sits on a shared hosting plan you have not looked at since the site went live, it may still be exposed right now.

The flaws have a name, PHP2Shell, and a rating of 9.2 out of 10 on the CVSS v4.0 severity scale. Wiz, one of the three research teams that found them, described them as among the most severe vulnerabilities in the history of PHP and arguably in the history of software. This article explains what happened in plain English, what to do in the next 24 hours and why the smarter long term move is to stop running your business on a stack that needs this kind of rescue every few months.

What actually happened

Conceptual illustration of a fractured server stack and a warning shield

Two memory safety bugs in the PHP engine let an attacker corrupt a web server's internal state and take it over. The flaws have sat in the PHP codebase for over a decade. Three research teams, Wiz, OpenAI and Calif, found them this summer using frontier AI models to do analysis that would previously have taken a specialist team months.

CVEPlain EnglishWhat researchers proved
CVE-2026-109618When PHP runs out of memory mid request, it leaves half built data behind. The next request can reuse it.Full remote takeover of WordPress, Drupal and Joomla with no login. Reading passwords, tokens and API keys straight out of server memory.
CVE-2026-109619PHP keeps a reference to data from a previous request after that memory has been freed.Full remote takeover of WordPress and Drupal with no login.

Both score 9.2 out of 10 on CVSS v4.0. Both affect every PHP release from 5.4 through 8.5. The important detail for a business owner: the bug is in PHP itself, not in WordPress or a plugin. Wiz showed that even a bare "Hello World" page on a vulnerable PHP version can be attacked. Having a tidy, well maintained site did not protect you.

DateWhat happened
22 Oct 2026watchTowr confirms exploitation attempts in the wild through its honeypot network
21 Oct 2026PHP ships fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at 14:00 UTC. Cloudflare and Fastly deploy emergency firewall rules
20 Oct 2026Technical details leak on social media two days early. Hosts such as SiteGround patch at server level ahead of the release
17 Oct 2026Amazon threat intelligence records the earliest known exploitation attempt, four days before public disclosure
24 Aug 2026Wiz reports the flaws privately to the PHP security team
19 Aug 2026Wiz discovers the first flaw

The leak matters. Attackers had working knowledge before most site owners had a patch, and sites on PHP 8.1 or older received no fix at all because those branches are out of support.

Why you should care even if you never touch the code

A compromised web server is not a defaced homepage. It is a machine an attacker now owns, sitting on your domain, with your reputation attached.

  • Customer data. Contact forms, enquiry logs, order histories and account passwords stored in the site database are readable once the attacker has code execution.
  • Credentials in memory. CVE-2026-109618 lets an attacker read live server memory without taking over the server at all. Wiz demonstrated recovery of passwords, session tokens and API keys for payment gateways, email services and CRMs.
  • Your domain as a weapon. Attackers use compromised small business sites to host phishing pages, distribute malware and send spam. Google flags the domain, email deliverability collapses and your customers get a red warning screen.
  • Regulatory exposure. In the UK, a breach involving personal data is reportable to the ICO within 72 hours. For South African businesses, POPIA imposes the same duty on the Information Regulator. "My web host didn't patch" is not a defence.
  • Silent compromise. These bugs operate below the application layer, so WordPress logs show little or nothing. You may not find out until a customer does.

Most small business owners have no idea which PHP version their site runs on, whether their host has patched it or whether anyone is checking. That gap is the real vulnerability.

What to do in the next 24 hours

Do these in order. The first three take under an hour and close the immediate hole.

  1. Find out your PHP version. Log in to your hosting control panel (cPanel, Plesk, SiteGround Site Tools or similar) and look for PHP Manager or PHP Version. If you cannot find it, email your host and ask: "Which PHP version is my site running, and has it been patched for CVE-2026-109618 and CVE-2026-109619?" Keep their written reply.
  2. Get on a fixed version. The patched releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your host offers a version switcher, move to the nearest patched branch now. If you are on PHP 8.1, 8.0 or 7.x, there is no patch for you. Those branches are end of life and your host has to upgrade you to 8.2 or later.
  3. Check your firewall. If your site sits behind Cloudflare, confirm the WAF is on and the managed ruleset is active. Cloudflare and Fastly both shipped emergency rules for PHP2Shell. This is a stopgap, not a fix.
  4. Rotate anything secret. Because the memory disclosure bug exposes credentials even without a full takeover, treat any key held by the site as potentially leaked. Reset admin passwords, regenerate API keys for Stripe, PayPal, Mailchimp, HubSpot or whatever the site talks to, and invalidate active sessions.
  5. Look for signs of tampering. Check for new admin users you did not create, recently modified files in wp-content or the site root, and unexpected scheduled tasks. Your host's logs may show bursts of HTTP 500 errors paired with unusual multipart upload requests, which Wiz identified as the fingerprint of exploitation.
  6. Ask your host when they will do this again. The uncomfortable question. PHP ships patch releases roughly every month, and WordPress core, themes and plugins patch far more often than that. Will your host apply the next one within hours, days or never? If they cannot answer, that tells you what you need to know.

If you are reading this and thinking "I do not know how to do any of that", skip to the end. That is the problem we solve.

The real problem is not this bug. It is the next one.

Patch PHP today and you are safe from PHP2Shell. You are not safe from the pattern that produced it.

A typical small business WordPress site is a stack of software you did not write and nobody at your company maintains: the PHP interpreter, a web server, a MySQL database, WordPress core, a theme and somewhere between 15 and 40 plugins. Each layer has its own release cycle, its own security list and its own way of breaking the layer above it when updated. You pay for this in one of two ways. Either you pay someone to watch it every week, or you ignore it and pay later.

Wiz was blunt about where this is heading. PHP2Shell took a single researcher about a week to turn into a working exploit using AI tools. Before those tools existed, the same work would have taken a world class team months. Flaws that were once too hard to exploit are now practical targets, and that applies to every layer of the stack, not just PHP.

The question is not whether your site will need an emergency patch again. It is whether you want to keep running a business on infrastructure that needs rescuing.

What a modern site looks like, and why this bug could not have touched it

Conceptual illustration of independent workloads above a modern platform

Every site LuxVibeWeb builds runs on a modern JavaScript stack: a React front end compiled to static files, served from a global edge network, with backend logic running as isolated serverless functions in TypeScript. There is no PHP interpreter, no long running server process sharing memory between visitors and no database server exposed to the internet.

ComparisonTypical WordPress siteLuxVibeWeb build
LanguagePHPTypeScript / JavaScript
Exposed to PHP2ShellYesNo
Server you must patchYes, several layersNone, the platform patches itself
Shared memory between requestsYes, the root cause of this bugNo, each request runs in isolation
Plugins to keep updatedTypically 15 to 40Zero
Page loadDatabase query on every visitPre built pages from a CDN
Who watches securityYou, or nobodyThe platform's security team

To be clear: no stack is immune to every flaw. JavaScript has its own supply chain problems and the same week PHP2Shell dropped, a poisoned Python package was stealing developer credentials. The difference is where the burden sits. On a serverless platform the vendor patches the runtime for every customer at once, usually before the advisory is public. On a PHP site on shared hosting, the burden sits with you.

The practical result: a smaller attack surface, no server to maintain, faster pages and a site that stays current without anyone logging in to click Update.

Move off PHP. We can have you rebuilt in days.

LuxVibeWeb rebuilds dated PHP and WordPress sites on a modern serverless stack with a turnaround measured in days, not months. You keep your domain, your content, your branding and your search rankings. You lose the server, the plugins, the update emails and the 3am worry.

How it works:

  1. Free stack check. Send us your web address. Within one working day we tell you what your site runs on, whether it has been patched for PHP2Shell and what else we found. No obligation.
  2. Fixed quote, fixed date. We scope the rebuild, give you one price and a delivery date before you commit. No hourly billing, no scope creep.
  3. We rebuild in parallel. Your current site stays live while we build the new one. Content migrates, URLs redirect, forms and integrations are rewired and tested.
  4. Switch over. One DNS change, usually at a quiet hour you choose. If anything is wrong, we flip back in minutes.
  5. Nothing to maintain. No PHP, no plugins, no patches. The platform updates itself and your site stays fast.

We have moved service businesses, consultancies, ecommerce stores and professional practices off WordPress onto this stack. Most are surprised by how little they lose and how much faster the new site feels.

If PHP2Shell was the first time you thought about what your website is actually running on, make it the last. Contact LuxVibeWeb for your free stack check today.

Frequently asked questions

What is PHP2Shell? PHP2Shell is the name given to two critical vulnerabilities in the PHP language, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. Both allow an attacker to run code on a web server without logging in.

Which websites are affected? Any site running PHP 5.4 through 8.5 without the October 2026 patch. That includes WordPress, Drupal, Joomla, Magento and custom PHP applications.

How do I know if my site has been patched? Check the PHP version in your hosting control panel or ask your host in writing. Patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older received no fix.

Is a WordPress site safe if all plugins are up to date? No. The flaw is in PHP itself, beneath WordPress. Plugin updates do not fix it. Only a PHP update or a host level patch does.

Does a LuxVibeWeb site have this problem? No. LuxVibeWeb sites run on a JavaScript and TypeScript serverless stack with no PHP interpreter in the request path.


Sources: Wiz Research disclosure · watchTowr PHP2Shell FAQ · Qualys technical breakdown and mitigations · SiteGround advisory · Cisco PSIRT advisory. Facts correct as of 22 October 2026.