Well… this week was a lot. Between a massive PHP vulnerability and a pile of other breaches, it’s been one of the wildest weeks for internet security I can remember. This is pretty unprecedented as far as digital impact goes, so I wanted to put together a quick update.
What happened this week
On Wednesday, October 21, PHP released emergency patches for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619). Both let an attacker run their own code on a web server without even logging in. Then the details leaked before the patch was out, so attackers got a head start. Supposedly, mass attacks were expected to start within minutes of the patch going public.
PHP sits underneath a huge share of the web: WordPress, Magento, Joomla, Laravel, MediaWiki and plenty of custom-built sites. When something this deep breaks, everything built on top of it is exposed until it’s updated. Ars Technica has a good overview of the patches.
And that’s just PHP. This post from @fiveoutofnine captures how much hit at once better than I could:
Read @fiveoutofnine's rundown on X
The short version, if you don’t want to read the whole thing:
- Government agencies told people to take systems offline. Several national cybersecurity agencies, and even Japan’s Prime Minister, urged organizations to pull vulnerable sites until they were patched.
- Big names went down. Wikipedia, Archive.org, Asana and a number of government sites went offline while teams scrambled.
- GitLab patched a top-severity bug that had been sitting in self-hosted installs since 2014.
- Developer tools were compromised. A popular AI library (LiteLLM) shipped a credential stealer in its packages, and the hosting platform Railway paused all deployments after someone got into stored secrets.
- Node.js and Plex both patched serious flaws, and Plex is being actively exploited.
- A certificate authority, whose whole job is proving websites are who they say they are, was reportedly using private keys that were trivially easy to guess.
Why this matters for your business
Here’s the thing… most of these attacks are automated. Once a vulnerability is public, bots sweep the internet looking for any site still running the old version. They don’t care whether you’re a huge company or a five-person team.
That’s why the gap between “patch released” and “patch installed” matters so much. You definitely don’t want to be caught running an older version. Sites that update quickly mostly move on. Sites that sit on an old version for weeks or months end up with defaced pages, spam injected into their content, stolen form submissions or a blacklisting from Google.
It goes beyond the website, too. Your domain registrar, DNS, email, hosting account and the logins your team shares all hold the keys to your online presence. Your domain settings are wicked important here. If someone gets into them, they can redirect your site or your email without ever touching the website itself.
Proactive is always easier
I’ve reminded a few clients of this over the past couple of days: it’s always easier to be proactive with this than need to fix a hacked or broken site. It’s a lot cheaper, too.
Routine maintenance is predictable. Updates get scheduled, tested and applied, usually without anyone noticing. A breach is the opposite. You’re paying for emergency developer time, malware cleanup, restoring from backups (if you have good ones), resetting every password, and sometimes rebuilding parts of the site from scratch. Then there’s the cost you can’t invoice for: downtime, lost leads, search rankings that take time to recover, and awkward emails to customers whose information may have been exposed.
I’m not trying to scare anyone here. Just trying to keep everyone safe!
A quick checklist for this week
You don’t need to do all of this today. Start at the top and work your way down.
- Update anything running PHP. If you have a WordPress, Magento, Joomla or custom PHP site, confirm with your developer or host that PHP itself has been patched, along with your CMS, themes and plugins. Our PHP patching guide has the fixed versions and walkthroughs for 20 hosts.
- Turn on two-factor authentication for your website platform, domain registrar, DNS provider, email and hosting. If you only do one thing on this list, do this one.
- Replace shared or reused passwords with long, generated ones stored in a password manager. Especially if it’s a password the team re-uses.
- Clean up who has access. Remove former employees, past contractors and old agencies from your website, domain and analytics accounts.
- Rotate secrets on affected platforms. If you or your developer use Railway, LiteLLM, self-hosted GitLab or Node.js, update and rotate API keys and passwords stored there.
- Confirm your backups work. Ask your host or developer when a restore was last tested, and run one if the answer is “never.”
- Know who to call. Write down who handles your website, hosting and domain, so you’re not hunting for logins in the middle of a problem.
Your stack and the people behind it
Every platform has tradeoffs, and none of them are safe on autopilot. The biggest difference comes from two choices: the architecture you build on, and the people responsible for keeping it healthy. The architecture decides which pieces need maintaining. The people decide whether that maintenance actually happens.
Here’s roughly who’s on the hook for what, depending on how your site is set up:
| Layer | Self-hosted site (WordPress, custom PHP, Magento) | Managed platform (like Webflow) |
|---|---|---|
| Server and operating system | Your host or developer | The platform |
| PHP or other runtime | Your host or developer | The platform |
| CMS core updates | Your developer | The platform |
| Plugins, themes and integrations | Your developer | You, for any third-party apps you add |
| Custom code and third-party scripts | Your developer | You or your developer |
| Logins, 2FA and team access | You | You |
| Domain and DNS | You | You |
| Backups | Your host or developer | The platform keeps site backups; anything outside it is yours |
Managed WordPress hosting lands somewhere in between. The host usually handles the server and PHP, and someone still needs to stay on top of plugins and themes.
Neither column wins on its own. A self-hosted site has more moving parts, and a team that stays on top of them can run it safely for years. A managed platform takes the server off your plate, and you’re still responsible for everything in the bottom half of that table.
A good example from this week: an agency we work with manages a whole portfolio of WordPress sites. When I flagged the PHP issue, they checked and every one of their clients was already on a current PHP version that wasn’t affected. Their routine updates had already done the work before anyone knew there was a problem.
Same goes on the managed side. One client recently swapped a shared password for a long generated one and turned on two-factor authentication the same day I brought it up. That’s the kind of small step that keeps a bad week from turning into a disaster.
Questions to ask whoever manages your site
These are worth asking whether you’re on WordPress, Webflow or something custom. If you don’t know the answers, that’s a good conversation to have this week.
- When were the server, PHP version, CMS and plugins last updated?
- Who’s watching for security news like this, and how quickly can a critical patch go out?
- Is two-factor authentication on for the website, hosting, domain registrar and email?
- Who has admin access right now, and does everyone on that list still need it?
- Where are the backups, how far back do they go, and when was a restore last tested?
- If the site went down tonight, who would you call, and do they have the logins they need?
How we handle it at Clarity
Most of the sites we build run on Webflow. We chose it partly because the platform handles server and runtime patching, so this week our Webflow clients didn’t need any emergency work. Our job is the rest of that list: watching for issues like this, flagging them early, and helping clients lock down the accounts and domain settings around their site.
When a client has a PHP site that needs hands-on care, we connect them with a developer who specializes in it. The right system matters, and so does having the right person looking after it.
Keep your eyes peeled
Keep your eyes peeled on everything digital for the next few months… It’s going to be pretty wobbly while they patch up these vulnerabilities and discover new ones. A few things worth a closer look if you spot them:
- New admin users or accounts you don’t recognize
- Pages, links or spammy content on your site that nobody on your team added
- Your site redirecting visitors somewhere unexpected
- A security warning in Google Search Console, or a browser warning when you visit your site
- Password reset or login alert emails you didn’t trigger
- Emails or calls about “urgent security updates” asking for logins or payment. Scammers love a week like this, so check with your developer before acting on anything.
If you’re not sure where your systems stand, or want a second set of eyes on your site, domain or accounts, reach out. Happy to help you sort out what needs attention now and what can wait.