Probes for WordPress's REST API batch endpoint more than tripled on our infrastructure
In the week of 26 October, the number of sources asking our infrastructure for WordPress's REST API batch endpoint, the entry point for the wp2shell flaw chain, rose to 3.3 times its previous weekly average. Scanners also asked more often for backups, debug pages and application internals.
291 Intercept is our weekly report on what automated scanners went after on our own infrastructure, so you can check your systems for the same things. Each edition covers a week that ended at least seven days earlier.
The clearest change on our infrastructure in the week of 26 October was a jump in requests for one WordPress address: /wp-json/batch/v1. About 40 sources asked for it, 3.3 times its weekly average over the previous three weeks. That endpoint is where wp2shell begins, a chain of two flaws in WordPress core that lets an attacker with no login run code on a site.
It came in a busier week overall: roughly 620 sources probed our internet-facing infrastructure, 10% more than the average of the previous three weeks. WordPress remained the main target, with 66% of sources going after WordPress logins, XML-RPC or plugin paths, up 20%. Scanners also asked more often for parts of an application meant to stay private.
What wp2shell is
/wp-json/ is the root of WordPress's REST API, and /wp-json/batch/v1 is its batch processor, which handles a bundle of API requests together. According to Rapid7, wp2shell joins two flaws. CVE-2026-63030 is a logic flaw in that batch processor, and CVE-2026-60137 is a SQL injection in the posts endpoint. Chained together, they let someone with no account run code on WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.
The flaw was disclosed on 17 July 2026, and Rapid7 reports that CISA added it to its Known Exploited Vulnerabilities catalog on 21 July. The fixed releases are 6.9.5, 7.0.2 and 7.1 Beta 2.
Why probe for a flaw that already has a fix? Scanners don't need every site to be vulnerable, only some. A request costs them almost nothing, and any site still on an affected version is worth a second visit.
The familiar side of WordPress scanning
A coordinated toolkit of about 20 sources in a few countries ran the same list of around ten paths. It asked for the same file under many folder names, such as /wp/wp-includes/wlwmanifest.xml, /shop/wp-includes/wlwmanifest.xml and /wordpress/wp-includes/wlwmanifest.xml, along with /xmlrpc.php.
wlwmanifest.xml is the Windows Live Writer manifest found on default WordPress installs, and asking for it under common folders is a way to find WordPress sites before trying plugin or theme exploits. XML-RPC is the follow-up: researchers found in 2015 that its system.multicall method lets an attacker try hundreds of passwords in one request.
Leftovers and internals
Compared with the previous three weeks, the number of sources looking for backup and dump files rose 73%, those after application internals such as Spring Boot actuator rose 63%, and those requesting diagnostic pages like /phpinfo.php and /info.php rose 52%. Because the overall number of sources also grew, their shares moved less: diagnostic pages went from 15% of all sources on average to 21%. The chart below shows six of this week's categories, each with its share of sources this week against its average over the previous three weeks.
Share of all separate sources that went after each target, in percent. A source can go after several targets, so the shares add up to more than 100%.
| This week | Average of the previous 3 weeks | |
|---|---|---|
| Backups and database dumps | 12% | 9% |
| Application management endpoints | 13% | 9% |
| Debug and diagnostic pages | 21% | 15% |
| WordPress logins and files | 66% | 61% |
| Exposed source code (Git, SVN) | 29% | 24% |
| Secret and configuration files | 33% | 33% |
/actuator/env drew about 40 sources, 2.4 times its previous average. On Spring Boot, that endpoint shows the application's configuration properties. Spring's documentation says only health is reachable over HTTP by default and that env values are masked by default, but when developers open it up without restricting access, it can leak credentials, API keys and internal settings. /wp-config.php.bak, a forgotten WordPress config backup, doubled to about 40 sources.
A second toolkit of about 20 sources mixed these interests in one sweep: /.env, /.git/config, /info.php, /config.json, /server-status and /debug/default/view. That last path belongs to the Yii 2 debugger, which shows session data, environment variables and database queries. Yii's guide says it normally works only from localhost, but CVE-2026-103475, disclosed on 30 September, covers yii2-starter-kit through 4.2.0, whose default configuration opens it to all IP addresses.
Following up on last week
Our last edition noted more scanners looking for .env files in subfolders. That continued. /v2/.env and /old/.env each drew about 60 sources, roughly twice their previous average, with /production/.env at 50 and /storage/.env at 40. In all, 200 sources went after secret and configuration files, up 16%, roughly in step with the rise in sources overall, so their share held at 33%. For scale, researchers reported in February 12,088,677 IP addresses serving publicly accessible .env-style files.
The Git probing we led with last week eased in share but stayed above its earlier level. In all, 170 sources looked for source-code repositories, 20% more than the three-week average, though their share of all sources fell from 37% to 29%.
Who was asking
More than half the sources (55%) came from cloud and hosting networks, with DigitalOcean and Google Cloud at 20% each, and 85% of all sources appeared on only one day. Most also tried to look like people: 82% sent strings posing as ordinary browsers, yet 85% behaved like automation, so the disguise is thin.
What went quiet
Requests for /wp-content/plugins/hellopress/wp_filemanager.php, which averaged about 20 sources a week, dropped away to almost none, down 79%. It is too early to say whether scanners have moved on. Cloud key files such as /service-account.json held roughly steady at 70 sources.
What to do
- Check your WordPress version. If it falls in 6.9.0 to 6.9.4 or 7.0.0 to 7.0.1, update to 6.9.5 or 7.0.2 now.
- Keep .env files out of the public folder entirely, including old releases and versioned subfolders. One level above the web root is the safe place.
- Delete backups and dumps such as
/database.sqlor/wp-config.php.bakfrom anything a browser can reach. - Lock down internals. Restrict Spring Boot actuator endpoints and leave env masking on, remove phpinfo test pages, and keep the Yii debugger limited to localhost.
- Turn off XML-RPC if nothing on your site needs it.
About these observations
This report is produced by 291 Heat Seeker One, 291 Group's security monitoring system, running on 291 Crossband, our proprietary security operations platform. It covers only traffic to 291 Group's own internet-facing infrastructure.
Figures are rounded, shares and changes are measured by the number of separate sources rather than requests, and only patterns seen from at least 20 separate sources are included. Countries are where the sources' servers are, not necessarily where the people running them are. Kinds of network come from who operates each network; only large, well-known providers are ever named.