WordPress SQL injection and RCE

What it means for your AI agents

Agents often read from and write to applications like this one: content, tickets and documents. A compromised instance can feed instructions to an agent through the content it reads, as well as expose the data itself.

• Find which agents have tools that read from or write to the affected application.
• Treat content from an unpatched instance as untrusted, the way you would a web page.
• Check the accounts and API tokens your agents use there for changes you didn't make.

Details

CVE-2026-60137 is a SQL-injection issue and CVE-2026-63030 is an unauthenticated code-execution issue associated with a REST API attack path. Their affected versions and conditions differ.

Managed WAF rules can mitigate known requests, but do not repair WordPress installations or replace vendor updates.

Risk

Affected sites can be compromised before sign-in. The July 20 review did not confirm active exploitation.

Affected deployments

WordPress sites running a release affected by either CVE. Check the security release for each flaw's version and configuration requirements.

Recommended action

Check each site's WordPress version and apply the vendor's update or backport guidance. Keep compensating controls in place during remediation.

1. 1Identify WordPress sites and compare their versions with the WordPress security release. WordPress security release
2. 2Apply the vendor update or backport guidance for each affected deployment.
3. 3Confirm that Internet-facing WordPress traffic follows the intended security controls during remediation.

Check your exposure with an agent

Paste this into an AI agent that can see your infrastructure. It asks for a read-only check of what's affected, including the systems behind your agents, and a table you can act on. Copying it changes nothing.

Assess whether the infrastructure you can access is affected by WordPress SQL injection and RCE (CVE-2026-60137 and CVE-2026-63030). Work read-only within your authorized access: do not run exploits, change configuration, restart services or install anything.

1. Confirm the affected and fixed versions from the vendor advisories and CVE records:
   - https://wordpress.org/news/2026/07/wordpress-7-0-2-release/
   - https://www.cve.org/CVERecord?id=CVE-2026-60137
   - https://www.cve.org/CVERecord?id=CVE-2026-63030
   Cite each source and the date you read it. Say plainly what you could not verify.

2. Inventory the systems that could run the affected software, including the hosts, containers, MCP servers, tool runners and sandboxes behind any AI agents. For each, record the asset, environment, owner if known and the version actually running, from read-only evidence (package metadata, version commands, platform inventory).

3. Note which affected systems are reachable from the internet or from agents and tools, and which credentials (model-provider keys, tool tokens, service accounts) are stored on them.

4. Report one row per asset: asset, running version, affected (yes / no / unknown), reachable from, credentials at risk, evidence, and the next step. List anything you could not access as a gap rather than assuming it is safe.