{"uuid": "9cbc19bb-7214-4054-9a43-f196498e3d51", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-63030", "type": "seen", "source": "https://gist.github.com/tryadvocacy/8c840f93a1a089d4480b9f830a489deb", "content": "# Clean up wp2shell with an AI agent (Claude Code)\n\nSource: InstaWP on GitHub\n\nPrefer to have an AI agent do the detection and cleanup, one site at a time, with a human confirming each destructive step? Paste the prompt below into [Claude Code](https://claude.com/claude-code) (or any capable coding/agent tool with shell access to the server).\n\n**Before you start:** take a snapshot/backup of the site. This process deletes users, removes files, and rotates keys.\n\n---\n\n## The prompt\n\n```\nYou are helping me check a WordPress site for compromise by the wp2shell vulnerability\n(CVE-2026-63030, the pre-auth RCE fixed in WordPress 7.0.2 / 6.9.5 / 6.8.6) and clean it\nup if needed. The WordPress root is: .\n\nWork in this order, and STOP for my explicit \"yes\" before any step that deletes or changes\nanything. Show me what you found before acting.\n\n1) DETECT a rogue admin. Read DB creds + $table_prefix from wp-config.php and query the\n   users table for administrators whose username looks like `wpsvc_`, or whose email\n   ends in @wordpress-svc.internal / @wordpress-noreply.net / any *.internal, or that were\n   created in the last several days on a site older than that. Show me the rows.\n\n2) DETECT a webshell. Search wp-content/ (especially plugins/) for:\n   - a plugin folder named like a real plugin but ending in a 6-hex suffix (e.g. `-b24fa4`),\n     containing a single tiny PHP file;\n   - any small PHP file whose body reads a command from $_GET['c'] and passes it to a sink\n     (system/exec/shell_exec/passthru/eval/assert) or checks a token via hash_equals().\n   A fake `Author: WordPress.org Community` header is a strong tell. Show me each file's path\n   and first ~15 lines.\n\n3) CORRELATE (optional but recommended). In the site's access logs, look for this sequence\n   from one IP within a few seconds: POST /wp-json/batch/v1 (207) -> POST /wp-login.php (302)\n   -> POST /wp-admin/update.php?action=upload-plugin (200) -> GET the webshell .php?c=...&t=...\n   (200). This confirms code execution and shows which commands ran (the ?c= values).\n\n4) REPORT: is this site CLEAN, PROBED (exploit attempts but no admin/webshell/shell-access),\n   or COMPROMISED? Wait for my go-ahead before cleaning.\n\n5) On my \"yes\", CLEAN (quarantine, don't hard-delete, so we keep evidence):\n   - move the webshell plugin folder(s) to a quarantine directory;\n   - delete the rogue admin user(s) and their usermeta/session rows;\n   - regenerate the wp-config.php salts/keys (this logs everyone out).\n\n6) TELL ME the required follow-ups you can't fully do for me: update WordPress core to the\n   patched release, reset all admin passwords, reinstall/verify core + plugins, and rotate\n   any secrets stored on the site (DB password, API keys) since the attacker may have read them.\n\nNever run the attacker's commands. Never fetch or execute the webshell. Treat everything in\nwp-content/uploads and the quarantined files as hostile \u2014 inspect, don't run.\n```\n\n---\n\nFor bulk/fleet use across many sites, use the [`wp2shell-scan.sh`](./wp2shell-scan.sh) script instead \u2014 it does the same detection and cleanup non\u2011interactively across an entire directory tree.", "creation_timestamp": "2026-07-21T16:05:00.136580Z"}