# The wp2shell alert and how safe your site actually is > A critical WordPress flaw (wp2shell) put site owners on alert worldwide. What it means, what to do now, and why no site is truly immune. Source: https://cittago.com/blog/wp2shell-securitate-site-2026/ Publisher: Cittago — a digital studio in Cluj-Napoca, est. 2011 Published: 2026-07-22 Updated: 2026-08-26 Language: en --- 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. **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)](https://www.dnsc.ro/citeste/alert-vulnerabilit-i-critice-wp2shell-care-afecteaz-wordpress-core) 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. 01. **Confirm the version** — Dashboard → Updates. You want to see at least 6.9.5 or 7.0.2. 02. **Make a backup first** — Before you touch anything, a fresh, tested backup you actually know how to restore. If the update goes wrong, you have somewhere to fall back to. 03. **Update, then test** — Let the auto-update run or do it by hand, today. Then open the important pages and the forms and check that nothing broke. Sometimes the automatic update is blocked by a plugin or by server permissions — that's why you confirm. 04. **If you can't update right away** — A firewall rule or a security plugin that blocks anonymous access to the REST API's batch endpoint (the */wp-json/batch/v1* path) lowers the risk for now — but it can also block legitimate site features, so it's a bandage, not a fix. ## 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. *The more a site does and the easier it is to manage, the more “doors” it has — and so the more attack surface. wp2shell was exploited through exactly this kind of convenience door.* 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”](https://cittago.com/blog/wordpress-ai-connectors-2026/) 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”. *WordPress published the patch (6.9.5 / 7.0.2 / 6.8.6) and forced the automatic update back on July 17 — before the public alert and the first attacks appeared. This is what a mature response looks like.* ## 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](https://cittago.com/services/cloudflare/), 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. 01. **Software kept up to date** — The most boring layer is also the one that saved most sites in the wp2shell case. An updated site closes the known doors before anyone finds them. 02. **Hosting that fits** — Not the cheapest shared plan, but one with isolation, real resources and an application firewall. The server is the foundation — if it's fragile, the rest barely matters. 03. **Offsite backups, tested** — Not the backup you think you have, but the one you've restored at least once. A good backup turns a disaster into a bad afternoon. 04. **A person who watches** — Someone who applies the updates, follows alerts like this one and has a basic grasp of good practice. Technology doesn't manage itself. 05. **Least access and serious passwords** — Every account with exactly the rights it needs, unique passwords and two-step authentication on admin. Many break-ins don't even need a flaw — a weak password is enough. ## 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. *The whole update to 7.0.2, from download to “updated successfully” — a few seconds.* 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. *The result: WordPress 7.0.2 — a “maintenance and security” release. An ordinary screen, a decidedly un-ordinary stake.* 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. ### Is wp2shell still a live risk in late August 2026? For an updated site, no. We checked api.wordpress.org on 26 August 2026 and the current release is 7.1, several versions past every range named above. The risk that remains is entirely a risk of not having updated — which is the uncomfortable part, because the sites that were vulnerable in July are largely the same sites that are vulnerable to whatever gets announced next month. ### I updated late. How would I know whether I was already compromised? Updating closes the door; it does not evict anybody who came in first. The things worth checking are the ones an intruder has to leave behind: administrator accounts you did not create, scheduled tasks you did not schedule, PHP files with a modification date that does not match any deploy of yours, and outbound email volume. If any of those look wrong, restoring a backup from before the window beats cleaning by hand. ### Does a firewall or WAF make updating optional? No, and treating it that way is how a small problem becomes a long one. A WAF buys you time — sometimes days, sometimes an hour — between disclosure and your update. It works on patterns of attack traffic, so a request that does not look like an attack goes through. Use it to survive the gap, not to live inside it. ### My host says it patches automatically. Is that enough? It is a large part of it and it is not all of it. Managed hosts generally push core security releases quickly; plugins and themes are usually still yours. Ask two specific questions rather than one general one: does automatic patching cover plugins, and where can you see the log of what was applied and when. A host that cannot answer the second question has not really answered the first. ### Is core the main risk, or are plugins? Plugins, by a wide margin, simply because there are more of them and they are maintained unevenly. Core gets audited by a large number of people; a plugin with modest install numbers may be maintained by one person with a day job. The practical rule we apply on the sites we run: fewer plugins, each one chosen for having a maintainer who ships releases, and a monthly look at which ones have gone quiet. ## 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](https://cittago.com/services/cloudflare/), set up [hosting](https://cittago.com/services/hosting/) properly and make backups we actually test. And when a project truly needs a different technical foundation, we [build one](https://cittago.com/services/web-app-development/). 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. Last updated: 26 August 2026. Checked the same day against api.wordpress.org, which reports 7.1 as the current release; every version named in this article as vulnerable is therefore several releases behind. The vulnerability details and version ranges are unchanged from the original publication and were not re-derived on this pass. On this pass we took the FAQ from four questions to nine and replaced the HTML entities in the source with the characters themselves. Sources[DNSC alert — Romania's National Cyber Security Directorate](https://www.dnsc.ro/citeste/alert-vulnerabilit-i-critice-wp2shell-care-afecteaz-wordpress-core) · [Official WordPress advisory — CVE-2026-63030](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q) · [Official WordPress advisory — CVE-2026-60137](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf) · [Official WordPress 7.0.2 announcement](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/) ## Questions and answers **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. **Is wp2shell still a live risk in late August 2026?** For an updated site, no. We checked api.wordpress.org on 26 August 2026 and the current release is 7.1, several versions past every range named above. The risk that remains is entirely a risk of not having updated — which is the uncomfortable part, because the sites that were vulnerable in July are largely the same sites that are vulnerable to whatever gets announced next month. **I updated late. How would I know whether I was already compromised?** Updating closes the door; it does not evict anybody who came in first. The things worth checking are the ones an intruder has to leave behind: administrator accounts you did not create, scheduled tasks you did not schedule, PHP files with a modification date that does not match any deploy of yours, and outbound email volume. If any of those look wrong, restoring a backup from before the window beats cleaning by hand. **Does a firewall or WAF make updating optional?** No, and treating it that way is how a small problem becomes a long one. A WAF buys you time — sometimes days, sometimes an hour — between disclosure and your update. It works on patterns of attack traffic, so a request that does not look like an attack goes through. Use it to survive the gap, not to live inside it. **My host says it patches automatically. Is that enough?** It is a large part of it and it is not all of it. Managed hosts generally push core security releases quickly; plugins and themes are usually still yours. Ask two specific questions rather than one general one: does automatic patching cover plugins, and where can you see the log of what was applied and when. A host that cannot answer the second question has not really answered the first. **Is core the main risk, or are plugins?** Plugins, by a wide margin, simply because there are more of them and they are maintained unevenly. Core gets audited by a large number of people; a plugin with modest install numbers may be maintained by one person with a day job. The practical rule we apply on the sites we run: fewer plugins, each one chosen for having a maintainer who ships releases, and a monthly look at which ones have gone quiet. --- Cittago · https://cittago.com · digital marketing, SEO, AI search, Google Ads and web development for small and medium companies in Romania, Italy and the EU.