{"id":55204,"date":"2026-07-21T07:05:01","date_gmt":"2026-07-21T06:05:01","guid":{"rendered":"https:\/\/edoardoguzzi.com\/"},"modified":"2026-07-21T07:23:15","modified_gmt":"2026-07-21T06:23:15","slug":"wp2shell-wordpress-critical-vulnerability-cve-2026-63030","status":"publish","type":"post","link":"https:\/\/edoardoguzzi.com\/en\/wp2shell-wordpress-vulnerabilita-critica-cve-2026-63030\/","title":{"rendered":"wp2shell, the Critical WordPress Vulnerability: Affected Versions, Technical Impact, and What to Do Immediately"},"content":{"rendered":"<p class=\"wp-block-paragraph\">It is Friday, July 17, 2026. WordPress releases three security updates and, along with the new versions, enables forced automatic updates on the affected sites.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When a project like WordPress decides to push a patch like this, it's usually not just fixing the wrong color of a button.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The official announcement mentions&nbsp;<strong>a critical problem and a very serious one<\/strong>. WordPress recommends updating immediately and confirms that it has enabled forced updates precisely because of the severity of the issue.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">There are two vulnerabilities:&nbsp;<strong>CVE-2026-60137<\/strong>, an SQL injection in the core, and&nbsp;<strong>CVE-2026-63030<\/strong>, an issue with handling batch requests in the REST API. When combined in the most recent versions, they form the chain called&nbsp;<strong>wp2shell<\/strong>&nbsp;and can lead to remote code execution without authentication.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Translation: On a vulnerable installation, the attacker does not first have to guess a password, convince an administrator to click a link, or wait for a specific plugin to be installed. The problem lies in the WordPress core.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>This time, the update shouldn't be put on the to-do list for \u201cwhen I have a moment.\u201d.<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Which versions of WordPress are vulnerable to wp2shell?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The two vulnerabilities do not affect exactly the same versions. This distinction is important because WordPress 6.8 is vulnerable to SQL injection, but not to the full chain of attacks leading to RCE.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Installed Version<\/th><th>SQL injection<\/th><th>RCE wp2shell Chain<\/th><th>Corrected version<\/th><\/tr><\/thead><tbody><tr><td>6.8.0 \u2013 6.8.5<\/td><td>Yes<\/td><td>No<\/td><td>6.8.6<\/td><\/tr><tr><td>6.9.0 \u2013 6.9.4<\/td><td>Yes<\/td><td>Yes<\/td><td>6.9.5<\/td><\/tr><tr><td>7.0.0 \u2013 7.0.1<\/td><td>Yes<\/td><td>Yes<\/td><td>7.0.2<\/td><\/tr><tr><td>7.1 beta prior to beta2<\/td><td>Yes<\/td><td>Yes<\/td><td>7.1 beta2 or later<\/td><\/tr><tr><td>Prior to 6.8<\/td><td>No, for these CVEs<\/td><td>No<\/td><td>However, that's no reason to stick with an outdated release<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The official WordPress source classifies the REST API vulnerability as critical and confirms that, when combined with an SQL injection, it can lead to remote code execution. Cloudflare adds a useful clarification: the RCE affects installations starting with version 6.9 and later when persistent object caching is not enabled, a common configuration in many standard installations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Running WordPress 6.7 or an even older version does not mean your site is secure. It simply means you are not exposed to these two specific vulnerabilities. An outdated version may have other issues that have long been known and fixed.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">How the chain works, without turning this post into a manual for forwards<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The first vulnerability affects&nbsp;<code>WP_Query<\/code>, the class that WordPress uses to build and manage many database queries. A parameter is not handled securely enough and could allow the intended query to be altered. This is the SQL injection vulnerability.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The second vulnerability involves the REST API's batch endpoint. In short, WordPress can misinterpret the path and the validations applied to a request, allowing an anonymous user to access a path that should have remained protected.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">On its own, SQL injection has a more limited scope. When route confusion removes the barrier that kept it from affecting anonymous users, the two issues combine. This can lead to database read access, the compromise of an administrative account, and\u2014in versions affected by the full chain\u2014the execution of code within the web process context.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This does not automatically mean root access to the server. It does mean, however, that the website and everything the PHP process can read or modify must be considered at risk. On hosting environments with weak isolation, overly permissive permissions, or shared secrets, the damage can spread. It is not guaranteed, but it is technically plausible.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The technical damage doesn't end with the altered homepage<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Defacement\u2014that is, the visible replacement of a website\u2019s content\u2014is almost the milder version of the problem. It causes a stir and is quickly discovered. The most troublesome attacks try to stick around.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1. Database read or modified<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The database may contain users, password hashes, content, configurations, data collected by forms, WooCommerce orders, and information stored by plugins and integrations. The exact content varies from site to site, but the idea is simple: the database doesn't just contain blog posts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2. Compromised administrative accounts and sessions<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">An attacker may attempt to gain or create administrative access, change email addresses, modify roles, or keep a session active. Updating the core fixes the vulnerability, but does not remove a malicious administrator account created before the patch was applied.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3. Backdoors in files, plugins, or scheduled tasks<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Malicious code can be hidden in a seemingly harmless plugin, a theme, a PHP file in an unusual folder, or a scheduled event. It can also modify existing files to make its persistence less obvious. The site returns to normal after the update, but the backdoor remains open.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4. Redirects, Phishing, Malware, and SEO Spam<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A compromised website can display different pages to search engines, inject JavaScript, redirect only certain visitors, or host fraudulent content. This can disrupt indexing, trigger security warnings in browsers, damage the domain\u2019s reputation, and make the cleanup process much more time-consuming than applying a patch.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5. Tokens and Integrations Listed<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Many WordPress sites communicate with CRMs, email systems, payment gateways, automation services, and external APIs. This does not mean that wp2shell automatically compromises all of these systems. It means that credentials and tokens that can be read by the site may need to be revoked and regenerated if the installation is compromised.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The patch fixes the vulnerability. It doesn't turn back time.<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This is the point that tends to get lost in the typical \u201cupdate immediately\u201d message.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The update is mandatory because it prevents new attacks based on this chain. If the site remained exposed, however, it\u2019s also important to ask whether anyone gained access before the patch was applied. Exploitation activity was observed in the wild shortly after the disclosure, and as of July 19, VulnCheck had already verified more than two dozen public proof-of-concepts.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So: apply the patch first, then check right away.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What to Do Next, Step by Step<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Check which version is actually installed<\/strong>, without assuming that the automatic update was successful.<\/li>\n\n\n\n<li><strong>Create a snapshot or a verifiable backup<\/strong>\u00a0Before taking action. If there are already suspicious signs, be sure to preserve logs and evidence before cleaning up.<\/li>\n\n\n\n<li><strong>Update to the correct branch<\/strong>: 6.8.6, 6.9.5, 7.0.2, or a later version that includes the fixes.<\/li>\n\n\n\n<li><strong>Check to make sure the update has actually been applied<\/strong>\u00a0and verify the integrity of the core files.<\/li>\n\n\n\n<li><strong>Perform a post-update check<\/strong>\u00a0on login, forms, checkout, APIs, webhooks, automations, and custom functions.<\/li>\n\n\n\n<li><strong>Look for signs of compromise<\/strong>\u00a0from the exposure window until the time of the patch.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">From WP-CLI, basic commands can start with:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>wp core version\nwp core update --minor\nwp core version\nwp core verify-checksums<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The update command modifies the site. On the production environment, it should be run with a backup available and with an immediate verification of critical functions. In a security emergency, however, I would not use an endless testing cycle as an excuse to leave a vulnerable version online.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">What to Check After the Update<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Abnormal requests to\u00a0<code>\/wp-json\/batch\/v1<\/code>\u00a0e\u00a0<code>?rest_route=\/batch\/v1<\/code>\u00a0in the web server, CDN, and WAF logs.<\/li>\n\n\n\n<li>New administrator users, role changes, updated email addresses, and sessions you don't recognize.<\/li>\n\n\n\n<li>Recently installed plugins or themes that were not expected.<\/li>\n\n\n\n<li>Modified files, PHP in unusual directories, differences in core checksums, and obfuscated code.<\/li>\n\n\n\n<li>Unexpected WP-Cron events, changes to\u00a0<code>wp_options<\/code>, changed URLs, redirects, and altered configurations.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">If you notice anything suspicious, don\u2019t start deleting files at random. Isolate the site, preserve the evidence, reconstruct the sequence of events, and consider restoring it from a clean source. Then reset any passwords, sessions, keys, and tokens that the site might have accessed.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">An application firewall can reduce exposure. Cloudflare has also deployed dedicated rules on its free plan for traffic actually proxied by its WAF. Searchlight Cyber also recommends temporarily blocking anonymous access to batch endpoints as an emergency mitigation measure. But this is, in fact, a temporary measure: it can disrupt legitimate functions and is not a substitute for a patch.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions About wp2shell<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Does wp2shell exploit third-party plugins or themes?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">No. The chain affects the WordPress core and can impact a standard installation without plugins. However, any installed plugins may increase the number of potential paths an attacker can take once they gain access.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Am I vulnerable if I'm using WordPress 6.8.x?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Versions 6.8.0 through 6.8.5 are vulnerable to the CVE-2026-60137 SQL injection, but not to the full wp2shell RCE chain. The fix for this branch is WordPress 6.8.6.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does the forced automatic update protect me?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">It only provides protection if the update was successful. Filesystem permissions, configurations, management plugins, or deployment procedures may prevent or override the update. You should verify the actual version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is a WAF sufficient without updating it?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">No. The WAF is an additional layer of defense and a temporary mitigation measure. The permanent fix is to update the core to a secure version.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">If I've updated it, do I still need to check the website?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Yes, especially if the site remained online using a vulnerable version after the vulnerability was disclosed. The patch prevents new attacks exploiting the vulnerability, but it does not remove accounts, files, or backdoors created prior to the patch.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The business issue deserves a separate discussion<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Here, I've focused on how it works technically, potential damage, and the checks that need to be performed. On&nbsp;<a href=\"https:\/\/webwakeup.it\/vulnerabilita-wordpress-wp2shell-rischi-siti-aziendali\/\">At WebWakeUp, we\u2019ve tackled the other side of the issue<\/a>: business continuity, data, sales, reputation, and responsibilities among the company, the hosting provider, and the technical provider.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Sources<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/wordpress.org\/news\/2026\/07\/wordpress-7-0-2-release\/\" target=\"_blank\" rel=\"noreferrer noopener\">WordPress 7.0.2 Security Release<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/github.com\/WordPress\/wordpress-develop\/security\/advisories\/GHSA-fpp7-x2x2-2mjf\" target=\"_blank\" rel=\"noreferrer noopener\">GitHub Security Advisory for CVE-2026-60137<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/github.com\/WordPress\/wordpress-develop\/security\/advisories\/GHSA-ff9f-jf42-662q\" target=\"_blank\" rel=\"noreferrer noopener\">GitHub Security Advisory for CVE-2026-63030<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/cert-agid.gov.it\/news\/wp2shell-vulnerabilita-critiche-nel-core-di-wordpress-necessario-aggiornare-i-sistemi\/\" target=\"_blank\" rel=\"noreferrer noopener\">CERT-AGID, wp2shell: Critical Vulnerabilities in the WordPress Core<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/blog.cloudflare.com\/wordpress-vulnerabilities\/\" target=\"_blank\" rel=\"noreferrer noopener\">Cloudflare, WAF protections for WordPress vulnerabilities<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/www.vulncheck.com\/blog\/wp2shell\" target=\"_blank\" rel=\"noreferrer noopener\">VulnCheck: Analysis and Status of Proof-of-Concepts<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/www.securityweek.com\/wp2shell-wordpress-vulnerabilities-exploited-in-the-wild\/\" target=\"_blank\" rel=\"noreferrer noopener\">SecurityWeek, real-world activity observed<\/a><\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>\u00c8 venerd\u00ec 17 luglio 2026. WordPress pubblica tre aggiornamenti di sicurezza e, insieme alle nuove versioni, attiva gli aggiornamenti automatici forzati sui siti interessati. Quando un progetto come WordPress decide di spingere una patch in questo modo, di solito non sta correggendo il colore sbagliato di un pulsante. L&#8217;annuncio ufficiale parla di&nbsp;un problema critico e [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":55208,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"wds_primary_category":0,"footnotes":""},"categories":[64,444,402,381],"tags":[405,384,390,445,382,446],"class_list":["post-55204","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-sicurezza","category-web","category-wordpress","tag-danni-aziendali","tag-e-commerce","tag-self-hosting","tag-sicurezza","tag-wordpress","tag-wp2shell"],"meta_box":{"articolo_correlato_di_approfondimento":"","data_pubblicazione_sui_social":"0","pubblicato_sui_social":"","immagine_generata":"true"},"_links":{"self":[{"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/posts\/55204","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/comments?post=55204"}],"version-history":[{"count":3,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/posts\/55204\/revisions"}],"predecessor-version":[{"id":55209,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/posts\/55204\/revisions\/55209"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/media\/55208"}],"wp:attachment":[{"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/media?parent=55204"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/categories?post=55204"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/edoardoguzzi.com\/en\/wp-json\/wp\/v2\/tags?post=55204"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}