Click2Shell, Comment2Shell, and wp2shell: what is actually hitting WordPress sites right now

If you run WordPress sites and only read one section, read this one. On 17 September 2026 WordPress shipped 7.1.1 with eleven security fixes. Two of them have been given catchy names: Click2Shell, found by Paulos Yibelo at pwn.ai, and Comment2Shell, found by Rafie Muhammad. Both are serious. Neither has been seen in a real attack at the time of writing, and both need a site administrator to do something — click a link, or simply look at a page — while logged in.

The name you should actually be worried about is the older one. wp2shell (CVE-2026-63030 and CVE-2026-60137) was published on 17 July 2026 and is a fully unauthenticated route to code execution on a stock WordPress install. Exploitation started within hours, CISA added it to the Known Exploited Vulnerabilities list four days later, and it is still being sprayed across the internet. When a site comes to us this month with a webshell and an administrator nobody created, the timeline almost always leads back to a July install that was not updated in time.

The practical consequence: the new flaws are a reason to update today. The old flaw is a reason to check whether you were already hit.

Click2Shell is a good name because it describes the whole attack. The attacker does not need a WordPress account, a nonce, or a password. They need an administrator, already logged in, to open one URL. Phishing delivers that; so does any existing cross-site scripting bug on the site. Everything after the click happens in the administrator’s browser and on the server, without any further interaction.

The bug itself is small. The theme installer page in wp-admin takes a theme slug from the URL and drops it, unescaped, into a jQuery selector so that it can highlight the matching theme card. A slug ending in a few carefully chosen characters turns that selector into one that matches the card’s Install button instead — and the page then clicks it on the administrator’s behalf. The WordPress.org API, which interprets the same value more forgivingly, still returns a real theme from the catalog. The result is a silent installation of an attacker-chosen theme, with the administrator’s session supplying every permission and token the request needs.

That alone is a nuisance, not a compromise. It becomes one because WordPress loads a theme’s PHP when building a Customizer preview even if that theme is not active. A second crafted link opens the Customizer with the freshly installed theme, its functions.php runs, and whatever that theme registers is now live. The pwn.ai researchers found more than forty themes on WordPress.org whose pre-activation code was unsafe, and demonstrated the chain with Mobile Repair Zone 2.5.4, whose AJAX handler accepted a plugin download URL with no nonce and no capability check at all. WordPress fetched the attacker’s ZIP, unpacked it as a plugin, and executed it.

1. 01

   The lure

   An administrator, logged into wp-admin, opens a link. The link points at theme-install.php on their own site with a theme parameter that ends in selector-breaking characters, for example twentytwenty"]>*>*>*/* once URL-decoded.

2. 02

   The forced install

   The installer page builds a selector from that slug without escaping it. The malformed selector matches the Install button of the theme card, the page fires a click, and WordPress installs an attacker-chosen theme from the official catalog. Nothing is shown to the administrator beyond a theme they did not ask for.

3. 03

   The preview

   A follow-up link opens the Customizer with customize_theme set to the new theme’s slug. WordPress loads that theme’s PHP to render the preview even though a different theme is active on the site, so the theme’s functions.php executes.

4. 04

   The insecure handler

   In the demonstrated case the theme registers an admin-ajax action that installs and activates a plugin from any URL it is given, with no nonce and no capability check. The request that reaches it needs nothing from the attacker beyond the administrator’s existing session.

5. 05

   The shell

   WordPress downloads the attacker’s ZIP, unpacks it into wp-content/plugins, and runs it. From this point the attacker has arbitrary PHP: new administrators, reading wp-config.php, modifying files, and everything else that follows from code execution as the web server user.

Click2Shell has taken the headlines, but 7.1.1 fixes eleven security issues. One of the others has its own name and deserves its own paragraph. Comment2Shell (CVE-2026-93485, rated 7.1 by Patchstack) is a stored cross-site scripting bug in wpautop(), the function that turns line breaks into paragraphs when a comment is displayed. A comment that passes WordPress’s sanitisation on the way in can be broken apart on the way out: a line break placed inside the attribute of an allowed HTML tag ends up moving attacker text into a position where it runs as an event handler. Nobody has to click anything. If a logged-in administrator so much as views the page, the script runs with their session and can upload a plugin, which is to say a webshell.

Two things limit it. The comment has to be rendered, so a site with moderation on and a moderator who reads before approving is protected by that habit — but comment moderation is a default that many sites relax, and the researcher notes it can be bypassed in practice. And the affected rendering path applies to block themes from Twenty Twenty-Two onward, so classic-theme sites are less exposed. It has not been seen in the wild.

The remaining fixes matter less individually but are worth knowing about, because several of them are the kind of authenticated flaw that turns a Contributor or Author account — cheap to obtain on any site with open registration — into something worse.

wp2shell is the reason this advisory exists. It is a chain of two Core bugs, disclosed by Searchlight Cyber on 17 July 2026 and fixed the same day in WordPress 7.0.2, 6.9.5, and 6.8.6. CVE-2026-63030 is a route-confusion flaw in the REST API batch endpoint that lets an anonymous request reach routes that should require authentication. CVE-2026-60137 is a SQL injection in the author__not_in argument of WP_Query, reachable through the posts endpoint’s author_exclude parameter. Chained, they give an attacker who has never logged in full read and write access to the database — and from there a new administrator, a plugin upload, and arbitrary PHP. Every default install running 6.9.0 through 7.0.1 was vulnerable to the full chain; 6.8.x was vulnerable to the injection alone.

Exploitation began the evening of the disclosure. Patchstack was reporting attacks by 7 PM Eastern on 17 July, VulnCheck had counted more than two dozen distinct public exploits by 19 July, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on 21 July. CrowdSec’s network then watched 62,802 distinct IP addresses send matching requests between 20 July and 22 August, peaking at over 158,000 signals in a single day, with the number of distinct daily sources still climbing when the observation window closed. Wiz measured that 60 percent of organisations using WordPress had at least one vulnerable instance on the day of disclosure and a quarter had one exposed to the internet.

This is not only mass scanning. GreyNoise tracked a single actor through at least 49 compromised organisations in 29 countries — mostly small businesses and government bodies — including a Western government agency from which more than 18,500 records containing plaintext passwords and personal data were pulled out of the backend database on 22 July. The post-compromise pattern was consistent: install a webshell, dump the administrator table, create a disguised user, read wp-config.php and any other credentials on disk, then use those to reach the database directly and try the same passwords elsewhere on the host.

1. 01

   Confirm the Core version on every site

   wp core version, or the Updates screen. Anything below 7.1.1 (or below the matching security release for an older supported branch) needs updating now. Write down which sites were on 6.8.0–7.0.1 between 17 July and their update date; those are the sites the rest of these checks are about.

2. 02

   List installed themes, including inactive ones

   wp theme list, or Appearance → Themes. An inactive theme nobody on your team installed is the fingerprint of a Click2Shell forced install. Record its slug and the directory’s creation time before removing it. Note that a forced install alone does not prove the chain completed; the plugin check below does.

3. 03

   List installed plugins and look at the directory names

   wp plugin list, then ls -la wp-content/plugins. Look for a plugin directory named with a plausible word and a six-character hex suffix, for “CMSmap” or any security plugin you did not install, and for any plugin whose directory holds a single small PHP file. Compare timestamps with your July update date.

4. 04

   List administrators and sort by registration date

   wp user list --role=administrator --fields=ID,user_login,user_email,user_registered. Look for logins of the form wpsvc_, wp2_, or w2s_ plus hex, for emails at domains you do not recognise, and for any account registered on or after 17 July that nobody can vouch for.

5. 05

   Search the access logs for the two attack surfaces

   For wp2shell: POST requests to /wp-json/batch/v1 or ?rest_route=/batch/v1, especially any that returned 200 or 207 — Wiz reports a 207 Multi-Status on that endpoint as a high-fidelity sign of success — and any user agent containing wp2shell or rezwp2shell. For Click2Shell: requests to theme-install.php with a theme parameter containing quotes or brackets, followed by admin-ajax.php with wp_customize=on and a customize_theme you did not choose.

6. 06

   Verify Core files and look for PHP where it does not belong

   wp core verify-checksums for Core, then a scan of wp-content/uploads, wp-content/cache, and mu-plugins for PHP files. A one-line file that evaluates a POST parameter and otherwise returns a 404 is the wp2shell first-stage shell and will not look like much.

7. 07

   Check what else registered itself

   wp cron event list for scheduled tasks you do not recognise, and a request to /wp-json/ to list registered REST namespaces — an unfamiliar namespace such as morning/v1 is a backdoor route. Also review Application Passwords under each administrator’s profile.

8. 08

   Check the comment queue if you run a block theme

   For Comment2Shell, look in pending and approved comments for HTML tags whose attributes span a line break. There is no observed exploitation to match against yet, so treat this as a low-cost look rather than a primary indicator.

Everything in this section applies to a site where you found evidence of compromise, whichever flaw let it in. The attacker’s first actions after any of these three chains are the same — a new administrator, a webshell, a copy of wp-config.php — and so the response is the same too. Our WordPress site keeps getting hacked guide explains why sites that skip the middle steps come back within weeks.

1. 01

   Preserve before you change anything

   Copy the suspicious files with their hashes and timestamps, export the users and usermeta tables, and pull the web server access logs covering July onward before rotation or cleanup overwrites them. Log retention on shared hosting is short; this is the first thing to run out.

2. 02

   Patch Core and close the endpoint

   Update to 7.1.1. If any site must stay on an older version for a short period, block POST requests to /wp-json/batch/v1 and the rest_route equivalent at the web server or WAF, and enable DISALLOW_FILE_MODS in wp-config.php, which prevents the forced theme install and the plugin upload that both Click2Shell and Comment2Shell depend on. Neither is a substitute for the update.

3. 03

   Treat every credential the site could read as taken

   Database password, WordPress salts, every administrator password and application password, SMTP, payment and API keys in wp-config.php or plugin settings, and the hosting-panel and SFTP credentials of the account. Rotate from a trusted device; the compromised site is not one.

4. 04

   Remove the identities, not just the files

   Delete rogue administrators, revoke all sessions, remove unknown application passwords and SSH keys, and check the hosting panel for users or API tokens added since July. GreyNoise’s actor moved from the site to the database to the host; assume yours did too.

5. 05

   Rebuild the application from clean sources

   Replace Core, every plugin, and every theme from fresh downloads rather than editing suspicious lines out. Remove the forced-install theme, the disguised plugin, and any PHP in uploads, cache, or mu-plugins. Diff the active theme against its original to catch the injected call you were not looking for.

6. 06

   Clean the database and scheduled tasks

   Review autoloaded options for encoded blobs and injected script, remove unknown cron events, and remove any REST route the rebuilt code no longer registers. The wp2shell first stage lived in the database before it ever touched a file.

7. 07

   Check the neighbours

   If the site shares a hosting account, a server, or a database server with others, the credentials it held reach them. Run the checks above on every site in that boundary before declaring any one of them clean. On a control-panel server, that means a root-level review, not a per-site scan.

8. 08

   Retest after normal operation resumes

   Re-run the checks after caches expire, cron has fired, and real traffic has returned. Then keep watching the administrator list and the plugin directory for the next month; the reinfection case study shows what happens when that step is skipped.

This advisory was compiled on 22 September 2026 from the published sources below, together with our own casework from the past two months. Figures are quoted as the source reported them and were not independently re-measured. Where a claim rests on a single source, that source is named next to it in the text.