Critical WordPress vulnerabilities: what to check right now

What happened and who is affected

Cloudflare announced new WAF protections for two severe WordPress issues: one SQL injection flaw and one unauthenticated remote code execution flaw. Based on the published details, the SQL issue affects versions from 6.8 onward, while the code execution issue affects versions from 6.9 onward under specific conditions. WordPress released fixes in 7.0.2, with backports in 6.9.5 and 6.8.6. If your site runs behind Cloudflare, the WAF can lower exposure while you patch, but it does not remove the vulnerable code.

For MioriticHost customers managing sites in cPanel, Plesk, or a WordPress management panel, the practical takeaway is simple: do not rely on WAF alone. Check the WordPress version immediately, confirm whether core auto-update has already run, and prepare a quick validation after patching.

Short checklist for admins

• Check in WordPress Admin whether the site is running 7.0.2, 6.9.5, or 6.8.6, depending on your branch.
• Confirm the date of the last update and whether the core auto-update completed successfully.
• Create an immediate backup of both files and database before any manual action.
• If you use Cloudflare, verify that traffic is proxied and that WAF rules were not changed from Block to Log by a ruleset override.
• After the update, test wp-admin login, contact forms, search, checkout, and any REST endpoints used by plugins.
• Review web logs and error logs for unusual REST API requests, especially if you notice traffic spikes or new 403 and 500 responses.

Operational hosting advice we recommend

If the site did not auto-update, apply the patch manually from WordPress Admin during a lower-traffic window. Before that, save a full backup and note your current PHP version, caching plugins, and any custom Apache, Nginx, or .htaccess rules. One practical recommendation is to clear both application cache and CDN cache after the update, otherwise you may be testing stale pages and miss real issues.

A second concrete step is to verify whether you use persistent object caching and how it is configured. The published critical issue explicitly mentions the absence of such a cache in some scenarios, so it is worth knowing whether Redis or Memcached is active, who manages it, and whether the integration plugin is working correctly. Also check uptime after the update, send a test email from site forms, and confirm that your scheduled hosting backup still runs normally on the next cycle.