PHP2Shell: Is Your Website Safe? A 15-Minute Check

Most small business websites will probably come through PHP2Shell fine, because their hosting company has already patched it. The sites in trouble are the ones nobody is looking after: an old WordPress install on a server the original builder set up years ago, a hosting account nobody has logged into since 2019, a "cloud server" an agency put you on before it went out of business.

You can find out which group you're in this afternoon without hiring anyone. It takes one email to your host, a couple of minutes inside your WordPress dashboard, and a few free Google checks.

If you get to the end and something looks wrong, or you can't get into your hosting at all, that's the kind of thing we fix.

What Happened

On October 21, 2026, the PHP project released emergency fixes for two flaws (CVE-2026-109618 and CVE-2026-109619) that researchers at Wiz, Calif, and OpenAI had named "PHP2Shell." PHP is the programming language underneath WordPress, Joomla, Drupal, and a large share of custom-built small business sites. W3Techs counts it on about 69% of websites where the server language is known.

A stranger on the internet could send a specially crafted request to a vulnerable site and run their own commands on the web server, with no password and no login. PHP rated both flaws 9.2 out of 10. A leaked version of the details had circulated a day early with a score of 10.0, and the PHP Foundation later said that number was wrong. The PHP project's advice is blunt: "There are no complete mitigations, updating is the only safe choice."

Does This Affect My Site?

Start with what your site is built on. If you log in at yoursite.com/wp-admin, it's WordPress, which runs on PHP. Joomla and Drupal also run on PHP. If your site is on Squarespace, Wix, Shopify, or Webflow, the platform runs the servers and handles this for you. There's nothing for you to do.

If you're on PHP, the next question is who looks after the server. That matters more than anything else in this post:

Attackers pick targets by machine, so "my site is too small for anyone to bother with" doesn't apply. They run scanners across millions of addresses looking for anything vulnerable, then use whatever they get into for spam pages, phishing, or redirects to sketchy sites.

The 15-Minute Check

Step 1: Ask your host (5 minutes)

This is the step that tells you whether you're patched. Your PHP version number alone won't, which surprises people. Many hosts fixed older versions like 7.4 and 8.1 by applying the patch without changing the version number. So "7.4.33" can be safe at one host and wide open at another. Only your host knows which yours is.

Send this to your host's support (email, ticket, or chat), filling in your domain:

A good host answers all three directly. If the answer is vague, or you get a sales pitch for a security add-on instead of a yes or no, that tells you something about the host too. Hostinger customers can check without asking: their PHP Info page shows a build date, and October 21, 2026 or later means fixed.

Step 2: Look up your PHP version (2 minutes)

This tells you how exposed you'll be to the next flaw, not whether you're patched for PHP2Shell. In WordPress, go to Tools → Site Health → Info and open the Server section. If your host uses cPanel, it's under Software → MultiPHP Manager. While you're in Site Health, check the Status tab too: WordPress flags an outdated PHP version there as a security issue.

If you're on 8.1 or older, you're in big company: according to WordPress.org's own stats, 35.8% of WordPress sites are. Your host may well have patched this particular flaw for you. But PHP itself has stopped fixing those versions, so the next serious flaw may not get a fix at all.

Step 3: While you're logged in (5 minutes)

PHP2Shell is unusual. Most WordPress security flaws are in plugins: Patchstack found 91% of the WordPress vulnerabilities it tracked in 2025 were in plugins and another 9% in themes. So while you're in the dashboard:

• Dashboard → Updates: install pending WordPress, plugin, and theme updates. WordPress applies minor core updates on its own, but most plugins and themes wait for you.
• Plugins: delete any you don't use. A deactivated plugin is still sitting on the server.
• Users: look for administrator accounts you don't recognize. Old ones from a former web person should go too.
• Backups: confirm your host is taking them and you know how to restore one.

Has My Site Already Been Hit?

Hacked small business sites rarely look hacked to the owner. Attackers want the site to keep running so they can use it. The damage tends to show up in Google, or for visitors arriving from Google, rather than when you type your own address. These free checks catch the usual signs:

• Search Google for site:yourdomain.com and click through a few pages of results. Pages you didn't make (pills, casinos, knockoff handbags, or Japanese text in odd-looking URLs) mean someone has added content to your site.
• Check Google Safe Browsing at transparencyreport.google.com/safe-browsing/search. Enter your domain and it tells you whether Google currently flags it as dangerous.
• Open Google Search Console, if it's set up, and look at Security Issues. It reports hacked content, malware, and phishing pages Google has found. Also check who has access: an owner you don't recognize is a red flag.
• Search for your business on your phone and tap your own result. Some hacks only redirect visitors who come from Google, or only on mobile, so typing your address directly shows nothing wrong.
• Read your host's emails. Hosts sometimes flag malware or a sudden spike in outgoing email before owners notice, and those warnings can land in spam.

If you find something

• Don't start deleting files. Hacks usually leave back doors in places you won't see. Deleting the visible spam often destroys the clues needed to find them, and the spam comes back.
• Contact your host. Ask whether they see anything on their end and whether they have a clean backup from before the problem.
• Don't install a "PHP2Shell fix" plugin or paste in a code snippet. Unofficial fixes are already circulating, and at least one blocks only one of the two attack paths. Patchstack warns against them, and PHP says no setting change makes a site safe.
• Ignore the cold emails. Expect "we scanned your site and found PHP2Shell!" pitches this week. The same people who call you about your Google listing read the news too.

The Next Deadline: December 31

If your site is on PHP 8.2, you're patched today, but PHP stops releasing security fixes for 8.2 on December 31, 2026. That covers 23.7% of WordPress sites. Add them to the 35.8% already on older versions, and about 60% of WordPress sites will be on PHP that gets no official fixes in ten weeks.

That's the bigger lesson of PHP2Shell. PHP ships updates most months. A site that was set up once and never touched again falls further behind every month, until a flaw like this one shows up. Moving to 8.3 or 8.4 now, on your own schedule, is a lot calmer than doing it in a hurry after the next headline.

Why We Build Sites Differently

A well-maintained WordPress site on a good host is fine. We work on WordPress sites all the time. But it helps to understand why WordPress sites keep showing up in security news: a typical one has several layers, and each needs its own updates.

• PHP itself, which your host updates (PHP2Shell lives here)
• WordPress core, which mostly updates itself (and had its own serious flaw, wp2shell, this July)
• Plugins and themes, each from a different author on its own update schedule, which mostly wait for you
• A database and a public login page at /wp-admin, which bots try passwords against around the clock

The sites we build for clients are mostly generated ahead of time. When someone visits, the server hands over pages that are already built. There's no PHP running, no database to break into, no plugins piling up updates, and no login page for bots to guess at. On a site like that, PHP2Shell has nothing to attack.

These sites still need security patches. We build on Next.js and React, which have had serious flaws of their own, including one last December that scored a full 10.0. The difference is in who does the updating. When a fix comes out, we update it once and redeploy, and every page updates together. Nobody has to remember to log in and click "update" on 20 plugins.