Should Business Owners Panic About WordPress 7.1.1?
Yesterday I mentioned that WordPress 7.1.1 fixes 11 security vulnerabilities, but saying “11 security vulnerabilities” doesn’t really tell a business owner much, does it? So I went through what was actually fixed. There are a few things here worth understanding, because this isn’t just a WordPress technical update. Some of these bugs affect who can change your website, what information people can see, and what can happen when somebody puts malicious content into WordPress.
The one thing I’d pay most attention to is a problem involving WordPress comments. An attacker does not need a WordPress account for this one. They can submit a specially crafted comment through a normal comment form.
At first, WordPress treats that comment as safe, and the problem happens later. When WordPress formats the comment for display, it can accidentally turn part of the comment into executable code. In simple terms, something that looked harmless when it went into WordPress can become dangerous when somebody views it.
Now, there’s an important detail here. The comment still needs to be published, so this does not mean somebody can simply visit your website and instantly take control of it. But depending on your comment settings, some comments can be approved automatically, and once the malicious comment is displayed, code can run in the browser of somebody viewing that page.
Why does that matter for a business? Because if the person viewing that page is somebody logged into WordPress, especially an administrator, the attacker may be able to use that browser session to do things the visitor is authorised to do. Stored attacks like this are particularly nasty because the attacker doesn’t necessarily need to be there when it happens. They leave the malicious content behind, then wait for somebody else to open the page.
Another vulnerability affects people with contributor access or higher. A contributor is normally allowed to write content, but they are not supposed to be able to change somebody else’s existing posts. This bug could allow them to overwrite a post they weren’t supposed to control.
For a small business website with one administrator, that might not sound particularly frightening, but think about a larger website. You might have staff, writers, contractors, SEO people, marketing agencies, or older user accounts you completely forgot about. The more people who can log into WordPress, the more important these permission boundaries become.
There is another issue that again requires somebody to already have a WordPress account, but under the right circumstances, they could manipulate the path WordPress uses when looking for template files. This is what’s called a path traversal vulnerability. You don’t really need to remember the term.
The important bit is this: WordPress is supposed to keep somebody inside a particular part of the file system, and this vulnerability could allow them to reach outside that boundary. The fix makes WordPress check where the requested file actually ends up before using it.
There are also several other permission problems in this release. One could expose the title of a private post, and another could expose the web address of draft or pending content. Another allowed logged-in users to move comments to places they shouldn’t control, and there is also a multisite issue involving network-only plugins, plus another involving WordPress’s XML-RPC system.
Individually, some of those might sound fairly minor, but together they illustrate something really important about website security. Being logged into WordPress should not mean you can do whatever you want. An editor should only be able to edit things, a contributor should be able to contribute things, and a site administrator on a WordPress multisite network should not automatically have the powers of the network administrator.
These boundaries matter, and this is also why old WordPress accounts can become a business risk. Maybe somebody worked for you three years ago, maybe an agency had access, or maybe you created an account for a contractor. And maybe you have 50 customers registering on the website every day.
The vulnerability might require a logged-in user, but that doesn’t necessarily mean the attacker needs your administrator password. So what should you actually do?
First, update WordPress. WordPress itself recommends installing this security release immediately, so if you’re running WordPress 7.1, you should be on 7.1.1. Security fixes have also been released for a number of older WordPress branches, but WordPress makes the point that only the current release is actively supported.
Second, don’t just assume the automatic update worked. Log into WordPress, go to Dashboard, then Updates, and check what version you’re actually running.
Third, look at your users, especially if your website has been around for years. Remove accounts that no longer need access, and make sure people only have the level of access they actually need. If your website allows comments, take a look at your comment moderation settings as well, particularly whether previously approved commenters have future comments published automatically.
The important thing here is not to panic. WordPress 7.1.1 does not mean every WordPress website was about to be hacked. Several of these vulnerabilities require an existing account, some require particular permissions, and the comment vulnerability still requires the malicious comment to be published.
But this is exactly why security updates matter. The software is enforcing boundaries all the time: who can see something, who can edit something, which files WordPress can access, and what content is allowed to run in somebody’s browser.
When one of those boundaries fails, the risk to the business is not just a technical problem. It could become a damaged website, a compromised administrator account, changed content, exposed information, or downtime while somebody cleans the site up.
So the simple takeaway is this. Check your WordPress version, install a security update, review who has access to your website, and then get on with running your business. I’ll keep digging into WordPress security updates like this when there’s something worth explaining.