Contents
- What actually happened this week
- The MFA story that should change how you think
- It was not just PHP
- Why WordPress owners should care more than most
- AI is on both sides of this fight now
- The plain-English checklist: what to do this week
- What not to do
- Why this week, and not next month
- Frequently asked questions
- The bottom line
You know that feeling when you put off an update because everything seems fine?
Your site loads. Your posts are there. Nobody has complained. So the little red update badge sits there, ignored, for another day. Then another week.
This is the week to stop doing that.
Not because someone is trying to scare you. Because, as of the overnight security roundup on 28 October 2026, active exploitation of critical PHP flaws was dominating the news, and a suspected campaign was already scanning the internet for sites that had not patched yet.
That is the part that matters most. Attackers are not waiting for you to feel ready. They are scanning first, and asking questions later.
What actually happened this week
Let us keep this simple, because security news loves jargon and most site owners do not.
PHP is the language that runs WordPress, and a huge share of the rest of the web with it. When a serious flaw is found in PHP itself, it is not just one site at risk. It is every site running that version, all at once.
On 21 October 2026, patches were released for two critical PHP flaws, rated CVSS 9.2. That number is a severity score, and 9.2 out of 10 is about as serious as it gets.
Then came the scanning.
According to the 28 October overnight roundup, a suspected North Korean campaign scanned 216 hosts for those two flaws. Read that again: 216 hosts, checked to see whether they were still vulnerable. This was not a quiet, targeted attack on one famous company. It was a sweep, looking for anyone who had left the door open.
A further PHP remote code execution advisory was also reported in the same window, and Microsoft pushed out-of-band fixes for .NET, including a Brotli bug. Out-of-band just means Microsoft did not wait for its normal monthly update day. When a company breaks its own schedule to ship a fix, that is usually a sign it does not want to wait either.
None of this means your site is definitely hacked. Scanning is not the same as breaking in. But scanning is how attackers build a list. Patching is how you get yourself off that list.
The MFA story that should change how you think
Here is the second story from the same roundup, and honestly, it might be the more important one for ordinary users.
Security firm Huntress reported that attackers replayed stolen Microsoft 365 session tokens, bypassing multi-factor authentication, to compromise email at 79 organizations. About 497 sign-ins succeeded, against more than 200,000 failures.
Let us translate that into plain English.
A session token is like a wristband at a concert. Once you have proved who you are at the door — password, plus that code from your phone — the system gives you a wristband so you do not have to prove yourself again every single time you move around. That is convenient. It is also, in this case, the weak point.
If an attacker steals that wristband, they do not need your password. They do not need your phone code either. They just walk in wearing the wristband, and the system waves them through.
That is why the usual advice — “just turn on MFA and you are safe” — needs an update. MFA is still essential. Please do not turn it off. But MFA protects the front door. It does not help much if someone has already copied the wristband from inside.
The fix, for users and admins, is less exciting but very real: sign out of sessions you do not recognise, revoke sessions when you change a password, and treat any “new sign-in” alert as something to check immediately, not something to swipe away.
This is also why the roundup’s advice was blunt: patch PHP and .NET now, and rethink your assumptions about MFA. Not panic. Rethink.
It was not just PHP
The same overnight window had two more threads that site owners and developers should know about, even if they sound like developer-only problems.
First, GitHub token theft was reported. A token, in this context, is a kind of secret key that lets a tool or a script act on your behalf without typing your password every time. If that key leaks, someone else can act as you, at least until the key is revoked. That is why developers are told, over and over, never to paste tokens into public code, chat logs, or screenshots.
Second, booby-trapped npm packages were reported — packages that only act at runtime. Npm is a huge library of reusable code that developers pull into their projects. Most packages are fine. But a malicious package can sit quietly during installation, when security tools are watching, and only do something harmful later, when the code actually runs. That is a sneaky trick, and it is exactly why “install it and forget it” is a bad habit for dependencies as well as for plugins.
You do not need to understand every detail of npm to take the lesson from this. The lesson is the same across all three stories: the boring maintenance jobs — updating, revoking, checking — are the security jobs. There is no clever shortcut that replaces them.
Why WordPress owners should care more than most
If you run a WordPress site, and you are reading this on a site about WordPress, SEO, and tech tips, this story is not abstract for you.
WordPress runs on PHP. Your host runs PHP. Your plugins and your theme sit on top of PHP. So when PHP itself has a critical flaw, updating WordPress alone is not the whole job, and updating PHP alone is not the whole job either. You need both layers in good shape, plus the layers in between.
Think of it like a house. PHP is the foundation. WordPress is the house built on it. Plugins are the furniture and the locks on the doors. A crack in the foundation matters even if your front door lock is brand new.
That is also why small sites get hit. Attackers scanning 216 hosts are not looking for the biggest prize. They are looking for the easiest one. A small blog, a local business site, a portfolio page — if it is unpatched and connected to the internet, it is on the list. Small sites are often targeted precisely because their owners assume nobody would bother.
And here is the uncomfortable part: a hacked small site is not just a problem for its owner. It can be used to send spam, host phishing pages, or attack other sites. Patching is not just self-protection. It is good internet citizenship, in the least preachy sense of that phrase.
If you want a sense of how fast this kind of wave can grow, look at what happened in South Korea in the same week. Financial firms, an asset manager, and a crypto exchange were all hit, and investigators were still examining whether the attacks were connected. We cover that wave in detail in South Korea’s Hacking Wave Just Hit Brokerages and Crypto — What Leaked. Different targets, different country, same lesson: once a wave starts, it does not stay in one place.
AI is on both sides of this fight now
There is another thread running through this week’s security news, and it is worth naming clearly.
AI is making attacks easier to run at scale. The Japan Times reporting on 28 October described AI helping attackers identify weaknesses in individual websites, including everyday services like library catalogues, train seat reservations, and university booking systems. We go deeper into that trend in AI Is Now Finding the Weak Spots in Everyday Websites.
That is the dark side. But it is not the whole story about AI, and it is worth keeping some perspective.
The same kind of AI that can scan a website can also scan a photo and help a normal person. Just yesterday, we wrote about a man who lost a white earbud in white gravel, and ChatGPT found it in under five minutes after he uploaded closer, top-down photos. Same technology family, completely different use: one person using AI as a patient second pair of eyes, another using automated tools to hunt for unpatched servers.
That contrast matters, because it stops us from falling into two traps. The first trap is thinking AI is magic and will save us. It will not. The second trap is thinking AI is only a threat. It is not. It is a tool, and like every powerful tool, the question is who is using it, and whether the rest of us are keeping our own defences up to date.
For site owners, the practical version of that is simple: you cannot out-clever an automated scanner. You can only make sure that when it knocks on your door, there is nothing vulnerable for it to find.
The plain-English checklist: what to do this week
Okay. Enough background. Here is what to actually do, in order, without any attacker tricks and without any steps that require you to be a security expert.
1. Back up first, then update.
Before you touch anything, take a full backup of your site — files and database — and check that you can actually download it. A backup you cannot restore is just a comforting file name. Then update PHP through your hosting panel, update WordPress core, update your theme, and update your plugins. If your host offers a managed PHP version, ask them which version is currently supported and patched, and switch to it.
2. Remove what you do not use.
Deactivated plugins and themes are not harmless clutter. They are code sitting on your server, and old code can still have old flaws. If you have not used a plugin in months, delete it, do not just deactivate it. Same for themes you tried once and never used again. Fewer moving parts means fewer things to patch.
3. Check for strangers in your admin area.
In WordPress, go to Users and look for any administrator account you do not recognise. Check your recent posts and pages for anything you did not publish. Check your site’s front page in a private browser window, not just while logged in, because some hacks only show themselves to visitors. If anything looks wrong, do not just delete the post and move on — restore from a clean backup and change your passwords.
4. Change passwords and revoke sessions.
Change your WordPress admin password, your hosting password, and your email password, using a different password for each. Then sign out of all sessions where your account settings allow it, and sign back in on the devices you actually use. This is the practical answer to the stolen session token problem: a stolen wristband stops working once the wristbands are all cancelled and reissued.
5. Turn on MFA, and keep it on.
Yes, we just explained how session replay can bypass MFA. That does not make MFA useless. Far from it. MFA still blocks the vast majority of password-only attacks, which are still the most common kind. Turn it on for WordPress, for your hosting account, and for your email. If your site offers a security plugin with login alerts, turn those on too, and actually read them.
6. Update .NET and other server software if you run it.
If you run any Windows-based or .NET services, apply Microsoft’s out-of-band fixes promptly, through your normal update channel. Do not download patches from random links in emails or forums. Use your host’s or Microsoft’s own update tools. The same rule applies to PHP: update through your host, not through a file someone sent you.
7. For developers: rotate tokens and audit dependencies.
If you use GitHub tokens, API keys, or npm packages, this is a good week to rotate any token that might have been shared, pasted, or stored somewhere unsafe, and to update your dependencies. Check your project’s dependency list for packages you no longer need, and remove them. Again, this is defensive housekeeping, not hacking advice, and it is the kind of job that prevents a quiet leak from becoming a loud incident.
8. Set a monthly reminder, and keep it.
Patching once is good. Patching every month is what actually works. Put a recurring reminder in your calendar: first week of the month, backup, update, check users, done. Fifteen minutes, once a month, is a lot cheaper than a hacked site, a lost ranking, and a week of cleanup.
What not to do
A few honest warnings, because security advice on the internet is not always good advice.
Do not download a “PHP fixer” tool from a random site. Do not run a script someone posted in a forum without understanding what it does. Do not pay someone who emails you claiming your site is already hacked and offering to fix it for a fee — check your site yourself first, or ask your host.
Do not ignore the update because your site “still works.” A hacked site often still works, at least at first. That is the point. Attackers want it to keep working, quietly, while they use it.
And do not assume your host will handle everything. Good hosts patch the server, and many will update PHP for you. But your WordPress plugins, your theme, your users, and your passwords are usually your job. If you are not sure where the line is, ask your host directly: “What do you patch, and what do I need to patch?” Write down the answer. That one email can save you a lot of guessing later.
Why this week, and not next month
It is tempting to file this under “I will get to it when I have time.” The scanning numbers are the reason not to.
When a flaw is patched on 21 October and a campaign is reported scanning for it by 28 October, the window between “fix available” and “attackers looking” is about a week. That window is getting shorter, not longer, because scanning is increasingly automated.
That does not mean you need to panic at midnight. It means you should treat patching like locking your front door at night. You do not do it because you are certain someone will try the handle tonight. You do it because it is cheap, it is quick, and the one night you forget is the night it matters.
Microsoft is a useful example of the wider mood this week. The same company pushing emergency .NET fixes is also, as we covered in Microsoft Offered Buyouts to 60,000 Staff While Pouring Money Into AI, reshaping its workforce while spending heavily on AI infrastructure. Big companies are moving fast, cutting costs, and investing in AI at the same time — and security is caught in the middle of all of it. Small site owners cannot control any of that. What they can control is their own update button.
Frequently asked questions
Does this mean my WordPress site is already hacked?
Not necessarily. Scanning is not the same as a successful break-in. But you cannot tell from the outside whether a scan found something. The safe move is to patch, check your admin users and recent content, and change your passwords. If you find something you did not create, restore from a clean backup and ask your host for help.
I updated WordPress. Is that enough?
It is a great start, but it is not the whole job. WordPress runs on PHP, so your PHP version needs to be patched and supported too. Check with your host. Also update your theme and plugins, and delete the ones you do not use.
I have MFA turned on. Am I safe from the Microsoft 365 token attack?
MFA still helps a lot, and you should keep it on. The token replay attack works differently: it reuses an existing session instead of logging in fresh. That is why revoking sessions, signing out everywhere after a password change, and checking sign-in alerts matter alongside MFA, not instead of it.
What is CVSS 9.2, in plain English?
It is a standard severity score from 0 to 10. A score of 9.2 means the flaw is rated critical — relatively easy to exploit, with potentially serious impact. It does not tell you whether your specific site is targeted, but it does tell you to treat the patch as urgent.
Should I stop using plugins altogether?
No. Plugins are one of the reasons WordPress is so useful. The goal is not zero plugins. The goal is only the plugins you actually need, from sources you trust, kept up to date. A small, maintained set beats a large, forgotten set every time.
What if my host will not let me change the PHP version?
Ask them what patched versions they offer, and when they plan to move older versions out of support. If your host cannot offer a supported, patched PHP version, that is a real reason to consider moving hosts. Your site’s security should not depend on an unsupported foundation.
The bottom line
Two critical PHP flaws. A patch on 21 October. Scanning reported by 28 October. Stolen session tokens bypassing MFA at 79 organizations. GitHub tokens stolen. Npm packages that wait until runtime to act.
None of that is a reason to panic. All of it is a reason to patch.
Back up, update PHP, WordPress, your theme, and your plugins. Delete what you do not use. Check your users. Change your passwords, revoke old sessions, and keep MFA on. Then set a monthly reminder and do it again next month.
The internet rewards the boring, regular jobs. This week, the boring job is the important one.
