Is your website affected by the PHP security flaw? A plain-language check

If your website runs on WordPress, this probably applies to you. Here is how to check, what to ask your web host, and what “safe” looks like. You do not need to be technical for any of it.

What happened

On 21 October 2026, the PHP project released emergency security updates for two critical flaws, known as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell”. PHP is the software that runs WordPress and many other websites, and these flaws can let a stranger run their own code on the server behind a site without logging in. Security companies have reported attempts to exploit them, so it is worth one short email today.

Does your website use PHP?

Very likely, if either of these is true:

• Your site is built on WordPress, Joomla or Drupal. All three run on PHP.
• Your hosting comes with a control panel called cPanel. Most hosting of that kind runs PHP.

If you use a hosted website builder such as Squarespace, Wix or Shopify, the company behind it runs the servers for you. Check its status page or ask its support team rather than assuming either way.

Not sure? If your site is on WordPress, log in and go to Tools, then Site Health, then the Info tab, and open the section called Server. It shows your PHP version. Otherwise, find out who your host is. It is whoever you pay for hosting, or the person who built your site will know. Then send them the email below.

The one email to send your host

Copy this, fill in the parts in square brackets, and send it to your host's support address or help desk.

About point 4: keeping WordPress and its plugins updated is always good housekeeping, but it does not fix this flaw. The flaw is in PHP itself, underneath WordPress, so the fix has to come from whoever runs your server.

What “safe” looks like

Your site is on one of these PHP versions, or a newer one in the same series:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

So 8.4.27 or 8.4.28 is fine, and 8.4.26 is not. There is one catch. Some hosts add the fix without changing the version number, so a patched site can show an older-looking number. If yours is lower than the list above, a written answer from your host saying the 21 October fix has been applied is what counts.

One more date worth knowing: PHP 8.2 receives security fixes only until 31 December 2026. If your site is being moved anyway, ask about 8.3 or newer.

If your host does not answer, or you are on PHP older than 8.2

If you have not heard back within a day, follow up by phone or live chat and ask the same questions. Many hosts are also posting updates about this on their own websites.

If your site is on PHP 8.1 or older, the PHP project no longer releases updates for it. It has published bare-bones fixes for versions 7.4, 8.0 and 8.1, meant for people who build PHP themselves, and some hosts add the fix to older versions on their own. For anything older than 7.4, the PHP project offers no fix at all. For most small businesses, the practical answer is to move to PHP 8.2 or newer.

• Ask your host to move your site to a newer PHP version. On many hosts it is a setting in the control panel, but ask them before you change it yourself.
• Take a full backup first, or ask your host to. Older plugins and themes sometimes stop working on a newer PHP, so check your main pages and forms afterwards.
• If the site cannot be moved soon, consider taking it offline until it can. The UK's National Cyber Security Centre and the Canadian Centre for Cyber Security both suggest this for systems that cannot be fixed straight away.

If you think your site has been hacked

Signs worth taking seriously:

• Administrator accounts or users you did not create.
• Files, pages or posts you did not add.
• Visitors being sent to another website, or seeing pages that are not yours.
• Your site suddenly showing error pages.
• A warning from your host, your security plugin or Google.

If you see any of them, in this order:

• Contact your host first. Tell them what you saw and when you first noticed it. They can see things you cannot, and many will help you clean up.
• Make sure the PHP fix is applied before anything else. Otherwise the same way in is still open.
• Restore your site from a backup made before the trouble started. If you are not sure when that was, ask your host to help you choose.
• Then change your passwords: your hosting account, every WordPress administrator, and anywhere else you used the same ones. Doing it after the clean-up means the new passwords are not exposed too.
• If your site stores customers' details, ask your host or an adviser whether you need to tell anyone.

How we run our own apps

None of our apps, and not this website, use PHP. They are built with different tools and hosted on Vercel, so this particular flaw has nothing to get into. That is a consequence of how they were built, not something we did this week. Plenty of well-run businesses use PHP.

Modern setups have security updates of their own, and we apply them. We also run automated checks on a schedule:

• Every week: a look for new errors in our apps, and a check across all of them for anything that has drifted out of line.
• Every month: an outside test that tries to read each app's data the way a stranger would, a check for settings missing from the live apps, and a check that everyone who pays is on the right plan.
• Every quarter: a check that what this website says matches what the apps actually do.

No setup is immune to every flaw. Checks like these are how we try to spot problems early. Whatever your website runs on, the two things worth knowing are what it is built on and who keeps it updated.