Skip to main content
Back to Blog

Security alert

PHP2Shell: What Small Businesses Need to Do Right Now

If your website runs on WordPress, WooCommerce, Joomla, Drupal, or anything else built on PHP, it needs attention today. Two critical flaws in PHP itself, nicknamed PHP2Shell, let an attacker take over an unpatched web server without logging in. The fix is out. The FBI and NSA are telling organizations that cannot install it right away to take the site offline until they can.

· 8 min read

What happened

On October 21, 2026, the PHP project shipped emergency security releases for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are rated critical, 9.2 on the CVSS v4.0 scale, and both can let an unauthenticated attacker run code on the server. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (Help Net Security).

PHP runs roughly 70% of the websites on the internet, according to the researchers at Wiz who found the flaws. Every PHP release from the last decade is affected by at least one of them, going back to PHP 5.4. Palo Alto Networks counted 22.6 million potentially vulnerable instances in its first pass (Fortune).

The warnings came from the top. OpenAI's Patch the Planet program helped find the bugs and led the coalition that coordinated the fix and disclosure. The FBI's Cyber Division and the NSA both advised that if an immediate update is not possible, organizations should “take the system offline until it can be fully mitigated.” The UK's National Cyber Security Centre urged organizations to find and prioritize their internet-facing PHP systems, and agencies in the Netherlands and Finland pulled some of their own sites as a precaution.

Why this one is different

Most website security news is about a single plugin or theme. This is not. The flaw sits in PHP itself, below WordPress and every plugin you run. Wiz showed a full takeover of default WordPress, Drupal and Joomla installs, and noted that even a bare “Hello World” page on an affected PHP version can be vulnerable. A clean, fully updated WordPress site on old PHP is still exposed.

There is a second problem besides takeover. One of the bugs lets an attacker read chunks of the server's memory, which can include passwords, login tokens, API keys and certificates. That means a site can leak secrets without anyone ever getting in.

And the clock is short. The code had been broken for more than ten years, but turning it into a working attack took a chain of steps that was impractical by hand. Frontier AI models closed that gap, and the same tools are available to attackers. Amazon's honeypots logged an exploitation attempt four days before the public announcement (Help Net Security), and security firms are already seeing exploitation attempts in the wild (The Record).

Is my site affected?

Assume yes until you confirm otherwise if any of these are true:

  • Your site, store, booking page or member portal runs on WordPress, WooCommerce, Joomla, Drupal, Magento or another PHP platform.
  • You are on shared hosting or a cPanel or Plesk account.
  • You have an old landing page, staging copy, microsite or donation page nobody has touched in a while.
  • Your PHP version is anything other than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. PHP 8.1 and older are no longer supported by the PHP project at all.

Every way of running PHP on a web server is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Setups using mod_php face the most risk.

Where your site is hosted decides who has to act

What matters is who runs PHP for your site, not which company you pay. Find your situation below.

  • Vercel, Netlify, Wix, Squarespace, Shopify, or a static or Next.js site: most likely nothing to do. These sites do not run PHP you control, so this flaw does not reach them. The exception is a project that deploys PHP functions or sends traffic to a separate PHP server. Vercel's bulletin covers that case, and Vercel added free firewall rules for it.
  • Behind Cloudflare: you still need to patch.Cloudflare sits in front of your site. If your site is proxied through it, Cloudflare's free firewall rules block the known attacks, but the server behind it still runs PHP and still has to be updated.
  • GoDaddy, Bluehost, SiteGround or other shared or managed WordPress hosting: your host patches PHP, and you confirm it.Ask support in writing whether your site's PHP version is fixed for CVE-2026-109618 and CVE-2026-109619. Then do the cleanup steps below anyway, because the memory leak could have exposed passwords and keys before the patch went in.
  • A VPS, a dedicated server, or a server your developer set up: you own this one. You or your developer must update PHP. These are the sites most at risk, along with the old ones nobody remembers.

In short: if you rent simple hosting, your job is to confirm and clean up. If you run the server, your job is to patch today. Our own site runs on Vercel with no PHP, so it is not affected.

What to do today

  1. List every site you own. Main site, store, old campaign pages, staging copies. The forgotten ones are the ones that get hit.
  2. If a host manages your server, get it in writing.Check your host's status page or email, then ask support directly: which PHP version is my site running, and is it patched for CVE-2026-109618 and CVE-2026-109619? Linux distributions got the fix early, so some hosts may already be updated. Do not assume yours is.
  3. If you manage the server, update now.Install your operating system vendor's updated PHP packages or move to one of the fixed releases, then restart PHP-FPM or Apache so the new version actually loads. Searchlight Cyber released an open-source scanner, php2shell-scanner, that tests whether a host is still exposed.
  4. If you are on PHP 8.1 or older, plan the upgrade. The PHP team published minimal source backports for 7.4, 8.0 and 8.1, but those are for people who build PHP themselves. For everyone else, this is the week to get onto a supported version. If you land on 8.2, note that it reaches end of life on December 31, 2026, so aim for 8.3 or newer.

If you cannot patch today

Take the site down. That is the FBI's advice and ours. Swapping your home page for an HTML file is not enough, because the attack can land before any of your site's code runs. PHP itself has to stop handling requests: your host can switch it off, or the domain can point to a simple maintenance page hosted somewhere else, so customers still see your phone number and hours. A few days offline costs far less than a compromised server, stolen customer data or a site that quietly serves malware.

If your site sits behind Cloudflare, it already has an initial set of firewall rules for the known attacks, on every plan including free. Treat that as a seatbelt, not a fix. Wiz is clear that updating PHP is the only complete remedy.

After you patch: check you were not already hit

Patching stops new attacks. It does not undo one that already happened. Because the memory leak can expose secrets, do these once the update is in:

  • Change admin passwords and the database password, and rotate any API keys stored on the server: payment, email, CRM, analytics.
  • Look for new admin users, plugins you did not install, and recently changed files.
  • Ask your host or developer to review server logs for unusual multipart (upload) requests followed by memory errors or repeated 500 errors, oversized PHPSESSID cookies in responses, and PHP workers restarting for no clear reason. Wiz lists these as warning signs, and notes they may not show up in your site's own logs.
  • Find a clean backup from before October 17, the earliest attempt anyone has recorded. If you restore it, do so only after PHP is patched, and still rotate your passwords and keys.

How BridgePath can help

Most small businesses and nonprofits do not have an IT department, and the person who built the website may be long gone. That is exactly who this flaw will hurt. We can take this off your plate:

  • Find everything. We inventory your sites and confirm which ones run PHP and which version.
  • Get it patched. We work with your host or update the server ourselves, then verify the fix with a scan.
  • Take it down safely if needed. We put up a maintenance page that keeps your contact details live while the fix happens.
  • Clean up after. We rotate passwords and keys, check for signs of compromise, and hand you a short written summary of what we found.
  • Get off the treadmill. If your site is an aging PHP install, we can rebuild it on a modern stack that does not run PHP at all. Our own site is built that way.

Book a free call and we will tell you on the call whether you are exposed and what it takes to fix it. If you would rather handle it yourself, the steps above are the whole job. Do them today.

Sources

Book a free call