The OpenSSL Search That Misses CVE-2026-60137

The ticket says, “Find every service affected by the critical OpenSSL CVE.” Three hours later, someone notices the CVE in the ticket is not an OpenSSL vulnerability at all. It is in WordPress Core.

That is not a pedantic correction. It changes what you search, who owns the affected systems, and where the vulnerable software is hiding.

CVE-2026-60137 is a WordPress Core SQL injection vulnerability. When a plugin or theme passes untrusted input to the affected parameter, an attacker can manipulate the resulting database query. It can also be chained with CVE-2026-63030 to give an unauthenticated attacker remote code execution on default WordPress installations.

CISA added CVE-2026-60137 to its Known Exploited Vulnerabilities catalog on 21 July 2026. The catalog records known ransomware use. This is no longer a theoretical exposure or an interesting scanner finding waiting for the next patch window. Attackers are using it.

Product names are a bad inventory strategy

Searching package databases for openssl is useful when OpenSSL is actually affected. It will tell you nothing about an old WordPress container behind a marketing hostname, a managed site owned by an agency, or a VM that stopped reporting to the vulnerability scanner six months ago.

The pattern shows up repeatedly during assessments. The asset register contains servers. The vulnerable thing is a service. A single server may host twelve WordPress sites, each with a different owner, update policy, plugin set, and internet exposure.

For CVE-2026-60137, the people at risk are organisations running affected WordPress Core releases, particularly where a plugin or theme can pass attacker-controlled input into the vulnerable parameter. Internet-facing sites deserve immediate attention. Internal sites still count, especially if contractors, partners, or compromised endpoints can reach them.

According to the WordPress 7.0.2 security release, the fixed branches are:

• WordPress 7.0.2
• WordPress 6.9.5
• WordPress 6.8.6
• WordPress 7.1 beta 2

Versions before 6.8 are not affected. WordPress 6.8 is affected by CVE-2026-60137 but not the second vulnerability in the chain. WordPress 6.9 is affected by both. Do not translate that into “6.8 is safe.” SQL injection is quite enough trouble on its own.

Start from the front door, then work backwards

Begin with everything that can answer an HTTP request, not everything labelled WordPress. Export public DNS zones, load balancer listeners, CDN origins, Kubernetes Ingress objects, cloud application gateways, reverse proxy configuration, and hosting-provider accounts. Include retired domains that still resolve. They have an unfortunate habit of remaining alive.

Probe only assets you own or are authorised to test. A first pass with ProjectDiscovery httpx can identify likely web applications:

httpx -l authorised-hosts.txt \
 -status-code -title -tech-detect \
 -follow-redirects -json -o web-inventory.json

Technology detection is a lead, not proof. WordPress fingerprints can be removed, cached by a CDN, or hidden behind a generic error page. Correlate the results with DNS targets, TLS certificates, cloud tags, web server virtual hosts, and deployment records.

In Kubernetes, find the routes first and then map them to services and workloads:

kubectl get ingress -A -o wide
kubectl get service -A -o wide
kubectl get deploy,statefulset -A \
 -o custom-columns='KIND:.kind,NS:.metadata.namespace,NAME:.metadata.name,IMAGES:.spec.template.spec.containers[*].image'

Do the same for ECS task definitions, Azure App Service, traditional virtual machines, shared hosting, and whatever sits in the corner because “the agency manages it.” Managed does not mean patched. It means you need evidence from another control plane.

Get the version from the installation

Once a service is mapped to a workload, obtain the WordPress Core version from the running installation. With WP-CLI available:

wp core version --path=/var/www/html
wp core verify-checksums --path=/var/www/html

The checksum command matters because version alone does not tell you whether core files were modified. For containerised deployments, record both the image digest and the runtime version. Tags such as latest and wordpress:7 are not patch evidence.

Search hosts where WordPress was installed manually or copied between document roots:

find /var/www /srv/www -type f \
 -path '*/wp-includes/version.php' -print 2>/dev/null

Your working record should join the hostname, public or internal exposure, owner, hosting location, Core version, image digest or filesystem path, plugin and theme inventory, patch status, and evidence timestamp. Without that join, patch management becomes a collection of screenshots and hopeful messages.

Patching closes the hole, not the incident

Update affected sites to the vendor-fixed release for their supported branch. WordPress recommends immediate updates and enabled forced automatic updates for affected installations. Still verify the installed version yourself. Automatic updates fail because of filesystem permissions, disabled cron, custom deployment pipelines, immutable images, and maintenance settings.

If a vendor mitigation is required before an update can be deployed, apply it exactly as documented and record where it was applied. A generic web application firewall SQL injection rule may reduce some traffic, but it is not a substitute for the Core fix. Attackers test variations. So should your defensive validation.

CISA’s required remediation calls for vendor mitigations, evaluation of each asset’s internet exposure, compliance with BOD 26-04 risk-based patching guidance, and its Forensics Triage Requirements. If mitigations are unavailable, the product must be discontinued where the directive applies. The wider lesson is sensible outside government too: a vulnerability in the CISA KEV catalog gets priority because exploitation has been observed, not because its score makes a dashboard turn red.

Assume an exposed site may have been touched

A clean update does not remove an attacker who already obtained code execution. Preserve evidence before making destructive changes. Collect web server, CDN, WAF, authentication, database, and hosting control-plane logs. Snapshot disks or volumes where appropriate, and record timestamps and hashes.

Hunt for unexpected administrator accounts, modified Core files, unfamiliar plugins or must-use plugins, PHP files under upload directories, altered scheduled tasks, changed web server configuration, and outbound connections that do not fit the application. Review REST API requests, authentication events, database errors, and file changes around the period of exposure.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --status=active
wp cron event list
wp core verify-checksums
find wp-content/uploads -type f -name '*.php' -print

None of those checks can certify that a site is clean. They are triage. A positive finding, missing logs, or unexplained file modification should move the system into incident response, with credential rotation and investigation scoped beyond WordPress. Remote code execution can expose database credentials, API keys, cloud metadata, and neighbouring systems, depending on the permissions granted to the workload.

That is where offensive testing and defensive work meet. Pen-testing helps establish which routes and trust boundaries are reachable. Threat detection and incident response determine whether somebody crossed them. Hardening reduces what the web process can do next.

If you only do one thing this week

Build one verified table that maps every reachable hostname to its running WordPress Core version and owner. Do not accept “auto-updates are enabled” as the version.

CVE response usually fails in the gap between a public service and the team that thinks somebody else owns it. Close that gap first. Then patch, verify, and hunt.

If this is on your plate, TecLeads does exactly this as part of our Cybersecurity work. If you'd like a second pair of eyes on your setup, book a 30-minute call or explore what we do.