Critical WordPress vulnerability „wp2shell” (CVE-2026-63030). What you need to know and how to protect yourself

In July 2026, one of the most serious vulnerabilities in the WordPress core in recent years was disclosed — known as wp2shell (CVE-2026-63030 and CVE-2026-60137). It is already being actively exploited by attackers online, so if you run a WordPress site, it’s worth taking action now rather than „when you get round to it”.

This post explains in simple terms what the risk is and what specific steps to take. We have deliberately chosen not to publish any technical details of the attack here — We want to help administrators protect themselves, not make life easier for attackers.

In a nutshell

• This is a vulnerability in the WordPress core, rather than in one of the plugins — so this applies to „clean” installations.
• It allows you to remote code execution without logging in (The attacker does not need an account on the website.).
• It is actively used — ready-made attack tools have appeared.
• The solution is simple: update WordPress to the patched version. Everything else is a temporary measure.

Who is affected?

Sites running the following versions of WordPress are at risk:

• 6.9.0 – 6.9.4 and 7.0.0 – 7.0.1 — the full, most dangerous variant.
• 6.8.0 – 6.8.5 — a narrower scope of the problem.

The patches were released in the following versions 6.9.5, 7.0.2 and 6.8.6 (and later versions). If you have automatic core updates enabled, WordPress may already have updated itself — but It’s worth checking this out, because automatic updates are often disabled on many servers.

How to check if you’re safe

1. Log in to your WordPress dashboard and go to Dashboard → Updates.
2. Check the WordPress version number. If it is older lower than 6.8.6 / 6.9.5 / 7.0.2 — update immediately.
3. If you have a few or a few hundred pages, check them all — just one out-of-date installation is enough to cause a problem.

What to do — step by step

1. Update the WordPress core (most important). This is the only complete solution. Updating to version 6.8.6 / 6.9.5 / 7.0.2 (or later) patches the vulnerability. Make a backup before updating — this is standard best practice.
2. Check whether the website has already been hijacked. Since the vulnerability is being actively exploited, it is worth making sure that no one has beaten you to it. Typical signs of an attack include unexpected PHP files in directories where they would not normally be found (e.g. in the cache folder or the media library), and unknown, newly added administrator accounts. If you have any doubts, ask your WordPress service provider to carry out an audit.
3. If you can’t update straight away, apply a temporary block. Until the update is available, you can temporarily block the vulnerable part of the WordPress API. This is a stopgap measure that buys you some time — it is not a substitute for the update.
4. Whenever you suspect a break-in, make sure you tidy up thoroughly. Change the passwords for all administrators, regenerate the security keys (soles) in the configuration, review the list of user accounts and delete any you do not recognise.

For administrators (technical abbreviation)

The gap is on the side of the interface REST API WordPress and is accessible to unauthenticated requests. Recommended steps:

• Core update up to 6.8.6 / 6.9.5 / 7.0.2+ — absolute priority.
• Temporary mitigation In the run-up to the update: block the vulnerable endpoint at server level (rule in the server/WAF configuration) or at application level for unauthenticated requests. Please note that Apache/LiteSpeed server rules do not work on Nginx — ensure you have a server-independent layer in place.
• Detection: monitor unusual responses from API endpoints and check for the presence of PHP files in cache and media directories.
• Post-implementation hygiene: rotation of administrator passwords, salt regeneration, account review.

For your own safety, we do not provide any paths, parameters or sample requests here — this information is not required to protect yourself.

How we protect TREJKA’s customers

The websites we manage are supported in this regard on multiple levels:

• Kernel updates We prioritise implementation as soon as a security patch becomes available.
• Our plug-in TREJKA Admin Helper has a built-in lock, enabled by default a vulnerable endpoint for unauthenticated requests — it operates independently of the server (Apache, Nginx, LiteSpeed) and provides protection during the window between the disclosure of a vulnerability and the release of a patch. Logged-in editors will not notice any difference.
• Monitoring It detects typical signs of this type of attack (e.g. suspicious PHP files where they shouldn’t be), so we can spot any potential problems early on.

If your website isn’t yet managed by us, but you want to make sure it’s up to date and secure — get in touch with us, we’d be happy to help.

Sources and further reading:

• ithardware.pl — Critical WordPress vulnerability: a single HTTP request (link to the article)
• Rapid7 — analysis of CVE-2026-63030 (wp2shell)
• Wiz — information on the exploitation of a security vulnerability online (CVE-2026-63030 / CVE-2026-60137)

Publication date: July 2026. Information on versions and updates is correct as at the date of publication — always install the latest available version of WordPress.