This was not a routine maintenance update

WordPress 7.0.2 was released on July 17, 2026 as a security release addressing one critical and one high-severity issue. The project also shipped fixes for affected supported branches. Because of the severity, automatic updates were forced for affected installations where the update mechanism could run. That is a strong signal that site owners should verify the installed version rather than assuming the update happened.

The vulnerabilities reached sensitive parts of WordPress

The release addressed SQL-injection-related issues, including a REST API batch-route problem that could lead to remote code execution. CISA subsequently added the relevant vulnerabilities to its Known Exploited Vulnerabilities catalog after evidence of exploitation. Once a vulnerability is public and exploitation exists, the useful window for delaying a security update becomes very small.

Patching is necessary, but verification matters too

An automatic update can fail because of filesystem permissions, disabled background updates, unusual deployment practices or an already unhealthy installation. After a high-priority security release, administrators should check the actual WordPress version, confirm that the site still operates correctly and review security monitoring for suspicious activity that may have occurred before patching.

A repeatable update process reduces the trade-off

Businesses sometimes postpone updates because they fear compatibility problems. The better answer is not indefinite delay but a process: current backups, staging for complex sites, known plugin and theme ownership, and a quick functional test after deployment. Security updates become much easier to apply promptly when the site is already maintained in a predictable way.