# WP2Shell: Critical WordPress security vulnerability in version 7.0, what happened and what you should do now > URL: https://4eck-media.de/en/blog/wp2shell-critical-wordpress-security-vulnerability-in-version-7-0-what-happened-and-what-you-should-do-now/ > Language: en > Description: There are moments on the web when the difference between “we heard there is an update” and “we actually installed the update, verified it and checked the logs” decides reputation,… --- There are moments on the web when the difference between “we heard there is an update” and “we actually installed the update, verified it and checked the logs” decides reputation, revenue and trust. July 2026 was one such moment. WordPress powers the lion’s share of the open web. So when a vulnerability appears not in a peripheral plugin, but in the core of the system, and can be exploited without a login or special administrator access, this is not about alarmism. It is about craft: understanding, prioritising, closing and proving. ![WordPress logo with padlock, symbolising the WP2Shell security vulnerability and core hardening](https://4eck-media.de/wp-content/uploads/2026/08/4eck-security-wordpress.avif) *Critical WordPress security vulnerability, July 2026: WP2Shell (CVE-2026-60137 & CVE-2026-63030)* **The WordPress security vulnerability known as WP2Shell is an attack chain that can lead to malicious code execution without authentication on affected versions.** This is exactly our day-to-day work at 4eck Media. Since 2010, we have built and operated technically clean WordPress and WooCommerce systems, from multilingual corporate sites to demanding shop and multisite architectures. And because we operate TutKit.com ourselves, a platform with up to 20,000 users per day, we know security not from a brochure, but from operations. For comparable e-commerce requirements, our [WooCommerce agency](https://4eck-media.de/en/competencies/build-a-woocommerce-online-shop-with-a-specialized-woocommerce-agency/) develops robust processes instead of short-term plug-in solutions. ## WP2Shell at a glance: why the security update to WordPress 7.0.2 matters so much On 17 July 2026, the WordPress Security Team released WordPress 7.0.2, a security release that addresses *a critical* and *a high-severity* vulnerability. Backports for the affected branches were released in parallel: - 7.0.x → update to `7.0.2` - 6.9.x → update to `6.9.5` - 6.8.x → update to `6.8.6` (SQL injection) ![WP2Shell vulnerability in WordPress 7.0: security release 7.0.2 and immediate actions at a glance](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-wordpress-7-security-emergency.avif "WP2Shell and WordPress 7.0.2: security situation in July 2026") The public name for the attack chain is WP2Shell. It consists of two CVE entries that are significantly more dangerous together than individually: - CVE-2026-60137 (High): facilitated SQL injection. Crafted input can manipulate database queries. Affected from WordPress 6.8 onwards. Reported, among others, by TF1T, dtro and haongo. - CVE-2026-63030 (Critical): unauthenticated remote code execution through route confusion in the REST API batch endpoint. Affected from WordPress 6.9 onwards. Reported by Adam Kues (Assetnote / Searchlight Cyber). WordPress considered the situation serious enough to enable forced automatic updates for affected installations. This is not a routine notice; it is the seat belt during emergency braking. Even so, automatic update does not automatically mean “done”. Anyone hosting seriously *verifies*. WP2Shell: what you need to do now - Install at least WordPress 6.8.6, 6.9.5 or 7.0.2. - Verify the running version instead of merely trusting the automatic update. - Check administrators, plugins, core files, cron jobs and logs for anomalies. - Use a WAF only as a temporary protection layer until the patch is installed. - If you suspect compromise, rotate all passwords, keys and active sessions. It is important to understand from the outset: no human hacker comes to your website and thinks, “I’ll try an attack.” It happens automatically through bots that, like search-engine crawlers, scour the web and enter wherever possible. Then new administrators are created, passwords for existing administrators are changed, plugins or malware are installed, and spam pages, for example for casinos, are put online by the thousands. ## How the WP2Shell security vulnerability works technically Many security posts stop at “critical, please update”. That is too little when, as a decision-maker or IT manager, you need to assess whether your site, shop or multisite network is truly secure. So here is a look under the hood. ### CVE-2026-60137: SQL injection through WP_Query The first vulnerability concerns how WordPress processes input in certain query parameters, particularly around `author__not_in` and related `WP_Query` paths. An attacker can shape crafted input so that the generated SQL query no longer merely “asks”, but is manipulated. SQL injection in the CMS core is troublesome for two reasons: first, it sits deep in request handling and is therefore broadly reachable. Second, it is often the *key* to further steps, such as data extraction, session manipulation or, as here, preparing for code execution. ### CVE-2026-63030: REST API batch route confusion leads to RCE The second vulnerability affects the REST API batch endpoint (`/wp-json/batch/v1` or the corresponding batch mechanism). Route confusion causes the method, validation and authorisation check to fall out of sync: a request can be “disguised” in a way that bypasses checks and internally accesses paths that should never have been reachable anonymously. Crucially, in the described form, no authentication is required for the critical remote code execution. No stolen administrator password. No phishing. No compromised editor account. A short, cleverly constructed sequence of unauthenticated HTTP requests can lead to malicious code execution on vulnerable systems without appropriate countermeasures, depending among other things on the object-cache setup. This very combination of SQL injection plus batch route confusion makes WP2Shell more than “just an SQLi”. It is an attack chain that can work on a standard installation: core, without exotic plugins and without prior access. ![Attack chain of the WP2Shell vulnerability, from an anonymous REST batch request through SQL injection to remote code execution](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-attack-chain-code-execution.avif "How the WP2Shell attack chain works") ## WP2Shell attack chain: how two vulnerabilities can take over WordPress In practice, security researchers typically see two exploit patterns: 1. Initial access: the attack chain combines REST batch route confusion with SQL injection in a short sequence of unauthenticated requests. It is not a single “magic request”. 2. Takeover and persistence: the publicly described chain can abuse temporary administrative permissions, create a new administrator and then upload a backdoor plugin. Web shells, manipulated cron jobs or further persistence mechanisms are then possible. After the public disclosure and the appearance of proofs of concept, the likelihood of exploitation rose noticeably. Universities, hosting providers and security companies expressly warned that widespread exploitation was likely because of the low attack complexity. Important for decision-makers: a WAF (web application firewall) can reduce attack pressure. Cloudflare and others have rolled out rules. **A WAF does not replace a WordPress security update.** Anyone relying only on edge protection while leaving the core exposed is gambling with their own domain. ## Affected WordPress versions: who needs to update to 7.0.2, 6.9.5 or 6.8.6 Not every WordPress version is affected in the same way. The SQL injection starts with 6.8, while the full RCE chain starts with 6.9. For the 7.0 branch, which includes many newly relaunched projects, this means: | Branch | SQL injection (CVE-2026-60137) | RCE chain (CVE-2026-63030) | Fix | | --- | --- | --- | --- | | 6.8.0 – 6.8.5 | Affected | No | 6.8.6 | | 6.9.0 – 6.9.4 | Affected | Affected | 6.9.5 | | 7.0.0 – 7.0.1 | Affected | Affected | 7.0.2 | | < 6.8 | Not affected by this chain* | Still keep current | | **WordPress 7.0.0 and 7.0.1 must be updated to at least WordPress 7.0.2.** ![Affected WordPress versions and secure updates against the WP2Shell security vulnerability](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-affected-wordpress-versions.avif "WP2Shell version matrix: WordPress 6.8.6, 6.9.5 and 7.0.2") *Older versions are not affected by *this* chain, but that does not make them “secure”. Outdated cores, plugins and PHP stacks are a risk universe of their own. Our [WordPress agency](https://4eck-media.de/en/competencies/wordpress-agency-websites-that-work-for-your-business/) implements comparable requirements as scalable, secure and editorially easy-to-maintain solutions. ## Why no 4eck Media client was affected: WordPress maintenance instead of luck Let us be clear: luck is not a strategy. The fact that none of our managed client projects was compromised by WP2Shell is due to a system, not chance. This system works as follows in practice: - Active core and plugin maintenance: security releases are prioritised, tested and installed, not “sometime in the next sprint”. - Verification instead of assumption: we check the actual WordPress version in the dashboard, in `wp-includes/version.php` and through monitoring. An automatic update alone is not sufficient proof for us. - Technical hardening: security headers, restrictive file permissions, clean separation of staging and production, targeted protection of sensitive endpoints, logging and, where appropriate, WAF/CDN layers. - Operational experience from our own platform: what we recommend to clients, we operate ourselves with TutKit.com, PSD-Tutorials and dozens of agency projects since 2002/2010. For us, security is not a one-off audit PDF that ends up in a drawer. It is part of design, development, the go-live checklist and ongoing support. That is exactly why we can say today: our clients were not affected by this incident. ## Run WordPress securely These articles show how up-to-date software, systematic security checks, robust backups and clean configuration measurably reduce the risk posed by WordPress vulnerabilities and outages. [![Cover image of the website launch checklist with clipboard, football and check points after go-live](https://4eck-media.de/wp-content/uploads/2026/07/website-launch-checkliste-nach-go-live-cover.avif "Website launch checklist: important steps after go-live")](https://4eck-media.de/en/blog/website-launch-checklist-what-separates-quality-from-botched-work-after-go-live/ "Website launch checklist: what separates quality from botched work after go-live") [Website launch checklist: what separates quality from botched work after go-live](https://4eck-media.de/en/blog/website-launch-checklist-what-separates-quality-from-botched-work-after-go-live/) Matthias Petri [![Laptop showing a website check for performance, SEO, security and accessibility, with the logos of the ten testing tools](https://4eck-media.de/wp-content/uploads/2026/07/website-pruefen-die-10-tools-mit-denen-wir-jede-website-testen-vor-und-nach-dem-go-live.avif "Checking a website: 10 tools before and after go-live")](https://4eck-media.de/en/blog/checking-a-website-the-10-tools-we-use-to-test-every-website-before-and-after-go-live/ "Checking a website: the 10 tools we use to test every website, before and after go-live") [Checking a website: the 10 tools we use to test every website, before and after go-live](https://4eck-media.de/en/blog/checking-a-website-the-10-tools-we-use-to-test-every-website-before-and-after-go-live/) Matthias Petri [![Cover image for the website checklist before go-live with the check areas technology, content, mobile, performance and quality](https://4eck-media.de/wp-content/uploads/2026/07/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif "Website checklist before go-live: quality instead of botch-work")](https://4eck-media.de/en/blog/website-checklist-before-go-live-what-we-check-before-a-website-is-allowed-to-go-online/ "Website checklist before go-live: what we check before a website is allowed to go online") [Website checklist before go-live: what we check before a website is allowed to go online](https://4eck-media.de/en/blog/website-checklist-before-go-live-what-we-check-before-a-website-is-allowed-to-go-online/) Matthias Petri [![JavaScript-SEO: Challenges for Web Developers and SEO Managers](https://4eck-media.de/wp-content/uploads/2025/10/javascript-seo-herausforderungen-720x480.avif "JavaScript-SEO: Challenges for Web Developers and SEO Managers")](https://4eck-media.de/en/blog/javascript-seo-challenges-for-web-developers-and-seo-managers/ "JavaScript-SEO: Challenges for Web Developers and SEO Managers") [JavaScript-SEO: Challenges for Web Developers and SEO Managers](https://4eck-media.de/en/blog/javascript-seo-challenges-for-web-developers-and-seo-managers/) Matthias Petri ## Close the WordPress security vulnerability: these six steps are required now Whether you host yourself, have a freelancer or work with an agency, the following sequence is the one that works in incident response and clean maintenance. ### Step 1: reliably check the WordPress version Log in to the WordPress backend and check the version under *Dashboard → Updates* or at the bottom of the admin footer. Additionally: - File `wp-includes/version.php`, field `$wp_version` - Hosting panel / WP-CLI: `wp core version` - Use external checkers only as an indication, never as the sole source of truth Target versions: 7.0.2+, 6.9.5+ or 6.8.6+, depending on the branch. Anything below that remains exposed. ### Step 2: install the WordPress security update in a controlled manner Ideally: staging → smoke test (login, checkout, forms, critical custom flows) → production → check the version again. If staging is unavailable and the vulnerability is critical, patch production and test intensively afterwards. For security-critical issues, “we will wait for the next content sprint” is the more expensive option. ### Step 3: temporary protective measures until the patch - Block the batch REST endpoint at the reverse proxy / WAF (`/wp-json/batch` and variants) - Restrict anonymous REST API access where the business permits it - Keep managed CDN/WAF rules active - After the patch, relax mitigations again sufficiently so that legitimate integrations, such as headless systems, mobile apps and automations, do not break ### Step 4: check WordPress for compromise A successful patch does not automatically heal a compromise that has already occurred. Check: - Unknown administrator accounts and changed roles - New or unknown plugins, must-use plugins and drop-ins - Modified core files (integrity check / fresh core files) - Suspicious cron jobs, redirects, `.htaccess`, PHP files in upload directories - Access logs around the disclosure period (batch API, unusual POST load) ![Six steps after WP2Shell: check the WordPress version, patch, analyse, isolate, restore and monitor](https://4eck-media.de/wp-content/uploads/2026/08/wp2shell-incident-response-checklist.avif "WP2Shell incident-response checklist") Where there are concrete indicators of compromise: isolate the system, preserve forensic evidence, and rebuild cleanly from a trusted backup plus patching and password rotation, not “delete something and hope”. ### Step 5: rotate passwords, keys and sessions Administrator and editor passwords, application passwords, FTP/SFTP, hosting, database, CI/CD secrets, SMTP, payment and API keys. Invalidate sessions. Enforce 2FA where possible. ### Step 6: establish monitoring and WordPress maintenance for the long term The best time for a maintenance agreement was before the incident. The second-best time is now. Uptime checks alone are not a security programme. You need an update policy, a backup strategy with restore tests, logging, alerting and someone who knows what to do at 9:12 after an emergency release. ## Harden WordPress: keeping the next security incident manageable WP2Shell is a core event. The next critical vulnerability may be in a plugin, the theme, the server stack or a misconfigured staging copy that is publicly indexable. That is why we work at 4eck Media with a minimum hardening standard: - Least privilege: as few administrator accounts as possible, separate roles and no shared passwords. - Plugin hygiene: only what is needed, actively maintained and regularly audited. Every dormant plugin is attack surface. - Security headers and transport: HSTS, CSP where feasible, secure cookie flags, TLS only. - Backups that can be restored: versioned, offsite and restore-tested, not merely “somewhere in the hosting panel”. - Staging is not production on the internet: authentication, robots, separate credentials, no copy with real customer data left unprotected. - Think about performance and security together: PageSpeed and Core Web Vitals do not conflict with hardening; bloated plugin graveyards harm both. ![WordPress security concept with hardening, two-factor authentication, WAF, backups and central monitoring](https://4eck-media.de/wp-content/uploads/2026/08/wordpress-security-baseline-hardening.avif "Hardening WordPress permanently against critical security vulnerabilities") ## Suspect WP2Shell? Have WordPress checked, cleaned and secured Not every company has an internal security team. Not every “WordPress maintenance” provider truly checks the version after an emergency release. If you are unsure whether your installation was on 7.0.0 / 7.0.1, or another vulnerable version, if automatic updates are disabled for you, if logs look strange or the backend feels “somehow different”, now is the time for professional help, not hope. 4eck Media supports companies in exactly these situations: - Immediate check: version, patch status and obvious indicators of compromise - Controlled installation of security releases, including smoke tests - Initial forensic assessment and clean recovery in the event of an incident - Hardening, WAF/CDN alignment, backup and update processes - Ongoing maintenance for WordPress, WooCommerce, multisite and multilingual setups We are the tech agency from Waren (Müritz) for professional WordPress development, WooCommerce, PageSpeed, accessibility, SEO and GEO. More than 350 client projects since 2010. For us, security is held to the same standard as performance: measurable, traceable and operated, not merely claimed. Our own clients were not affected by WP2Shell. If you were, or need proof that you were not, contact us. We close the vulnerability, clean up and build operations so that the next Security Friday does not become an emergency for you. *Sources and notice: this article is based, among other things, on the official WordPress 7.0.2 security release (17 July 2026), advisories on CVE-2026-60137 and CVE-2026-63030 (WP2Shell), analyses by Searchlight Cyber / Assetnote, Cloudflare, Rapid7, as well as university and hosting security alerts. This article does not replace an individual forensic analysis. In a concrete incident: isolate the system and consult specialists.* ## Frequently asked questions about the WP2Shell security vulnerability What is WP2Shell? WP2Shell is the name of a critical attack chain in the WordPress core. It combines CVE-2026-60137 (SQL injection) and CVE-2026-63030 (REST API batch route confusion), allowing malicious code to be executed without prior authentication on vulnerable installations. Which WordPress versions are affected by WP2Shell? The full chain affects WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1. WordPress 6.8.0 to 6.8.5 is affected by the SQL injection but not by the full RCE chain. WordPress 7.1 Beta 1 was also affected. Which WordPress updates close the security vulnerability? Depending on the branch, install at least WordPress 6.8.6, 6.9.5 or 7.0.2. The 7.1 test branch requires Beta 2 or later. Then actively check in the backend and through WP-CLI whether the target version is actually running. Can WP2Shell be exploited without a login or an insecure plugin? Yes. WP2Shell affects the WordPress core and requires neither a specific plugin nor a previously stolen account. This means that even seemingly lean standard installations may be vulnerable. Is an automatic WordPress update sufficient? No. Automatic updates can fail or be absent on individual instances. Verify the version in the dashboard and with wp core version. In addition, a current patch does not prove that the website was not already compromised before the update. Does a web application firewall provide complete protection against WP2Shell? No. A WAF can temporarily block known attack patterns and reduce attack pressure, but it replaces neither the WordPress security update nor the subsequent check for compromise. How can I recognise a possible WordPress compromise? Check for unknown administrators, new plugins and MU plugins, modified core files, PHP files in upload directories, suspicious cron jobs, redirects, REST and wp-login activity, and conspicuous outbound connections. What should I do if my WordPress website has been compromised? Isolate the system, preserve logs and evidence, and restore the website from a trusted backup or through a clean rebuild. Install the security updates, rotate passwords, keys and sessions, and closely monitor the cleaned instance.