WordPress exposure: 7,982,220 matching sites and a file inclusion flaw with a short exploitation window

A content management system with millions of installations turns a single core vulnerability into a population problem. The WordPress core file inclusion issue disclosed in September 2026 is a clear example.

Method and scope

Every count in this article comes from ZoomEye international, queried through the official Python SDK on 3 October 2026 between 02:33 and 02:35 UTC. All queries used the sub_type=all scope, which covers devices and websites, with a page size of one. The returned figure is the total match count for the fingerprint, not the number of records retrieved.
A fingerprint match describes what the search engine observed on the wire. It does not confirm that a system runs an affected build, and it does not confirm that a system is exploitable. Exposure data and vulnerability confirmation are separate questions, and the sections below keep them apart.

The disclosed risk

WordPress core versions 4.7.0 through 7.1.1 are affected by CVE-2026-87902, a path traversal issue in the get_page_template() function that allows unauthenticated local file inclusion and, under specific conditions, remote code execution [1][2]. Published scores range from 8.1 to 9.2 depending on the source [1][2].
Fixed releases are 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9 and 4.7.37, and the flaw was added to the Known Exploited Vulnerabilities catalog on 25 September 2026 [1][2].
Exploitation began within hours of the patch release on 22 September. Reporting describes the first observed attempt at 11:49 UTC, a total of 68 recorded attempts in the initial wave, and source addresses including 104.194.9.227, 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170 and 92.246.130.76 [1][3].

What ZoomEye shows

Query	Scope	Matching assets
app="WordPress"	all (devices and websites)	7,982,220

Roughly eight million matching sites is the largest population in this collection, and the figure describes sites identified as running WordPress rather than sites running an affected version. Version detection for WordPress is unreliable from external fingerprints, because many sites hide the generator tag and use caching layers that mask the origin.

The preconditions that limit exploitation

Reporting describes three conditions required for the remote code execution outcome rather than for the file inclusion itself [1][3].
First, the site must contain a theme directory named with a page- prefix. Second, a readable copy of pearcmd.php must be present on the server. Third, the PHP configuration must have register_argc_argv enabled. The file inclusion is broader than the code execution path, but the severe outcome depends on all three.
Artifacts named in the exploitation reporting include files called wp-pear-rce-flag.php and poc87902.php, and files prefixed with luci_ or zeta_ [1][3].

Using exposure data for this class of flaw

For WordPress, an external count is a rough sense of scale rather than an inventory. A site owner who wants an actionable list should work from the CMS's own update reporting and from a host-level file inventory, because the affected files are in the core distribution [2].
Where ZoomEye helps is in checking whether a specific site is externally identifiable as WordPress at all. A site whose fingerprint is hidden is still vulnerable, so an absence of fingerprint evidence is not evidence of safety. That limitation applies to every exposure figure in this article and is worth stating plainly, because a count that appears to exclude a site can create false confidence.

Remediation and verification

Update core to a fixed release. Managed hosting platforms applied the update centrally, but sites on unmanaged infrastructure depend on the site owner, and reporting indicated that exploitation attempts started before many owners had acted [1].
Check the filesystem after updating. The file names listed above are specific enough to search for, and a site that never ran an affected version will not contain them [1][3].
Review access logs for requests to the affected function. The 68 attempts recorded in the initial wave indicate that scanning began immediately, so a request pattern that predates the site's update window is a meaningful signal [3].

Limitations

The count describes matching sites at a single point in time. It cannot determine which WordPress version each site runs, whether the preconditions for code execution are present, or whether a site is a production deployment rather than a staging environment. Addresses cited from exploitation reporting are historical observations and should not be treated as a current blocklist without further verification.

References

1. FreeBuf analysis of the WordPress core file inclusion flaw and the exploitation timeline: https://m.freebuf.com/news/501523.html
2. NVD record for CVE-2026-87902: https://nvd.nist.gov/vuln/detail/CVE-2026-87902
3. Reporting on the initial exploitation wave and its indicators: https://blog.csdn.net/weixin_41905135/article/details/164372827
4. ZoomEye international search platform: https://www.zoomeye.ai/