The wp2shell alert and how safe your site actually is
On July 19, national cyber-security agencies — Romania's DNSC among them — raised a clear alarm: a critical flaw in WordPress, nicknamed wp2shell, that lets an attacker take over a site with no password at all. It's serious news. But past the “update now”, it's also a good moment to talk about something few people will tell you plainly: no site is immune — and that's alright, if you know how it's handled.
Let's start with the urgent part, so you can breathe: if your site runs WordPress, check the version. If it's 6.9.5, 7.0.2 or newer, you're already covered against this attack — WordPress pushed the update automatically. If not, make a backup first, then update — and afterwards check that everything still works the way it should. The rest of this article is about what sits behind the alert.
wp2shell is a combination of two flaws in the WordPress core that, together, let an unauthenticated attacker run code on the server — in other words, take over the site. It affects versions 6.9.x and 7.0.x and is fixed in 6.9.5 and 7.0.2 (WordPress security releases, 2026). Real-world attacks are already happening, so update now. And beyond this one case: security isn't a product you buy once, it's a discipline sized to what's at stake for you.
wp2shell: two bugs that, together, open the door
Taken separately, the two vulnerabilities look manageable. Combined, they become what's called a pre-authentication RCE — in plain terms, someone on the internet can run code on your server without any password. The first flaw (CVE-2026-63030) fools the access rules of the REST API — the service door applications use to talk to each other — through a mistake in how the server reads incoming requests. The second (CVE-2026-60137) is a SQL injection.
To see why it matters: the database is the notebook where the site keeps absolutely everything — users, posts, passwords. Normally, the site asks it polite, pre-set questions. A SQL injection is when the attacker slips a hidden command inside something that looks like an ordinary request — a bit like whispering an extra order to the waiter alongside your restaurant order, and the kitchen carrying it out without blinking. Technically: it happens when what the user types isn't “cleaned” and ends up being read as a command rather than as plain text.
And there's a nuance that matters: on its own, neither is a catastrophe. The SQL injection alone would usually need a valid account. But the first flaw makes it reachable by anyone, with no password — and only put together do they give full control. That's why it's called a chain: each link looks small, but together they open the door.
CVE (Common Vulnerabilities and Exposures) is a kind of international license plate for security problems: every discovered vulnerability gets a unique code — like CVE-2026-63030 — so everyone in the world, from researchers to vendors and authorities, talks about exactly the same issue, no confusion. RCE (Remote Code Execution) is the most serious kind of flaw: the attacker runs their own commands on your server, from anywhere, as if their hands were on the keyboard. And pre-authentication means they do it with no account and no password.
Romania's National Cyber Security Directorate (DNSC) was among the agencies that raised a clear public alarm on this — and no wonder: more than 500 million sites run WordPress worldwide (DNSC, July 2026). Not all of them run exactly the vulnerable versions, but enough do for the alert to matter. Here's what's affected and what puts you in the clear:
| WordPress version | Status | What to do |
|---|---|---|
| 6.9.0 – 6.9.4 | Vulnerable | Update to 6.9.5 |
| 7.0.0 – 7.0.1 | Vulnerable | Update to 7.0.2 |
| 6.8.0 – 6.8.5 | SQL injection only | Update to 6.8.6 |
| 6.9.5 / 7.0.2 and newer | Safe | Nothing — you're covered |
Am I affected? How to check in ten seconds
Go into the admin panel, to Dashboard → Updates, and read the version. If it's 6.9.5, 7.0.2 or newer, you're fine — WordPress turned on forced automatic updates for the affected versions, precisely because of how serious this is. If you see an older version, don't wait for the normal maintenance cycle.
Story
The same Friday, two sites
Picture two bakeries, two streets apart. Almost identical sites, the same platform, built in the same month. On Friday, July 17, both were running exactly the WordPress version wp2shell goes through.
At the first, updates were on and someone — a person, not a plugin — glanced at it now and then. By Saturday morning, the patch had already landed on its own. Nobody felt a thing. A non-story.
At the second, a conflict between two plugins had quietly switched off automatic updates months earlier. Nobody had noticed, because everything “worked”. Until Monday, when customers started being redirected to a shady pill site, and Google wrapped the search result in a red warning.
The same code. The same day. The same flaw. The only difference was who was watching.
Why no site is truly immune
Here's the part few people tell you straight: there's no 100% secure site. Any system that does useful things — and especially one that hands you a friendly panel so you can manage your own content, without a developer — means more code, more features, more doors. Every extra door is a door that, in theory, can be forced. Specialists call it the attack surface. And the attack surface grows in step with convenience.
wp2shell is the perfect illustration. The flaw was exploited through the REST API — a feature meant to make WordPress more flexible and easier to integrate with other applications. It's not a defect born of carelessness, it's the price of complexity. Any platform powerful enough — WordPress, but its alternatives too — has, somewhere, a door like this that nobody has spotted yet.
A very current example: version 7.0 — the exact affected line — is the one that brings the “AI foundations” into WordPress: a new screen, Connectors, where you plug your preferred AI provider and other external services straight into the site. Powerful, useful features. And, at the same time, new surface. To be fair: it wasn't the AI foundations that caused the flaw — wp2shell hits some older components. But the direction is the same: the more a platform does, the more it has to defend. Today's convenience is tomorrow's surface.
And there's one more thing that matters, to put the alert in the right context: the response was mature. The flaw was reported responsibly, fixed quickly and pushed automatically to millions of sites within days. That's not the mark of a broken system, but of a healthy one, with serious people behind it. The difference between a secure site and a vulnerable one isn't “which technology you use”, it's “who's watching it and how fast they react”.
How much security do I actually need?
Exactly as much as the stakes demand. A five-page brochure site and an online store with thousands of customers and payments don't play in the same league and shouldn't be protected the same way. The idea is to match your measures to what you have to lose — neither over-protecting a brochure, nor leaving a whole business exposed.
If you have a simple brochure site, the essentials are honestly few: up-to-date software, decent hosting and a backup. If you run a serious e-commerce, the conversation changes completely. There, security is no longer optional: you need a server that's robust both technically and on the security side, a firewall out front, automated and tested backups, and someone technical who actually looks in periodically, not just when the alarm goes off. Customer data and money don't forgive improvisation.
Security “by design”: the layers that make the difference
The idea of security by design is simple: you think about safety from the start, as you build, instead of patching it after something happens. In practice, for an owner who isn't technical, it comes down to a few layers. None of them spectacular. All of them important.
The update takes under 30 seconds. The diligence takes longer.
The visible part of an update is surprisingly short. On a typical site, you press a button and in under 30 seconds WordPress handles everything itself: it downloads the package, unpacks it, drops into maintenance for a moment, copies the files, updates the database and exits. “WordPress updated successfully.” Exactly how long depends on your hosting and the size of the site — the point is that the technical part is unexpectedly fast.
It's just that the update itself is the easy part. The real work — the kind that makes the difference between “I pressed a button” and “I did it properly” — is around it: a full backup before, serious testing after (the important pages, the forms, the cart and checkout, everything that counts) and one more backup only after you've confirmed everything works. That takes time, attention and a bit of experience. The button is free; the diligence isn't.
And, to be fair all the way: neither a timely update, nor the backups, nor the testing guarantee that nothing will ever happen. Nothing in security is “100%”, and anyone who promises you that is reassuring you rather than protecting you. What these layers do together is something else, more honest and more valuable: they give you the best ratio between risk and peace of mind, and turn a possible incident from a disaster into a manageable annoyance.
Frequently asked questions
Am I affected by wp2shell if I have WordPress?
Only if you're running versions 6.9.0–6.9.4 or 7.0.0–7.0.1 (and for one of the flaws, 6.8.0–6.8.5 too). If you're on 6.9.5, 7.0.2 or newer, you're already covered. Check in Dashboard → Updates; if you're not sure, ask whoever manages your site.
I've updated. Am I safe now?
For this flaw, yes. Updating to 6.9.5 or 7.0.2 closes the wp2shell attack chain. But security doesn't end at an update — if the site sat vulnerable for a few days, it's worth confirming that no one had time to leave something behind.
Should I flee WordPress after this alert?
No. WordPress is a solid platform, used by hundreds of millions of sites, and it reacted exemplarily here. Every platform has a flaw at some point. What matters is that it's maintained properly. You migrate when the project calls for it — speed, structure, type of site — not out of fear.
How do I tell if my site has already been hacked?
Typical signs: files or users you didn't create, strange redirects, a sudden slowdown, warnings from Google or your hosting company. If you sat on a vulnerable version, a careful check is worth it even if everything looks fine — a well-hidden webshell doesn't announce itself.
Where Cittago comes in
We build and maintain sites — WordPress included — and that's exactly why we see alerts like this differently: not as drama, but as maintenance. We keep versions current, put a firewall and CDN out front, set up hosting properly and make backups we actually test. And when a project truly needs a different technical foundation, we build one. We pick the tool to fit the need, not the fashion.
A site isn't secure or insecure forever. It's secure as long as someone is watching it. The rest is just a matter of when, not if.
SourcesDNSC alert — Romania's National Cyber Security Directorate · Official WordPress advisory — CVE-2026-63030 · Official WordPress advisory — CVE-2026-60137 · Official WordPress 7.0.2 announcement
