InfiniteWP CVE-2026-15038: unauthenticated takeover of an entire Multisite network

CVE-2026-15038, affecting the InfiniteWP Client plugin for WordPress, was published on 9 August 2026. In Multisite installations, releases before 1.13.6 did not properly verify the site-connection state and authenticity of requests to the remote-management endpoint. An unauthenticated attacker could bind their own key, hijack an administrator session and take control of the entire site network, ultimately enabling remote code execution.

Scale requires precision. The official WordPress directory reports approximately 200,000 active installations of InfiniteWP Client, but the CVE specifically describes WordPress Multisite configurations. It does not mean all active installations are vulnerable or compromised. It does mean organisations running Multisite should immediately establish their version and connection history.

What version 1.13.6 fixes

CVE-2026-15038 was published by the WPScan CNA at 06:00 UTC on 9 August. Every release before 1.13.6 is in the affected range, with other versions defaulting to unaffected. Version 1.13.6 reached the directory on 21 July; the vendor changelog describes the change as an improvement to the add-site mechanism for Multisite.

That distinction between fix date and public CVE date matters. An administrator may have received a safe release earlier without yet knowing that the change closed a takeover path. Continuous inventory therefore provides more value than tracking headlines alone: it can establish whether the update was deployed before public disclosure.

The WPScan advisory identifies three material stages of impact:

1. the remote-management endpoint does not adequately confirm the connection workflow state and request authenticity;
2. an attacker can bind a key under their control to the site;
3. that trust enables network-administrator session hijacking, and WordPress administrative authority can lead to code execution through component installation or modification.

The public description does not provide the complete request sequence or every resulting log artefact. Defenders should not fill those gaps with speculation or base detection on a single unconfirmed parameter.

Why a connection-workflow flaw is an identity flaw

Remote WordPress management must solve a trust-bootstrap problem: how does a client know that the first console attempting to add it is the correct console? If an endpoint treats “not yet connected” as permission to establish a new relationship without a strong one-time proof, application state replaces authentication.

A secure flow should combine a short-lived challenge, administrator intent expressed in a trusted session, cryptographic verification of the response and unambiguous binding to a site identity. The request must fail after the challenge is used, after expiry and if its context changes. The absence of an existing console must never authorise an external sender to assign one.

The consequence is greater in Multisite than on an individual blog. A network administrator can manage multiple sites, users and plugins. Compromise of one remote-management relationship becomes compromise of the platform boundary.

Who should act first

Environments meeting several conditions at once have the highest priority: WordPress Multisite, InfiniteWP Client before 1.13.6, a publicly reachable endpoint and highly privileged network-administrator accounts. Shared hosts, agencies maintaining multiple sites and franchise platforms should determine whether one installation serves many brands or domains.

Inventory should also include inactive copies, staging and old container images. Disabling a plugin in the panel does not necessarily remove its files, data or evidence of an earlier connection. A backup restored after an incident could reintroduce a vulnerable release.

Response plan

1. Update InfiniteWP Client to 1.13.6 or a later release from the official channel.
2. Confirm the update across every site in the network and every recovery image, not only the main site.
3. Verify which InfiniteWP console and keys are currently bound to the installation.
4. End active network-administrator sessions and require fresh authentication where prior exposure is suspected.
5. Review administrator accounts, plugins, themes, MU-plugins, scheduled tasks and files changed since the last known-good state.
6. Search web-server and WAF logs for InfiniteWP endpoints, focusing on connection attempts before the update and unusual sources.
7. If a foreign key or hijacked session is found, rotate WordPress, database, hosting and integration secrets reachable from the application.

Updating closes the known path but does not remove code or accounts left by an attacker. A confirmed exposed environment requires investigation across the application, file server, database and hosting control panel.

Confirming version and scope in Multisite

In a large network, reading the central update screen is not sufficient. Check the plugin file in the active directory, host inventory and the version WordPress sees after opcode caches are cleared. Where deployment uses multiple web nodes, every node must run the same artifact. An old pod, replica or autoscaled recovery server may still answer a request to the vulnerable endpoint.

Build a map containing network identifier, domains, application nodes, InfiniteWP Client version, bound console and business owner. Record the first 1.13.6 deployment time and evidence that every replica received it. The answer to “were we vulnerable after public disclosure?” should not depend on a current state that may already have changed.

Separate three forms of scope. Technical scope identifies the sites and components a network administrator can alter. Data scope describes databases, files, forms and backups reachable from WordPress. Identity scope covers SSO sessions, API keys and service accounts. Panel takeover does not automatically prove exfiltration of every dataset, but these maps define what an attacker could have reached and which logs require review.

Resuming remote management safely

If response work disconnects the client from the InfiniteWP console, treat reconnection as a privileged trust change. An administrator should initiate it from a clean, strongly authenticated workstation, verify the target network identity and record the exact time. A second person can approve the console identifier or key fingerprint where the organisation’s process permits.

After connection, perform a controlled low-risk operation and verify it in logs on both sides. Confirm the console cannot see tenants the operator should not manage and that the client rejects another bootstrap attempt. Then alert on relationship changes so future key binding cannot remain a silent configuration event.

Do not restore the old relationship merely by importing the entire database or plugin-directory backup. A backup may contain a vulnerable release, previous key or state that reopens the add-site workflow. Recovery should separate business content from secrets and trust configuration, then re-establish the latter only after integrity has been verified.

Monitoring for takeover attempts

Build a timeline from HTTP logs, WordPress authentication records, option changes, plugin installations and administrator activity. New management relationships, operations without a normal control-panel session and component changes shortly after requests to the InfiniteWP endpoint deserve particular attention.

An alert should use correlation rather than one IP address. A legitimate console can change address, and an attacker can use ordinary cloud infrastructure. The strongest signal is the creation or alteration of a remote-management relationship without corresponding administrator activity and an approved change window.

Facts versus Breachroad conclusions

The sources establish an affected range before 1.13.6, a description limited to Multisite, attacker-controlled key binding, administrator-session takeover and impact leading to RCE. The WordPress directory confirms around 200,000 active installations of the plugin—not 200,000 vulnerable Multisite networks. The public record does not confirm a mass exploitation campaign.

Breachroad’s conclusion is that first-time connection must be tested as a critical identity protocol, not a convenience setting. Training for administrators and web teams helps teams respond correctly when a fix predates its CVE, while web and API penetration testing can examine trust bootstrap, endpoint authorisation and the real reach of administrative accounts.