WordPress 7.1.3 Security Update – What Website Owners Need to Do Today

If your business website runs on WordPress, there’s a new security update you need to know about this morning. WordPress 7.1.3 fixes seven security problems, and some could expose information that was never meant to be public or allow malicious content to affect the website. There’s no evidence at this stage that these vulnerabilities are being actively exploited, so this isn’t about panic. It’s about making sure someone is actually managing the risk.

Hi, I’m Dustin Gray. I’ve been building production software for 25 years, and I look at the security issues that matter each day.

WordPress has released a new security update, version 7.1.3, which fixes seven security issues inside WordPress itself. One could expose comments connected to content that isn’t publicly available. Another could allow malicious content to be stored inside the website and triggered later when someone views it, and another affects the way WordPress handles information being exported.

Now, here’s the important part. There’s currently no evidence that these are being actively exploited, but that doesn’t mean you should ignore the update.

If someone else manages your website, you don’t need to understand how these vulnerabilities work. Just ask them one simple question: are we running WordPress 7.1.3, and has the website been tested since it was updated? Because clicking update is only half the job. You also need to know that the website still works properly afterwards.

This next WordPress story is very different, because attacks have actually been observed. Attackers are targeting vulnerabilities in Ninja Forms and a WooCommerce product bundling plugin. Ninja Forms alone is used on more than half a million websites.

But here’s the interesting part. In the Ninja Forms attack, the attacker needs someone with administrator access to interact with malicious content. Think of it a little like leaving something dangerous inside the website and waiting for an administrator to open it. The administrator is already trusted, so that access can potentially be used against them.

Researchers have observed attackers creating new administrator accounts and hiding their access to make it harder to spot. That’s why simply updating may not be enough. If your website uses Ninja Forms or WPC Product Bundles, ask whoever manages it to check the versions and update where required.

Importantly, also check for administrator accounts or software that shouldn’t be there. Fixing the original weakness doesn’t remove an attacker who already got inside.

Next up, Atlassian. If your organisation uses systems like Jira or Confluence, there’s a newly demonstrated security risk worth checking. The vulnerability can allow an attacker to retrieve certain files from affected systems without logging in.

Again, there are conditions: the attacker needs to know what they’re looking for, and there’s currently no evidence that it’s being actively exploited. But researchers have now demonstrated why the problem can become much bigger. Some of those files can contain information used by other trusted systems.

In one test environment, researchers were able to turn what looked like a file access problem into administrator-level access. And that’s the business lesson. The first system compromised isn’t always the important one; the question is, what can that system access next?

If your organisation runs its own Jira, Confluence or other Atlassian servers, ask your IT team or provider whether you’re affected. Ask whether the fixes have been applied, and whether those systems are unnecessarily exposed to the public internet.

Next, there’s a warning for organisations running Rejetto HTTP File Server. This is software used to share files through a web browser. Unlike some of today’s other stories, attacks have now been observed.

The vulnerability can allow someone on the internet to impersonate an administrator without knowing their password, and from there they may be able to take control of the server. No phishing email is required, and no employee needs to click anything. The vulnerable server itself is the target.

The fixed version is 3.2.1 or later. But if your organisation has been running a vulnerable version on the public internet, don’t just update it. Ask your IT team to check whether anyone may already have accessed it.

That distinction matters. An update can stop the next attacker, but it can’t undo what a previous attacker already did.

And finally, something particularly relevant to businesses building new websites and applications. Payload CMS is a modern system developers can use to build websites and web applications. A critical security issue has just been disclosed, and you don’t need to understand the technical details to understand the problem.

Imagine your office security pass correctly identifies you as, let’s say, Dustin. But because the pass was configured incorrectly, it also tells every locked door that you’re the CEO as well. The identity is correct, but the permission is wrong.

That’s essentially the security principle involved here. Under certain configurations, a normal user could potentially receive permissions they weren’t supposed to have. There’s currently no evidence that this is being actively exploited, and the issue has been fixed.

But this is a particularly useful lesson for organisations building software quickly with AI. AI can help us build functionality incredibly quickly. It can make the login work, it can make the database work, and it can make the application look finished.

But working is not the same thing as being secure. Someone still needs to ask, “What is this user actually allowed to do?”

And that’s really the theme running through today’s briefing. Security isn't just about updates; it’s about assumptions. We assume an update installed, we assume an administrator account belongs to an administrator, and we assume one business system can’t expose another.

We assume fixing a vulnerability removes the attacker. And we also assume that because someone logged in correctly, they only have access to what they’re supposed to have. That’s the difference between software that works and software that’s secure and production-ready.

So here’s the question I’d take back to your organisation today. When someone tells you a system is secure, what are they actually checking?