You did everything right. You kept your plugins up to date. But that is how the malware got in.
On 15 October, Rank Math PRO, an SEO plugin for WordPress, shipped an update with malware inside. It was live for 11 hours. Rank Math's clean-up guide asks you to open your website's database, find a table called wpoptions and delete an entry with a random name like uf6qdn2hmm. Then check the .htaccess file. Then search the server for hidden PHP files. Do it in the right order, the guide warns, because the malware rebuilds itself every time someone visits the site.
If you are a designer or a marketer, you probably read that paragraph twice.
Think about who installs an SEO plugin. It is rarely a developer. It is the marketer who wants the blog to rank. It is the designer who set up the site for a client and turned on auto-updates to keep it safe. The plugin did its job. It also became a way into the site.
Every website lives on a server. That part is not the problem. The problem is a CMS that runs on the same server as your live site, with plugins, a login page and a database that anyone on the internet can reach. Every plugin, every login page and every database is a door. Security people call all of those doors together the attack surface. When one of them gets kicked in, the person who has to fix it is often the person who built the site, or the person who runs it. The fix is not in Figma. It is not in your content calendar either.
The good news: you decide how many doors your website has. Most marketing sites have far more than they need. Here is how to count them, and how to reduce your website's attack surface.
It was not only one plugin
Rank Math was not alone. Look at these seven days in October:
- 14 October. Drupal, another CMS that runs on the same server as the live site, released an emergency fix for every supported version. Its security team asked site owners to reserve time for the update, because "exploits might be developed within hours or days" (Drupal).
- 15 to 16 October. The Rank Math PRO update with malware inside was live for 11 hours (Rank Math).
- 17 to 18 October. Attackers got into teamupdraft.com, the company behind the UpdraftPlus backup plugin. The plugin itself was clean. But the attackers used the company's connection keys to reach customers' sites, create admin accounts and install malicious plugins (TeamUpdraft).
- 20 October. PHP, the programming language WordPress is built with, announced two critical security holes and asked all users to "prepare now" for a fix the next day (PHP).
Four alarms in seven days. Each one asked site owners to stop what they were doing and update, check or restore.
The attackers are also getting faster. TeamUpdraft wrote that the speed of the attack on its customers' sites suggests "that the hackers used AI to accelerate their attack".
Updates alone cannot keep up
"Keep everything updated" is good advice. It is not enough. Patchstack, a company that tracks security holes in WordPress, counted what happened in 2025 (Patchstack):
- 11,334 new security holes were found in WordPress sites and their add-ons. That is 42% more than the year before.
- 91% of them were in plugins. Only 6 were in WordPress itself.
- 46% had no fix from the developer when the hole became public.
- The most targeted holes were under attack a median of 5 hours after they became public.
- In Patchstack's test of hosting companies, the hosts blocked only 26% of the attacks.
An update can only close a hole after someone finds it and fixes it. In 46% of the cases, that fix did not exist yet. And in the Rank Math case, the update was the attack.
This is not only a WordPress problem
Drupal had the same kind of week. So does any website that runs code on a server for every visitor.
Node.js, the JavaScript engine many modern websites run on, fixed 12 security issues in a single release in June, most of them in every supported version (Node.js). If your site needs Node.js on a server to show a page, those fixes are your problem too. More on that in Do you need Next.js to publish a website?
The pattern is the same each time. A server builds the page when a visitor asks for it. Often it asks a database first. That work happens on every visit, even when the page has not changed in a year. Each step is code that someone has to patch, on someone else's schedule. The longer version is in Does your website need a database?
Every CMS uses a server. The question is which one.
A visitor's browser has to get your page from somewhere, so every website is on a server. The useful question is not "server or no server". It is: where does your CMS run, and what does the server do?
There are three common answers:
- The CMS runs on the live server. WordPress and Drupal work this way. You edit in your browser, but the editor, the database, the plugins and the public site all share one server. The admin login sits on the same address your visitors use.
- The CMS runs in your browser, on the vendor's servers. Webflow, Wix, Squarespace, Framer and hosted CMS tools like Sanity work this way. The vendor patches the servers for you, and that closes many doors. But your content, your login and the keys to your site now live in the vendor's cloud. When the vendor has a bad day, so do you. More on that in We reached the limit of the browser.
- The CMS runs on your computer. You edit on your own device. The server only stores the finished files and sends them to visitors. There is no editor, no login and no database on the server for anyone to reach.
The UpdraftPlus attack shows the risk of the second model. The plugin was fine. The company's own website was not, and the keys stored there led to customers' sites.
Count the doors on your website
The OWASP Foundation, a non-profit for web security, defines the attack surface as "the sum of all paths for data/commands into and out of the application" (OWASP). In plain words: every place where someone can send something in, or get something out.
Here is how the doors compare for the three kinds of CMS:
| CMS on the live server | CMS in the browser | CMS on your computer | |
|---|---|---|---|
| Where you log in to edit | On your live site | On the vendor's website | On your own computer |
| Where your content is stored | A database on your server | The vendor's cloud | Files in a folder you own |
| Who runs and patches the server | You or your host | The vendor | Your host |
| Plugins that run code on the server | Yes | No | No |
| Outside services with keys to your site | Often (backup, SEO and security tools) | The vendor holds them | No |
| Doors left for you to lock | Server, database, login, plugins, hosting, domain | Vendor account, domain | Your computer, publishing account |
A static website still lives on a server. The difference is what that server does. It stores a set of finished files, HTML, CSS and images, and sends the same file to every visitor. Nothing runs. Nothing asks a database. There is no login page to guess.
That is why this week's alarms did not reach static sites. The PHP fix does not apply when there is no PHP. The Rank Math malware had nowhere to install itself, because there are no plugins on the server. The UpdraftPlus keys had no site to connect to.
Static does not mean zero doors. Three stay open: your hosting account, your domain, and the place you publish from. That is a short list. It is a list a designer or a marketer can protect without opening a database.
How to reduce your website's attack surface
- List every door. Write down every plugin, every login and every outside service that connects to the site. If nobody can say why it is there, remove it. With 91% of WordPress security holes in plugins, each plugin you remove is one less door.
- Stop rebuilding pages that do not change. A pricing page, an about page and a blog post look the same for weeks. They do not need a CMS and a database on the server to build them again on every visit. Publish them as static files.
- Give the moving parts to a specialist. A contact form, a newsletter sign-up or a shop can use a dedicated service whose only job is to run that one thing safely. Your site links to it. It does not run it.
- Lock the doors that stay. Turn on two-factor authentication for your hosting account, your domain registrar and the account you publish from. Use a password manager for all three.
- Keep a copy you control. Rank Math's first advice was to restore the site from a backup made before the attack. A site that is a folder of files with a full history can go back to any earlier version, without a backup plugin.
Where Splitleaf fits
In Splitleaf, your website is a folder of files on your own computer. The CMS does not run on your live server, and it does not run in a browser tab on a vendor's cloud. It runs in the desktop app on your computer (The CMS for the AI era lives on your device). When you publish, your host gets plain static files (Host where you want).
That means no database on the server, no admin login to guess and no plugin that runs code for each visitor. Every change is saved in a GitHub repository you own (Own your code), so you can go back to any earlier version of the site.
What is left to protect is short: your computer, your GitHub account and your host.
This week, four alarms went off for websites whose CMS runs on the live server. A static site did not need to answer any of them.
See how Splitleaf publishes your site as static files
Questions
Is a static website more secure than WordPress?
A static website has fewer doors. It is still on a server, but the server only sends finished files. There is no CMS, no database and no admin login on it. The doors that stay are your host, your domain and the account you publish from. Fewer doors means fewer ways in. It does not mean none.
Is a browser-based website builder safer than WordPress?
The vendor patches the servers for you, so you manage fewer doors yourself. But your content, your login and the keys to your site sit in the vendor's cloud. A problem at the vendor reaches your site too.
Does a static website need security updates?
The pages do not, because they are finished files. The accounts around them do need care. Protect your hosting account, domain and publishing account with two-factor authentication.
Can a static website have a blog or a contact form?
Yes. A blog is a set of pages built before you publish. A contact form can send to a dedicated form service. Neither needs a database on your server.