{"id":43263,"date":"2026-07-23T17:10:20","date_gmt":"2026-07-23T15:10:20","guid":{"rendered":"https:\/\/csw.agency\/?p=43263"},"modified":"2026-07-23T18:21:31","modified_gmt":"2026-07-23T16:21:31","slug":"wp2shell-wordpress","status":"publish","type":"post","link":"https:\/\/csw.agency\/en\/wp2shell-wordpress\/","title":{"rendered":"wp2shell forces WordPress websites to update"},"content":{"rendered":"

WordPress is one of the most widely used content management systems worldwide, and consequently, the attack surface is large when a critical vulnerability appears in the core of the system. This is exactly what happened with wp2shell, a combination of two vulnerabilities that together create a unauthorized code execution<\/strong> enable. Security researchers are already confirming active attacks on the internet, so time is of the essence.<\/p>\n

What's behind wp2shell<\/h2>\n

wp2shell refers to the combination of two vulnerabilities in the WordPress core that are much more dangerous together than each one is on its own. CVE-2026-63030 is in the REST API<\/strong> and causes confusion between different batch routes, allowing multiple requests to be evaluated differently in a single call than actually intended by the system, The Hacker News<\/a> describes the mechanism in detail in its own analysis. CVE-2026-60137 is a SQL Injection<\/strong> in the parameter author__not_in of the WP_Query class, which is used in the background with the MySQL<\/a>-database communicates and is supposed to actually filter out only authors there. Combined, both loopholes allow an anonymous attacker Remote Code Execution<\/em>, So, executing your own code on a foreign server, regardless of whether additional security plugins are installed.<\/p>\n

Installations from versions 6.8.0 to 6.8.5 are affected by the SQL injection alone, and versions 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1 are affected by the complete, much more dangerous chain of both vulnerabilities. Those running versions older than 6.8 are not affected, which, given outdated installations and their own risks, is rarely of any real comfort. The two vulnerabilities were discovered and reported independently: the REST API vulnerability by Assetnote and Searchlight Cyber, and the SQL injection by the research team TF1T, dtro, and haongo. The WordPress core team responded with a Emergency Update<\/strong> for all three affected version branches. The details about the official patch have WordPress<\/a> published in a separate post, including a technical description of both vulnerabilities.<\/p>\n

Why the attack is so dangerous<\/h2>\n

The combination of both loopholes works without registration and without a single installed Plugin<\/a>, A standard WordPress is already enough of a target. This is precisely what distinguishes wp2shell from most security vulnerabilities of recent years, which usually found their way into the system via vulnerable extensions or themes and could therefore be more easily contained. ExpertInsights<\/a> calls the vulnerability the first critical, unauthenticated remote code execution in the WordPress core in nearly a decade. Those who underestimate the scope risk full compromise of their server, including the database, customer data, and in the worst case, also linked systems such as newsletter tools or payment providers.<\/p>\n

As early as July 17, 2026, the security service provider Wordfence registered the first test requests to the REST API, followed by the first real injection attempt a few minutes later. Shortly thereafter, a public repository appeared on GitHub Proof of Concept<\/em> which made the complete attack chain understandable step by step, thereby also making it easier for less experienced attackers to get started. The Federal Office for Information Security subsequently classified the situation as Alert Level Orange<\/strong> one, how heise<\/a> in its ongoing reporting. Also SecurityWeek<\/a> confirmed active attacks on the web and classified the campaign as one of the more serious WordPress incidents of the current year.<\/p>\n

\"\"<\/p>\n

What operators must do now<\/h2>\n

The most important step is simple, even though it's often postponed in daily business. Check which WordPress version your site is currently running on and update immediately to 6.8.6, 6.9.5, or 7.0.2, depending on which version branch you are using. Because the severity of the vulnerability allows no waiting time, the core team has enforced automatic background updates for affected versions, so many sites are already running on a patched version, provided the host has not disabled this function for their own reasons. Nevertheless, check the version number yourself in the backend, because especially with managed hosting packages and specially configured servers, their own update rules sometimes apply.<\/p>\n