Your website still works fine. That says nothing about how secure it is.

Most SMEs have a website that simply sits there. Built by an agency at some point, quietly doing its job ever since, and nobody looks at it anymore. Usually that's no problem. Since mid-July, briefly, it is.

What's going on

On 17 July 2026, WordPress released three emergency versions: 7.0.2, 6.9.5 and 6.8.6. The reason: two flaws in the software that researchers jointly nicknamed "wp2shell" (officially CVE-2026-63030 and CVE-2026-60137). A flaw like that, which an attacker can abuse, is called a vulnerability.

The sting is in the location. These two flaws are not in a plugin — an extra module installed on top of WordPress, for a contact form for instance — but in WordPress itself. A bare installation without a single plugin is therefore just as exposed as a site full of extras.

What an attacker can do with it: send one request to the website. No account needed, nobody has to click anything. From that moment on, foreign code is running on the server behind that site. In practice that means: altering text, redirecting visitors to fake pages, reading out the database, quietly creating an extra administrator account, or leaving a back door open for later.

Theoretical? No. On 21 July, the US cyber security agency CISA added both vulnerabilities to its list of flaws with confirmed exploitation. The Centre for Cybersecurity Belgium (CCB), the national government service for cyber security, called for updating with the highest priority. Ready-made attack code is circulating publicly in the meantime.

A quick note on the versions. WordPress 6.9.0 up to and including 6.9.4 and 7.0.0 up to and including 7.0.1 are vulnerable to the full attack. 6.8.0 up to and including 6.8.5 only to the smaller of the two flaws. Anything older than 6.8 escapes these two particular flaws — but anyone still running that is missing years of other updates. No cause for celebration, then.

Why this affects SMEs

WordPress runs on roughly 41.5% of all websites worldwide (W3Techs, July 2026). Chances are high that a Flemish SME's site runs on it too. And attackers don't pick their victims: they release a script onto the entire internet and take whatever turns out to be vulnerable. Being small doesn't help. Nobody checks the size first.

WordPress pushed the update out through the automatic update system. Good — but that mechanism doesn't reach every site. It skips sites where automatic updates are switched off, sites with strict file permissions, sites managed through a development environment, and sites with very few visitors. In other words: exactly the sites nobody in IT looks at daily.

And there's more. Most businesses have more online than they think. The main site, yes. But also that campaign site from three years ago. The webshop on a subdomain. The test environment the agency forgot to take offline back then. All running the same software. And nobody feels responsible for it.

That this genuinely hits small businesses became clear in June: an international police operation dismantled a network that used hacked WordPress sites to spread malware. In the Netherlands alone, nearly 15,000 infected sites were cleaned up. Among the victims: restaurants, garages and other businesses without an IT department of their own.

And a hijacked website is rarely "just the website". Visitors landing on a fraudulent page. A Google warning next to the company name in the search results. Contact details from forms out in the open — that last one is a data breach under the GDPR, notification duty included.

What to actually do about it

Check today which version is running. In the WordPress dashboard it's on the home page under "At a Glance", or via Dashboard → Updates. It should read 7.0.2, 6.9.5, 6.8.6 or higher. Don't assume the automatic update went through. That check takes thirty seconds.

Do that for every site, not just the main one. Write down everything that is online: main site, webshop, campaign sites, subdomains, test environments. Whatever isn't on that list doesn't get updated either.

Ask the web builder or hosting partner for confirmation in writing. Not only that the update is installed, but also that someone has looked for traces of a break-in. Have them check for unknown administrator accounts, plugins nobody installed, and files that don't belong there.

An update closes the door. It doesn't remove anyone who was already inside.

Updating right away really isn't possible? Then a firewall in front of the website can temporarily shield the vulnerable component. That's a stopgap for a few days, not a replacement for the update.

Then lock it down structurally. One name per website. An agreement on how quickly critical updates get installed. And two-factor authentication on every administrator account: alongside a password, a code on the phone. Get this right once and there's no need to improvise at the next flaw.

How NetGuard helps

The hardest part of a flaw like this is rarely the update itself. It's the question that comes before it: where is there actually still something of this business online? That's what External Attack Surface Management (EASM) is for — mapping which websites, subdomains, login pages and servers of an organisation are reachable from the internet, forgotten ones included. That way it's clear what needs checking, instead of hoping nothing gets overlooked. Anyone who then wants to know whether a vulnerability is genuinely exploitable in their own environment ends up at a pentest: a controlled attack by specialists.

Curious what is visible of your business from the internet today? Get in touch with NetGuard for a first analysis.

More information

• CCB — Warning: Critical, Actively Exploited Remote Code Execution in WordPress Core (CVE-2026-63030, CVE-2026-60137)

• Rapid7 — CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core

• SecurityWeek — WP2Shell WordPress Vulnerabilities Exploited in the Wild