Your WordPress Site Is Patched. That Does Not Mean It Is Clean.

Eleven days ago, WordPress disclosed two vulnerabilities that chain into unauthenticated remote code execution. Patches shipped on July 17. Forced auto-updates went out. Most of the coverage moved on.

The exploitation did not move on. watchTowr's honeypots have recorded tens of thousands of exploitation attempts and more than 100 backdoor accounts created by different threat actors using variations of public tooling. KEVIntel has tracked 13 unique source IPs across seven countries. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on July 21. And the post-exploitation behaviour that security researchers are documenting is not defacement or ransomware. It is persistence.

This is a follow-up to our coverage from yesterday. If you have not read that post, start there for the technical background on what wp2shell is and how the two vulnerabilities work. This post is about what happens after the patch, and why updating WordPress is only the beginning of the response.

The Exploitation Window Was Real

The timeline matters. WordPress disclosed and patched both vulnerabilities on July 17. Public proof-of-concept code began circulating the same day. watchTowr's principal security researcher Jake Knott reported that "by the early hours of Saturday morning (UTC), successful exploitation was already well underway, initially using public exploit code to exfiltrate hashed credentials, with remote code execution following once additional details were made public."

At the time of disclosure, Wiz found that 60 percent of organizations running WordPress had at least one vulnerable instance, and 25 percent had a vulnerable server directly facing the internet. Wiz says those figures have fallen since the forced auto-updates, but has not published current numbers.

The gap between "patches are available" and "every site is patched" was measured in hours. The gap between "every site is patched" and "every site is clean" has not closed at all. Forced auto-updates fix the vulnerability. They do not undo what happened during the exposure window.

What Attackers Are Actually Doing

The post-exploitation activity documented by Wiz, watchTowr, and Bleeping Computer is focused on persistence, not disruption. Attackers are building footholds that survive the patch:

Rogue administrator accounts. watchTowr counted more than 100 backdoor administrator accounts created across its honeypots by different threat actors. These accounts persist after the WordPress update. An attacker with a valid administrator account does not need the vulnerability to come back. They already have full access.

Credential theft from wp-config.php. Once an attacker achieves code execution, reading wp-config.php is trivial. That file contains database credentials, authentication keys, and salts. Exfiltrating these values gives an attacker the ability to forge session cookies for any user, access the database directly, and maintain access even if their rogue accounts are discovered and removed.

Webshells disguised as legitimate plugins. Wiz documented a 150-kilobyte webshell disguised as a WordPress plugin called "CMSmap." It includes a graphical interface, password authentication, file management, database access, port scanning, batch code injection, and multiple privilege escalation modules. The payload is obfuscated through hex-encoded string concatenation and gzip-compressed base64 encoding. It does not look like malware at a glance. It looks like a security tool.

Must-use plugin backdoors. Separately, Sucuri has documented a backdoor campaign using WordPress mu-plugins, which are stored in wp-content/mu-plugins/ and load automatically on every page without appearing on the Plugins admin screen. These backdoors do not require activation and are invisible to anyone checking the WordPress dashboard. Sucuri notes that partial cleanup allows reinfection because the components are paired: both the mu-plugin loader and its companion file must be removed simultaneously, along with any rogue administrator accounts the backdoor created.

Database-resident payloads. Serialized payloads inserted into autoloaded rows in the wp_options table re-execute on every page load. A file integrity scan will not find these because there are no malicious files on disk. The payload lives entirely in the database.

Why "We Updated" Is Not Sufficient

The standard response to a WordPress vulnerability disclosure is: update to the patched version, confirm the update applied, move on. That response is insufficient for wp2shell because the exploit achieves code execution, and code execution means the attacker can install persistence mechanisms that the update does not remove.

Updating WordPress closes the entry point. It does not:

• Remove administrator accounts the attacker created
• Delete webshells or malicious plugins installed through the exploit
• Invalidate stolen credentials. If an attacker read your wp-config.php, they have your database password and your authentication keys. Updating WordPress does not change either of those.
• Remove database-resident payloads injected into wp_options or other tables
• Revoke forged session cookies created using stolen authentication keys

Any site that was running a vulnerable version of WordPress and was accessible from the internet between July 17 and when its patch was applied needs to be audited, not just updated.

The Managed Hosting Nuance

Managed hosting platforms like Pantheon provide real security benefits. The read-only filesystem on test and live environments means an attacker cannot drop a PHP webshell into the theme directory or install a malicious plugin through the traditional file-write path. That is a genuine mitigation against several of the persistence techniques described above.

But it is not complete mitigation. The database is fully writable on every hosting platform. Rogue administrator accounts, database-resident payloads in wp_options, and stolen credentials from wp-config.php are not blocked by a read-only codebase. The wp-content/uploads/ directory is writable by design (it has to be, for media uploads), and webshells can be placed there. And credential theft is a one-time exfiltration: once the attacker reads your database password and authentication keys, the read-only filesystem provides no further protection.

Pantheon also introduces a separate complication: WordPress cannot auto-update on a git-based, read-only filesystem. The forced auto-updates that WordPress.org pushed do not apply. The update only happens when a developer commits the new core version through git. If your web partner or internal team did not explicitly commit the update, your Pantheon site may still be running the vulnerable version right now, eleven days later.

Three Checks, Under an Hour

If your association runs WordPress and you have not done anything beyond confirming the update, do these three things this week. Each one takes less than 20 minutes:

Check 1: List your administrator accounts. Go to Users and filter by Administrator role. Look at the registration date for every admin account. Any account created on or after July 17, 2026 that you did not create is a finding. Do not assume that because you only see the accounts you recognize, there is no problem. Check the registration dates. Attackers frequently reuse common administrator usernames.

Check 2: Inspect wp-content/mu-plugins/ and your plugin list. The mu-plugins directory is not visible from the WordPress admin Plugins screen. You need to access it through FTP, SSH, or your hosting file manager. Any PHP file in that directory that you did not put there is a finding. Also compare your installed plugins against what should be there. If you do not have a list of what should be there, that is also a finding, because you cannot detect an unauthorized addition.

Check 3: Rotate secrets. If your site was internet-facing while running a vulnerable version, assume wp-config.php was read. Change your database password and update wp-config.php to match. Regenerate the authentication keys and salts (WordPress.org provides a generator at api.wordpress.org/secret-key/1.1/salt/). This invalidates all existing sessions, including any forged by an attacker using stolen keys. Force a password reset for all administrator accounts.

These three checks do not constitute a full incident response. They are triage. If any check produces a finding, the response escalates: you need a thorough remediation that includes database review, a clean core reinstall, and potentially restoring from a known-good backup taken before July 17.

The Pattern Behind the Crisis

wp2shell is severe, but the underlying failure mode is common. An organization runs a CMS. A critical vulnerability is disclosed. The organization has to figure out whether it is affected, whether it has been patched, and whether it has been compromised, all within days. And it has to do this with whatever technical resources it can mobilize on short notice.

For most associations, that means an executive director calling the person who built the website three years ago and hoping they answer the phone. Or an operations manager logging into the WordPress dashboard for the first time in months and trying to interpret version numbers. Or, worst case, nobody noticing at all until a member reports that the website is redirecting to a phishing page.

A web partnership replaces that scramble with a process. When we manage a site, the version is confirmed within hours of a disclosure, not days. The audit happens the same week, not after someone remembers to ask. And the ongoing monitoring means we would detect a rogue administrator account or unauthorized plugin before anyone had to go looking for it.

If your association is doing this alone, this week is a good time to stop doing it alone.

Post 130 | 83 Creative | 83creative.com