The critical PHP flaw of October 2026: is my website affected?

1. Does your site run on PHP?

• Yes, almost certainly: WordPress installed on a hosting plan, WooCommerce, PrestaShop, Joomla, Drupal, Magento, OpenCart, or a custom site built with Laravel or Symfony.
• Not your job: Shopify, Wix, Squarespace and WordPress.com. The servers belong to the platform, and the platform updates them.
• Usually not: sites built with Lovable, Bolt or v0 and published on Vercel or Netlify.

Also count what sits next to the shop: a WordPress blog on a subdomain (say blog.yourcompany.com) or an old site nobody switched off. If you don't know how your site was built, ask whoever built it.

2. Which PHP version do you have?

Look in your control panel. These are the most common places:

• WordPress: Tools › Site Health › Info › Server, on the PHP version line.
• cPanel: Software › MultiPHP Manager, next to the domain. Some hosts call it “Select PHP Version”.
• Plesk: on the domain, the PHP section (PHP Settings).
• Hostinger (hPanel): Websites › Dashboard › PHP Configuration, in the sidebar.

You're covered if your version is the same as, or newer than, the fixed one on the same branch:

• PHP 8.5: 8.5.12 or newer
• PHP 8.4: 8.4.27 or newer
• PHP 8.3: 8.3.36 or newer
• PHP 8.2: 8.2.35 or newer

A lower number doesn't always mean the fix is missing. Linux distributions (Debian, Ubuntu, Red Hat and others) received the fixes before the 21st, and many apply them without changing the version number. So the right question for your host isn't “which version do you run?” but “does your PHP already include the 21 October fixes?”.

PHP 8.1 or older: the PHP project no longer updates it. Some vendors publish their own fixes for old versions; if yours doesn't, the way out is moving to a supported version. And 8.2 stops getting fixes on 31 December 2026: if you're on it, update now and plan the move to 8.3 or newer.

3. Updating: who does what

• Shared hosting (most small business WordPress sites): PHP belongs to the host. You pick the version in the panel, but they install the fixes.
• Your own server or a VPS: update PHP through your distribution's package manager, or to one of the versions above, and make sure PHP and the web server have restarted. Until then the old version may still be running.
• Someone looks after the site for you (an agency, a freelancer): send them this page and ask them to confirm in writing.

For your host, a message like this is enough: “Hello. My website, yourcompany.com, runs on PHP. On 21 October the PHP project fixed two critical flaws (CVE-2026-109618 and CVE-2026-109619) in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Can you confirm whether the PHP on my hosting already has these fixes, or when you will install them?”

Careful when changing versions. Within the same branch (from 8.3.30 to 8.3.36, for example) the risk of breaking something is minimal. Jumping branches (from 7.4 or 8.1 to 8.3) can leave old plugins and themes not working: take a backup first and check the site straight after.

4. If you can't update yet

The PHP project published temporary measures, but it says they reduce exposure and don't make the server safe. They're for whoever runs the server: on shared hosting, the host applies them.

A security plugin isn't enough: in the worst case (Apache with mod_php), the demonstrated attack happens before any of the site's code starts running, so the plugin never even sees it. Hiding your PHP version doesn't protect you either: the attack doesn't need to know it.

5. After updating: did someone get in first?

Updating closes the door, but doesn't tell you whether someone got in before it closed. If your site stayed on an old version after 21 October, do this:

1. In WordPress, under Users, look for administrators you don't recognise.
2. Ask your host for a malware scan of your account, and run a security plugin's scan as well.
3. Change the passwords for every way in: the hosting panel, FTP or SFTP, the database and the site's administrators. In WordPress, also replace the secret keys in wp-config.php: that ends the sessions of anyone still logged in.
4. Replace the keys stored on the site: the payment ones (Stripe, PayPal), the password of the email account the site sends from, and the keys for AI services that plugins use. Whoever controls the server can read them, and a stolen AI key gets spent on your bill.

If you find signs of an attack and the site holds customer data, in the EU and the UK the GDPR requires you to tell your data protection authority within 72 hours, unless a risk to people is unlikely. Get help from your host or a professional before cleaning up: a bad clean-up leaves doors open.

What Excubitor sees, and what it doesn't

The free check only reads what is public and doesn't tell you your PHP version: you see that in your panel, or ask your host. What it tells you is what can be seen from outside: whether the certificate is valid, whether someone can send email pretending to be your domain, and what's missing from the site's security headers, with the evidence for each point.

A tip from WordPress's own documentation: a hijacked site is often used to send spam, and if your business email goes out from the same server, blocklists catch both. Having your email with a separate provider (Google Workspace, Microsoft 365) keeps them apart.

So you don't have to check again

We don't watch PHP, but we do watch the rest of the domain: Excubitor can check your domain every week (the certificate, the email records, the headers) and email you only when something changes. Free for 1 domain: run the check and press “Notify me”.

SPF, DKIM and DMARC step by step (the values work for any domain)