Summary
- CERT-FR has warned of WordPress Core flaws involving SQL injection and a security policy bypass.
- The agency says the flaws can be chained for unauthenticated remote code execution in affected WordPress versions.
- Public-facing CMS exposure remains a persistent enterprise, public sector, and supplier-risk problem.
CERT-FR has warned that two WordPress Core vulnerabilities could be chained to achieve unauthenticated remote code execution in affected versions, with public proof-of-concept material increasing the likelihood of mass exploitation attempts.
The French government cyber response agency’s 20 July alert covers CVE-2026-60137, an SQL injection vulnerability, and CVE-2026-63030, a security policy bypass. WordPress published fixes on 17 July, and CERT-FR says combined exploitation can allow remote arbitrary code execution in affected WordPress Core versions.
Affected systems include WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, 7.1.x before 7.1 beta2, and 7.x before 7.0.2. CERT-FR recommends applying fixes quickly. Where patching cannot be completed immediately, it points to researcher-recommended filtering that blocks unauthenticated access to the WordPress REST API path used in the exploit chain.
WordPress vulnerability coverage often slips into small-business web hygiene. In practice, the platform sits across enterprise and public sector estates in campaign sites, investor pages, recruitment portals, knowledge bases, policy microsites, marketing systems, and supplier-hosted web properties. These systems may not run core operations, but compromise can still support malware hosting, credential collection, visitor redirection, reputational damage, and attacks against staff or customers.
Public proof-of-concept material changes response speed. A widely deployed platform with an unauthenticated exploit path is likely to attract automated scanning, opportunistic compromise, and attempts against forgotten sites. Managed hosting may reduce exposure for some organisations, but fragmented ownership remains common. A marketing team may own the site, an agency may manage the build, a hosting provider may control patching, and central security may not hold a complete asset record.
Those ownership gaps turn a CMS vulnerability into a governance problem. Emergency patching depends on knowing who can apply updates, whether the site is monitored, whether backups are clean, and whether incident notification duties sit with the organisation or a supplier. Contracts that do not specify update windows, logs, vulnerability handling, and incident cooperation leave room for delay when a mass exploitation wave begins.
The regulatory connection is indirect but relevant. Public-facing web assets may hold personal data, publish official information, or provide customer and citizen access routes. Under European and UK resilience expectations, organisations need to manage risk across digital services, not only the systems formally labelled critical.
Response work should include asset discovery, version checks, patch confirmation, REST API exposure review, web application firewall rules where needed, backup validation, and inspection for unauthorised changes. Where agencies or hosting providers are involved, customers should obtain evidence rather than verbal assurance.
CERT-FR’s warning returns attention to a familiar but persistent exposure: public-facing software that is widely deployed, unevenly owned, and attractive to automated attackers. The difference between a contained update and a large incident will depend on asset knowledge and supplier responsiveness as much as the patch itself.
