WordPress security
wp2shell needed a WordPress that answers. A static copy does not.
wp2shell was a chain of two flaws in WordPress itself, fixed on 17 July 2026 in WordPress 7.0.2 and 6.9.5. Anyone on the internet could use it to run code on an unpatched site — no account, no plugin needed — through an address every WordPress answers. A site whose visitors get a static copy never hands their requests to WordPress, so that address was not there to be used. The WordPress behind it needed the update all the same.
A copy that works like your site
An HTML export writes each page out with the files it names. What a page only loads once it is open — a picture that appears as you scroll, a menu that fills in, content a script fetches, a link that forwards to another address — is often missing, and you find out from a visitor.
A copy from MakeStatic works like your site, not only looks like it. You try it yourself, side by side with your site, before you decide anything — and if a page of the copy ever works differently from yours, write to [email protected] and we fix it.
- Pictures that load as you scroll, in every size your site has for phones and large screens.
- Fonts, icons and everything your theme or page builder brings along.
- Content a script loads once the page is open, and menus that fill in as you move over them.
- Links on your pages that forward to another address still forward.
- Videos that play and let you skip ahead.
- Contact forms that deliver, and a search box that answers.
What wp2shell was
Two vulnerabilities, CVE-2026-63030 and CVE-2026-60137, used together. The first lets a request slip through the batch interface of WordPress's REST API; the second turns it into a database query the attacker writes; together they end in code running on the server. The researcher who found it, Adam Kues of Assetnote / Searchlight Cyber, showed it working against a plain installation with no plugins, used by an anonymous visitor.
Together the two are rated 9.8 out of 10. Germany's Federal Office for Information Security (BSI) warned of active exploitation after the first attack code appeared within hours of the fix, and the US agency CISA listed both flaws as exploited on 21 July 2026.
Which versions, and what fixed them
- WordPress 6.9 up to 7.0.1: both flaws. Fixed in 7.0.2 and 6.9.5.
- WordPress 6.8: only the database flaw. Fixed in 6.8.6.
- Versions before 6.8 were not affected.
- WordPress pushed the fix as a forced automatic update. A site that does not update itself had to be updated by hand.
Why a static copy was out of reach
The attack is a request to WordPress itself — to /wp-json/batch/v1, or the same interface asked for through any address of the site. It works wherever WordPress answers what a visitor sends.
A static copy answers every visitor from files. Nothing a visitor sends is passed on to WordPress: the search is answered in the visitor's browser, a contact form is received by us, and an address the copy does not hold is simply not found. There was no WordPress behind the public address to send the attack to.
What it does not change
The WordPress you edit in is still a WordPress. It stays online at its own address, and until it was updated, wp2shell worked there as it did anywhere else. Update it as you would any WordPress.
What the copy changes is that your public site does not depend on it. Nothing from the editing installation reaches your visitors until you publish, and every publish lists the pages it changed — so a page that changed without you is one you see before your visitors do.
If your site ran an affected version
- Check the version: 6.8.6, 6.9.5, 7.0.2 and everything after them are fixed.
- Check the site for signs of a break-in even if it is updated now, as the BSI advises: a site can have been taken over before the fix arrived.
- If it was, clean it first. A copy shows what the site shows, including whatever was put into its pages.
Sources
The WordPress 7.0.2 release announcement on wordpress.org; the research note by Searchlight Cyber (wp2shell.com); the entries for CVE-2026-63030 and CVE-2026-60137 in the US National Vulnerability Database; the BSI's warning of 20 July 2026; Bitdefender's technical advisory. Checked on 28 September 2026.
Questions people ask
- Does wp2shell need a login?
- No. The researchers and the US National Vulnerability Database both describe it as needing no account of any kind. The sentence about authenticated users on wp2shell.com describes the stopgap plugin offered there, which switches the anonymous batch requests off.
- My site uses no plugins. Was it affected?
- Yes, if it ran WordPress 6.8 to 7.0.1 without the fix. The flaw was in WordPress itself, not in a plugin.
- Would a firewall or a security plugin have stopped it?
- Once a rule for it existed: after the flaw became known, security vendors published rules that block anonymous requests to the batch interface. A static copy did not need one, because it has no such interface to block.
- Is a static site safe from every attack?
- No. It has no WordPress for a visitor to reach, which takes attacks like this one off the table for your public site. The WordPress you edit in, your domain and your email accounts still need looking after.
See it on your own site
About twenty seconds, and nothing to sign up for. You will have your site and the copy open next to each other, and can try the copy yourself before you decide anything.