Content management and web applications

WordPress: XSS2Shell core check and October 2026 plugin checks

WordPress XSS2Shell check

WordPress Core 4.7 through 7.0.2 reflects the submitted username in the wp-login.php error message through sprintf() without adequate sanitization. A whitespace parser-differential payload (< area, with a space between < and the tag name) survives PHP strip_tags() but is re-tokenized by WordPress's KSES sanitizer into a live DOM element. An attacker who can get a logged-in administrator to send that crafted login form runs attacker JavaScript in the WordPress origin, and can then chain the injected session privileges into full remote code execution through OAuth app-password abuse and plugin upload. No account is required for the XSS stage. Disclosure by PWN.AI on 2026-08-07. WordPress shipped the fix in 7.0.3 the same day.

Quick start

1. Download the script. The repository is mirrored on GitHub and Codeberg; pick a base URL.

   # BASE from GitHub:   https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main
   # BASE from Codeberg: https://codeberg.org/PrivacySafe/security-patches/raw/branch/main
   # curl -fLO "$BASE/wordpress/wordpress-xss2shell-check.sh"
   curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/wordpress/wordpress-xss2shell-check.sh
   

2. Read it before running it, then make it executable.

   less wordpress-xss2shell-check.sh
   chmod +x wordpress-xss2shell-check.sh
   

3. Check a site. The probe is a non-destructive POST to wp-login.php that generates one failed-authentication entry.

   ./wordpress-xss2shell-check.sh check https://your.site
   

4. Full defensive-posture audit.

   ./wordpress-xss2shell-check.sh audit https://your.site
   

5. Look for signs of exploitation in web server logs and plugin directories.

   sudo WP_ROOTS="/var/www/html /srv/www" ./wordpress-xss2shell-check.sh hunt
   

Commands

Environment: WP_ROOTS (space-separated directories to look for wp-content/ under; default /var/www /srv/www /srv/www/html /opt/wordpress), HUNT_SINCE (how far back hunt looks; default 2026-08-07, the disclosure date), HUNT_LOGS (extra log file globs), CURL_OPTS (extra curl options, e.g. --insecure for a self-signed certificate).

What the probe checks and why it is non-destructive

The probe posts < area id=ajaxurl href=/?rest_route=/> as the username to wp-login.php. On a vulnerable WordPress install, KSES re-tokenizes the whitespace-prefixed tag into a real <area id="ajaxurl"> element in the error message. On a patched install the output is escaped or the tag is stripped. The checker looks for id="ajaxurl" and <area together with Error: (the login-failure marker, which also prevents false positives against non-WordPress pages). This is the same matcher the verified Nuclei template uses.

Posting to wp-login.php with an incorrect password generates one failed-authentication record in the auth log and no other side effects: no account is created or modified, no data is written, and no session is opened.

What hunt looks for

In web server access logs (Apache and nginx, from standard paths and from HUNT_LOGS):

• POST bursts to wp-login.php: the XSS stage sends a crafted login form. Legitimate traffic is usually much lower volume.
• Requests to authorize-application.php: this page handles OAuth application-password authorization and is not normally accessed directly. A request here after a burst of login POSTs is a strong indicator of stage 4 of the chain.
• Plugin upload requests (update.php?action=upload-plugin): the RCE stage uploads a plugin zip containing a webshell. Each upload that the admin did not make is worth investigating.
• Direct PHP access in plugin directories returning 200: a webshell dropped via plugin upload lives at wp-content/plugins/<slug>/<slug>.php and is web-accessible without activation. Successful GET requests to a path matching that pattern are a strong signal.

In plugin directories under WP_ROOTS (with WEBROOT supplied as an argument or from the environment):

• PHP files created after HUNT_SINCE: any *.php file that appeared after the disclosure date is worth reviewing. The webshell dropped by the public PoC is not named uniquely, so a new PHP file in any plugin directory is a lead.

In WordPress debug.log (under WP_ROOTS):

• Fatal errors, call_user_func warnings, and system() or shell_exec() calls that suggest code execution.

A hit tells you exactly where to look. Confirm by reviewing the specific request IDs, the plugin directory contents, and your outbound traffic logs.

Before you run it

• check and audit make HTTP requests to the target. The probe causes one failed-authentication entry. The sensitive-file checks each make one GET request. audit fetches the homepage, the OPML endpoint, several sensitive paths, the homepage headers, and the REST API user list: nine or ten requests in total.
• hunt is read-only. It reads log files and file system metadata; it does not modify anything.
• Version detection can miss. WordPress plugins and themes often hide the meta generator tag. A clean version result does not mean the site is patched. The XSS reflection probe covers this case independently.
• GNU/Linux only. The find -printf and date formats assume GNU tools.
• Root helps but is not required. Without root, hunt reads only the logs you own and may miss files in other users' directories.
• It also checks running docker and podman containers, unless you name a directory or set SCAN_CONTAINERS=0. A read-only probe inside each running docker and podman container copies only the Plugin Name and Version header lines of each covered plugin's main file, plus its modification time, and the script runs once per container in isolation against that copy. For Rank Math PRO 3.0.123 the arrival-time test uses the modification time alone, because a container's inode change time cannot be recovered. The output says so. hunt does not look inside containers. A path shown as .../docker_NAME/PATH is the PATH inside the container NAME.

Sources

• PWN.AI disclosure: https://pwn.ai/blog/xss2shell
• NVD record: https://nvd.nist.gov/vuln/detail/CVE-2026-64638
• THN coverage: https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
• NHS cyber alert: https://digital.nhs.uk/cyber-alerts/2026/cc-4827
• Nuclei template (upstream): projectdiscovery/nuclei-templates PR #16785

WordPress plugin checks, October 2026

Script: wordpress/wordpress-plugins-oct2026-check.sh

Eight plugin problems: seven vulnerabilities and one supply-chain compromise. The script reports all eight and hunts for signs of abuse.

Two booking plugins and a registration plugin, covered by the same script:

One more plugin, exploited since 7 October 2026:

Once activated, the Rank Math malware reportedly contacts a command server (rank1cdn[.]com) and plants hidden PHP backdoors that it rebuilds whenever a visitor loads a page. It creates administrator accounts, drops a fake WordPress core file and PHP code hidden inside .cache files, adds scheduled tasks, can add SSH keys, and reads every secret the web server can reach: WordPress passwords, the database login, API keys and payment gateway keys. Treat an activated tainted copy as a full compromise. The vendor notice is rankmath.com/kb/pro-3-0-123-security-incident.

Quick start

1. Download the script. The repository is mirrored on GitHub and Codeberg; pick a base URL.

   # BASE from GitHub:   https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main
   # BASE from Codeberg: https://codeberg.org/PrivacySafe/security-patches/raw/branch/main
   # curl -fLO "$BASE/wordpress/wordpress-plugins-oct2026-check.sh"
   curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/wordpress/wordpress-plugins-oct2026-check.sh
   

2. Read it before running it, then make it executable.

   less wordpress-plugins-oct2026-check.sh
   chmod +x wordpress-plugins-oct2026-check.sh
   

3. Check the versions, then hunt. Run the hunt as root so it can read crontabs and logs.

   ./wordpress-plugins-oct2026-check.sh check
   sudo ./wordpress-plugins-oct2026-check.sh hunt
   

Commands

With WP-CLI 2.12 on WordPress 6.4.3, the REST routes of the deactivated plugins went from 200 to 404 and rollback brought them back. Update the plugin to its fixed version, then reactivate it. An update does not remove accounts or files an attacker already created, so run hunt. As root, WP-CLI runs as the owner of wp-config.php and never as root, if runuser is not available the plugin is left active and the script says how to deactivate it by hand. STATE_DIR (default /var/lib/psf-security-patches/wordpress-plugins) holds the record rollback uses.

Exit codes: 0 nothing affected or nothing found, 1 affected or to review (check) or an indicator found (hunt), 2 bad arguments.

A pre-release of a fixed release (7.9.2-rc1 against a fix in 7.9.2) counts as below it, as in semantic versioning, so it is never reported as the release.

mitigate and rollback change the plugins on the host. Run them with sudo from an admin account, or as the site's own user (set WPM_ALLOW_NONROOT=1), so the change is recorded against a person. The script stops and prints the exact command if you forget:

sudo ./wordpress-plugins-oct2026-check.sh mitigate --all-affected --dry-run
sudo ./wordpress-plugins-oct2026-check.sh mitigate --all-affected
sudo ./wordpress-plugins-oct2026-check.sh rollback

Reading the Rank Math result

• 3.0.123 whose files changed inside the window: likely the tainted package.
• 3.0.123 that arrived before the window opened: not the tainted package.
• 3.0.123 that arrived after the window: probably clean, because Rank Math pulled the bad files, but the script asks you to update and run the hunt. File times are circumstantial: a backup restore or rsync resets them. Also check the plugin update history, your backup log and the email Rank Math sent to affected accounts.
• 3.0.124 or newer: clean replacement. If the site ever ran 3.0.123, run the hunt anyway.

Reading the Profile Builder result

• 4.0.4 or earlier: affected. Update to 4.0.5. A registered user may be able to gain a higher role, so afterwards review administrator and editor accounts (the hunt lists administrators created since 1 October). If you cannot update today, deactivate the plugin and close public registration. Only the free profile-builder folder is checked. A folder named profile-builder-pro is a different product and is not matched.

Reading the LatePoint and Amelia results

• LatePoint 5.7.4 or earlier: affected. Update to 5.7.5. An attacker who brute-forces the one-time code logs in as a customer, so afterwards review recent customer logins and bookings. The hunt counts web log requests that name LatePoint's OTP route (auth__verify_otp) by source address. Many from one address is a lead. POST bodies are not normally logged, so a POST-only attack may not show.
• Amelia 2.4.11 or earlier: affected. Update to 2.4.12. An SQL injection can expose the whole database, including user password hashes, so afterwards rotate administrator passwords and the keys and salts in wp-config.php, and run the hunt for new administrators.
• If you cannot update today, deactivate the plugin: an inactive plugin registers no routes (PrivacySafe recommendation).

Reading the SureCart result

• 4.9.5 or earlier: affected. Update to 4.9.6, or deactivate the plugin if you cannot update today (an inactive plugin registers no routes; this is PrivacySafe's recommendation). After updating, reset administrator passwords and end all sessions by changing the AUTH_KEY and SECURE_AUTH_KEY salts in wp-config.php, because an authentication bypass leaves no account trace.
• 4.9.6 or newer: fixed. If the site ran 4.9.5 or earlier in October, run the hunt. It lists new administrator accounts, but it cannot see a login as an existing user, so also review recent administrator activity.
• SureCart has had a run of authentication and account-takeover fixes this autumn, so keep it current rather than pinning a version.

Reading the OttoKit result

• 1.1.40 or earlier: affected. Update to 1.1.41, or deactivate the plugin if you cannot update today (an inactive plugin registers no routes; this is PrivacySafe's recommendation).
• 1.1.41 or newer: fixed, but a site that ran an affected version in October may already have a rogue administrator. Run the hunt.

What the hunt looks for

The Rank Math indicators come from public reports of the incident (Rank Math, Wordfence and Patchstack, as relayed by several write-ups). The named rows, domain, usernames, fake core file and cron tag are specific to that attack. A clean hunt does not prove a site is clean, and the published list may be incomplete. The administrator list is a generic check that also catches other privilege escalations.

How the database check works, and why it avoids wp-cli

The script reads DB_HOST, DB_NAME, DB_USER, DB_PASSWORD and $table_prefix from wp-config.php with a text search, and runs three SELECT queries with the mysql client. The password goes through the MYSQL_PWD environment variable, not the command line. It deliberately does not use wp-cli: wp-cli loads the site's PHP, including mu-plugins, and a backdoor could run when it does. localhost:/path/to.sock and host:port forms of DB_HOST are understood. If there is no readable wp-config.php, no mysql client or the login fails, the script prints the three queries so you can run them yourself.

If the hunt finds something

For the Rank Math malware:

1. Delete the whole rank-math-pro plugin folder first. Deactivating it does not stop the malware, and it recreates deleted files whenever someone visits the site, so remove the folder and the database rows before the other files.
2. Block outgoing traffic to rank1cdn[.]com.
3. Restore files and database from a backup taken before 15 October 2026 20:02 UTC.
4. Rotate WordPress user passwords, the database login, the keys and salts in wp-config.php, payment, SMTP and API keys, and hosting, FTP and SSH logins.
5. Only then install Rank Math PRO 3.0.124, downloaded by typing the vendor's address yourself. Rank Math says it never sends download links by email.

For OttoKit: update to 1.1.41, remove administrator accounts you did not create, reset the password of every administrator and rotate the keys and salts in wp-config.php, and review plugins and themes for files you did not add.

LiteSpeed Cache: fixing and a protective measure

Update LiteSpeed Cache to 7.9.2 or later. Until then, hold every comment for moderation (Settings, Discussion). That is our reading of the description, which needs a published comment from an unauthenticated visitor; this is PrivacySafe's recommendation.

Sources

• Rank Math: PRO 3.0.123 security incident
• CVE record for CVE-2026-113500 (WPScan)
• Patchstack: Bricksforge arbitrary file upload exploited (CVE-2026-85097)
• Patchstack entry for the OttoKit flaw

wp2shell: WordPress core pre-authentication RCE (CVE-2026-63030 and CVE-2026-60137)

Script: wordpress/wordpress-wp2shell-check.sh

wp2shell chains two flaws in WordPress core into remote code execution for an unauthenticated attacker on a default install, with no plugins and no login. It was disclosed and fixed on 17 July 2026, exploitation began on 20 July, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 21 July. Observed attacks create rogue administrator accounts and install webshells. Discovered by Adam Kues of Searchlight Cyber.

Update with wp core update, to 6.8.6, 6.9.5, 7.0.2 or newer on your branch.

Object cache caveat: when a persistent object cache (Redis, Memcached) is active, the SQL injection sink is not reached and the chain does not fire. The site still needs the update, if the cache is ever disabled or flushed the full chain becomes reachable again.

Quick start

curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/wordpress/wordpress-wp2shell-check.sh
less wordpress-wp2shell-check.sh
chmod +x wordpress-wp2shell-check.sh
./wordpress-wp2shell-check.sh check
./wordpress-wp2shell-check.sh hunt

By default it searches /var/www /srv /home /opt /usr/share/wordpress /usr/share/nginx /var/lib/wordpress. Pass directories to narrow it. Everything it does is read-only.

Commands

Env: STATE_DIR (default /var/lib/psf-security-patches/wp2shell) holds the backups and manifest. HUNT_SINCE (YYYY-MM-DD, default 2026-07-17) sets the date for file changes. WP2S_LOGS names web server logs (space separated paths or globs) when they are not in the usual places.

Commands that change the host need root. Run them with sudo from an admin account, not from a root login, so the change is recorded against a person. The script stops and prints the exact command if you forget:

sudo ./wordpress-wp2shell-check.sh mitigate --dry-run
sudo ./wordpress-wp2shell-check.sh mitigate
sudo ./wordpress-wp2shell-check.sh rollback

How the check decides

• Version, per branch. 6.8.0 to 6.8.5 is reported as the SQL injection only. 6.9.0 to 6.9.4, 7.0.0 to 7.0.1 and 7.1 beta 1 are reported as the full chain. 6.8.6, 6.9.5, 7.0.2, 7.1 beta 2 and later are reported as fixed. Anything before 6.8.0 as not affected.
• The source, because a package can backport. A distribution can carry both fixes under an older version number. The SQL injection fix replaces the is_array test and implode() in wp-includes/class-wp-query.php with wp_parse_id_list(). The batch fix adds a guard against starting a new top-level REST cycle while one is already dispatching, in wp-includes/rest-api/class-wp-rest-server.php. The script judges each flaw from its own signature: both present is reported as a backport and not exposed. Only one present is reported as partially patched and exposed, naming the flaw that remains.
• A fixed version whose files still hold the vulnerable code is reported as a mismatch (a partial or failed update).
• The block on the batch route. If an install is exposed, the script looks in the usual nginx, Apache and .htaccess locations for a refusing rule for each of the two URL forms and says which it found. Both forms must be covered. The block closes the chain's entry point. It does not fix the SQL injection, so update anyway.

Checked against the real source files of WordPress 6.8.5, 6.8.6, 6.9.4, 6.9.5, 7.0.1 and 7.0.2: the verdicts above came out as described. A tree with the 6.9.4 version file and the 6.9.5 source files was recognized as a backport and reported as not exposed, and the reverse (6.9.5 version file, 6.9.4 source) was reported as a partial or failed update.

If you cannot update at once

./wordpress-wp2shell-check.sh mitigate --dry-run, then mitigate --reload, applies the web server block below. rollback removes it. Verified on nginx 1.24 in front of a PHP handler: the plain, subdirectory, query-string, URL-encoded and mixed-case forms of the route all got 403 after the change, other REST routes, index.php and static files were unaffected, and rollback restored the original behavior. The rule matches the route anywhere in the path, so a WordPress in a subdirectory is covered, and it applies to every PHP virtual host on the machine. On a live WordPress 6.9.4 (an affected release) on Apache 2.4.58 in the Debian layout, the check flagged the install as the full chain. The batch route answered anonymous POSTs (207 and 200) before the block and 403 after it, in the query-string, index.php/ and URL-encoded forms. The login page and other REST routes kept working, the check then reported a refusing rule for both URL forms, and rollback restored the original behavior. On Apache 2.4.58 with WordPress 6.4.3, the batch route answered 403 in the plain, query-string, URL-encoded and index.php/ forms on every virtual host, while other REST routes still answered. In the Debian layout, a2enconf and configtest accepted the rule and rollback removed it. The block editor uses the batch route for some saves. On a site that is edited, the plugin below leaves editors working and is the better choice.

Refuse both URL forms of the batch route at the web server.

nginx:

location ~* "^/wp-json/batch" { return 403; }
if ($args ~* "rest_route=(%2F|/)batch") { return 403; }

Apache:

RewriteEngine On
RewriteRule ^wp-json/batch - [F,L]
RewriteCond %{QUERY_STRING} rest_route=(%2F|/)batch [NC]
RewriteRule ^ - [F,L]

If you cannot install a web server rule, a WordPress plugin can block the route from within WordPress. Drop this file on the server at wp-content/plugins/disable-batch-api-for-unauth.php and activate it from the Plugins screen:

<?php
/**
 * Plugin Name: Disable Unauthenticated REST Batch API
 * Description: Requires an authenticated WordPress user for REST batch requests.
 * Version: 1.0.0
 * Requires at least: 5.6
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

function wporg_require_authentication_for_rest_batch( $result, $server, $request ) {
    if ( '/batch/v1' !== strtolower( untrailingslashit( $request->get_route() ) ) || is_user_logged_in() ) {
        return $result;
    }
    return new WP_Error(
        'rest_batch_authentication_required',
        'Authentication is required to use the batch API.',
        array( 'status' => 401 )
    );
}
add_filter( 'rest_pre_dispatch', 'wporg_require_authentication_for_rest_batch', -1000, 3 );

This approach causes fewer compatibility issues than a network-level block, because authenticated editors keep full access to the batch endpoint. Source: Searchlight Cyber.

The block editor uses the batch route for some saves, so a network-level block may affect editing until you update. These are protective measures. They do not fix the underlying flaws.

If an affected site was reachable after 17 July 2026

Run hunt. Then treat any strong lead as a possible compromise: update core. In the database look for administrator accounts you did not create (wp user list --role=administrator) and for unexpected customize_changeset posts; review wp-content/plugins and mu-plugins; and rotate the database password, the salts in wp-config.php and every administrator password. The hunt cannot see request bodies, which is where the exploit's payload travels, so a quiet log does not rule out an attack.

Sources

• WordPress 7.0.2 release announcement
• CVE-2026-63030 at CVE.org and GHSA-ff9f-jf42-662q
• CVE-2026-60137 at CVE.org and GHSA-fpp7-x2x2-2mjf
• Searchlight Cyber: wp2shell pre-authentication RCE in WordPress core
• Rapid7 ETR: CVE-2026-63030 wp2shell

The Security Patches software and this documentation are dedicated to the public domain under CC0 1.0 Universal. Other pages on privacysafe.app/docs are CC BY-SA 4.0 unless the page says otherwise.

Edit this page on Codeberg