Click2Shell 暴露面：790 万 WordPress 资产能说明与不能说明什么

Click2Shell Exposure: What 7.9 Million WordPress Assets Do and Do Not Tell You The Click2Shell disclosure on September 21, 2026 described an unauthenticated RCE chain in WordPress Core: a crafted link makes a logged-in administrator's browser install a catalog theme automatically, then the theme's unprotected AJAX handler pulls attacker PHP from a remote package and executes it. WordPress shipped the fix in 7.1.1 via changeset 63664. No CVE exists yet, and researchers reported no in-the-wild exploitation. Within a day of the disclosure, a ZoomEye query for app="WordPress" returned 7,945,496 matching assets globally (executed 2026-09-22, UTC). Headline numbers like this invite two opposite mistakes: dismissing the event as noise, or treating every matched host as compromised. Both are wrong, and the difference lies in reading the exposure surface correctly. The chain has an authentication-shaped gate Every stage of Click2Shell requires one thing before any code runs: a logged-in administrator must visit an attacker-chosen URL. There is no need for attacker WordPress credentials, but there is also no code execution without that visit. This shapes the real exposure surface. A WordPress instance is materially at risk only where some administrator might plausibly click such a link, which is nearly everywhere in practice, but the attack is a social-engineering-assisted chain, not an open unauthenticated door into PHP execution. The count of 7.9 million describes indexed product assets. It is not a count of vulnerable patch levels, and it is certainly not a count of successful attacks. Version and component boundaries The exposure surface has two distinct layers: Core layer: the theme-slug parser discrepancy affects all WordPress versions before 7.1.1. Patching to 7.1.1 or later closes the forced-installation stage. Theme layer: the second stage abuses unprotected AJAX endpoints in catalog themes, identified specifically in Mobile Repair Zone 2.5.4 and over 40 other themes. A patched core with a vulnerable inactive theme still carries the second-stage code if an attacker can get that theme loaded during a Customizer preview. This is why a single product fingerprint cannot represent the whole surface. ZoomEye's app="WordPress" query answers "where is WordPress", which is the outer boundary of the problem. It cannot answer "which of these runs a vulnerable theme", because themes are not part of the product fingerprint. Reading the number responsibly For teams using ZoomEye during this event, the query's verified use is scoping and prioritization: locating WordPress assets in a network range, comparing counts before and after cleanup, or flagging assets that reappear after being decommissioned. The observation should be recorded with its query, timestamp and total, and any report should repeat the caveat: indexed assets are not confirmed vulnerable hosts, and exposure count is not a breach count. References SecurityOnline.info, "WordPress Click2Shell Vulnerability Triggers Core RCE, PoC Published", September 21, 2026. pwn.ai technical report on the Click2Shell chain, as cited by the source article. ZoomEye query record: app="WordPress", 2026-09-22, 7,945,496 results.