On October 21, 2026, PHP, the language most business websites run on, shipped an emergency fix for two flaws that let a stranger run code on your server without logging in. Attack traffic was already moving before the fix was public.
Updated October 22, 2026. Written by Rares Rata, who runs SEO and AI Search at We Lead in Naples. We are not a security company. This is the check we run on every website we build and maintain, written down so you can run it on yours in under an hour.
If your website is on a managed host or a shared hosting plan, the host patches PHP for you, and most did so on October 21 or 22. Your job is to confirm it, then use the moment to run the seven checks below: PHP version, updates, hosting responsibility, backups, logins, HTTPS and forms, and monitoring. The flaw is in PHP itself, so it applies to WordPress, Joomla, Drupal and anything else written in PHP. Site builders such as Wix and Squarespace handle it entirely on their side.
What happened on October 21, 2026?
Two vulnerabilities in the core of PHP, tracked as CVE-2026-109618 and CVE-2026-109619, were fixed in an out-of-schedule security release. Both allow unauthenticated remote code execution, which is the plain-English worst case: someone who has never logged in sends a crafted request and ends up running their own code on the server. The PHP team rated both 9.2 out of 10 and said every installation serving web requests is at risk, whatever the server setup.
Three details make this one unusual. Details of the flaws leaked a day before the patch, so the release was pulled forward. Cloudflare turned on protective rules at 3:02 am UTC on October 21, about nine hours before public disclosure, and reported attack traffic aimed at its customers. And WordPress.org said the same day that no WordPress update is required or planned, because the problem sits underneath WordPress: the fix is updating PHP.
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer get updates from the PHP project at all, and PHP 8.2 stops getting them on December 31, 2026. If your site runs on one of those, this is the week to move.
Does this affect my business website?
It depends on who runs the server, not on how big your business is.
| Your setup | Who patches PHP | What you do |
|---|---|---|
| Wix, Squarespace, Shopify or another site builder | The platform, invisibly | Nothing for this flaw. Run checks 5 to 7 anyway. |
| WordPress on shared or managed hosting (most Naples small businesses) | Your hosting company | Confirm the patch landed. Run all seven checks. |
| WordPress on a VPS or a server someone set up for you | Whoever manages that server | Find out who that is today. If it is nobody, that is the finding. |
| A custom PHP application | Your developer or IT provider | Ask them in writing which PHP version is live now. |
Hosts applied partial mitigations too. One of them, turning off a PHP feature called session upload progress, costs a WordPress site nothing, because WordPress does not use it. If your host mentions it, that is a good sign, not a worry.
The 7-point website security check
In the order we run it. Each step says how to check and what a good answer looks like.
Is your PHP version patched?
In WordPress, go to Tools, then Site Health, then the Info tab, then Server. You want 8.3.36, 8.4.27, 8.5.12 or 8.2.35, or newer. One caveat: some hosts apply the fix without changing the version number, so if you see an older number and your host says it patched, ask them to confirm in writing rather than assuming either way.
Good answer: a patched version, or a written confirmation from the host dated October 21 or later.
Are WordPress, your theme and every plugin up to date?
This is where most real-world break-ins happen. Patchstack counted 11,334 new vulnerabilities across the WordPress ecosystem in 2025, 42% more than the year before, and 91% of them were in plugins. The median time from public disclosure to first exploit for the heavily attacked ones was five hours. Updates are the whole defense, and a plugin you no longer use is still an open door: delete it, do not just deactivate it.
Good answer: zero pending updates in Dashboard, then Updates, and no plugin installed that nobody can explain.
Who is responsible for your hosting?
Write down three things: the hosting company, who has the login, and who gets their emails. The October notice went to the email address on the hosting account. If that address belongs to a former employee or a web designer you no longer work with, you did not get it. Also ask the host whether each website runs in its own isolated account, so a problem on a neighbor’s site cannot reach yours.
Good answer: you can log in to the hosting panel yourself, and the contact email is one you read.
Do you have a backup you have actually restored?
A backup you have never restored is a hope, not a backup. Most hosts keep daily copies; the question is whether you know how to use them, how far back they go, and whether they live somewhere other than the same server. Once a year, restore one to a staging copy and open the site. Thirty minutes, and you will sleep better.
Good answer: daily backups, kept at least 30 days, off the server, restored successfully at least once.
Are your logins protected?
Go to Users in WordPress. Every account should belong to a person you can name, with a unique password and two-factor authentication on. Remove the old agency, the intern from 2023 and the generic “admin” user. Keep administrator rights to the two or three people who need them. Do the same on the hosting panel and the domain registrar, which attackers love because that is where the whole site can be redirected.
Good answer: every user is named, two-factor is on for admins, and nobody who left the business still has access.
Is HTTPS on everywhere, and is your contact form protected?
Open your site on a phone and check the padlock on every page, not just the homepage. Then look at the contact form: it is the one place strangers can type into your site. It should have spam protection that does not punish real customers (a hidden honeypot field and a submission limit do the job without a CAPTCHA), and every message should be stored, not just emailed, so a mail hiccup never loses a lead.
Good answer: padlock on every page, a form that stores submissions, and no spam flood in the inbox.
Would you know if something went wrong?
Most hacked small-business sites are found by a customer, or by Google, weeks later. Three free alarms: an uptime monitor that texts you when the site is down, Google Search Console, which has a Security Issues report and emails you when it finds one, and the Site Health screen in WordPress, which you should glance at monthly. If Google flags a site, rankings and trust drop fast, and getting them back takes far longer than the cleanup.
Good answer: you would hear about a problem within hours, from a machine, not from a customer.
What we found on our own site the next morning
We ran the same seven checks on weleadag.com on October 22. Our host had emailed overnight to say its platform was not exposed in the way the attack expects, and that it was applying the PHP fix across all accounts anyway. We did not take that on trust: the PHP build on our server now carries an October 21 build date, the session upload progress feature was already switched off, the host states that every site runs in its own isolated account, and the eight plugin updates waiting that morning were applied the same day. The version number still read 8.3.35 at the time of writing, which is exactly the caveat in check 1: the fix was there, the label had not caught up.
That is the honest shape of website security for a small business. Not drama, just a short list, run on a schedule, with someone whose name is on it.
What should I do when my host emails about a vulnerability?
Three steps, in order. First, read the email for one sentence: do they say they are applying the fix, or that you must? Second, run checks 1 and 2 above the same day. Third, reply to the host and ask them to confirm, in writing, the PHP version your account is running and the date it was patched. Keep that email. If your website is looked after by an agency or a freelancer, forward the host’s email to them with one line: “Please confirm we are patched.” A good provider answers within a day with a version number, not a reassurance.
Frequently asked questions
Want someone to run this check for you? Our free audit includes the seven points above alongside your rankings and your site’s speed, with a written list of what to fix first. Every site we build comes with checks 4 to 7 already done; see our web design work in Naples.
About the author. Rares Rata runs SEO and AI Search at We Lead in Naples, FL, and maintains the websites the agency builds. If you are deciding who should look after your site, the questions to ask are in how to choose a web design company in Naples, and the platform trade-offs are in WordPress vs Wix vs Squarespace.
