WordPress operators got a useful reminder this week: the first exploit request is only the beginning of a hosting incident. InMotion Hosting published a detailed investigation of two customer sites compromised after the July WordPress core security releases, showing how attackers moved from initial access into multiple persistence layers that survived a basic cleanup.
The case study centers on the chained WordPress issues now commonly discussed as “wp2shell”: CVE-2026-60137, a SQL injection issue in WordPress Core, and CVE-2026-63030, a REST API batch-route confusion issue. WordPress shipped emergency fixes on July 17 in WordPress 7.0.2, 6.9.5, and 6.8.6, and CISA added the vulnerabilities to its Known Exploited Vulnerabilities catalog on July 21.
InMotion’s write-up says its teams saw POST bursts against the WordPress REST batch route followed quickly by rogue administrator creation. From there, the attacker planted a temporary PHP helper, copied or restored webshell access, created must-use plugin persistence, checked for the attacker’s administrator account, destroyed other users’ session tokens, and removed traces of the helper. One site was cleaned and then reinfected six days later, underscoring the risk of restoring from backups or leaving a hidden persistence mechanism behind.
Why hosting teams should care
For managed WordPress providers, agencies, and site owners, the practical lesson is that “updated WordPress” and “deleted bad admin user” are not sufficient incident-response milestones. A verified cleanup needs to review the filesystem, must-use plugins, suspicious plugin and theme directory names, uploads directories, cron entries, database users and options, configuration changes, session tokens, and server logs.
The timing matters because many WordPress installs rely on automatic core updates. InMotion notes that automatic updates did not reach one of the investigated sites in time, which is exactly the gap attackers scan for after a high-profile release. Hosts should be checking fleet-level patch completion, not merely assuming WordPress.org’s forced-update process reached every account.
For customers, the takeaway is less glamorous but more useful: if a WordPress site was exposed during the July patch window, ask the host or developer for evidence of a persistence review. The absence of a defaced homepage does not prove the absence of a webshell.
Primary source: InMotion Hosting: “Inside a wp2shell WordPress Compromise and Recovery”.