WordPress 7.0.2 is a security release published on July 17, 2026. For site owners, the relevant question is not simply whether an update was initiated. You need to know which corrected version is actually installed and whether the website’s business-critical functions still work as expected.
Which WordPress versions are affected?
The required version depends on the release branch the site was running:
- WordPress versions before 6.8 are not affected.
- WordPress 6.8 is affected only by the first of the two corrected issues. WordPress 6.8.6 contains the fix.
- WordPress 6.9 requires version 6.9.5, which corrects both issues.
- WordPress 7.0.x requires version 7.0.2, which also corrects both issues.
Forced automatic updates were enabled for affected versions. This shortened the time to installation, but it does not replace verification that the appropriate corrected version reached the specific site.
The official WordPress 7.0.2 release announcement lists the corrected release branches. On July 21, 2026, CISA also added the relevant vulnerabilities to its Known Exploited Vulnerabilities Catalog, as documented in its official alert.
How to prove which version is installed
Check the version number inside WordPress and, where possible, confirm it through the hosting or site-management platform as well. A useful record should identify the site, the time of the check and the version found.
- A site on the WordPress 6.8 branch must be running at least version 6.8.6.
- A site on the WordPress 6.9 branch must be running at least version 6.9.5.
- A site on the WordPress 7.0 branch must be running at least version 7.0.2.
- An update request or automatic-update email does not, by itself, prove the result.
Check that the update completed cleanly. A site left in maintenance mode, a pending database update or errors in the administration area all warrant closer inspection.
Which site functions should be tested after the update?
A correct version number does not show whether forms, logins and connected workflows still operate properly. Test the paths that generate enquiries, bookings or revenue.
- Submit every important contact, enquiry and application form using realistic test data. Confirm the on-screen response, message delivery and stored entry.
- Test login, password reset and the user roles that matter. A successful administrator login is not enough.
- For online stores, complete a test purchase through to the order confirmation. For booking systems, verify selection, availability, confirmation and notifications.
- Check handoffs to the CRM, helpdesk, newsletter platform or other connected services. Compare the transmitted fields and confirm that the record reached its destination.
Record when each test was performed and what happened. If a problem appears later, this helps establish whether it existed immediately after the update or arose afterwards.
How to assess possible signs of compromise
The update closes the known vulnerabilities in the relevant release branch. It does not establish whether someone accessed or changed the site before the update was installed.
Unknown administrator accounts, unexplained changes to content or settings, newly appearing extensions, unusual redirects, and suspicious login or server-log activity justify technical review. The same applies if forms suddenly send to different recipients or integrations transmit unexpected data without a planned change.
These observations are triage indicators, not forensic proof. They may have harmless explanations, while an uneventful spot check cannot conclusively rule out earlier access. Document and contain suspicious changes before cleaning up files, logs or accounts that may be relevant to a deeper investigation.
What evidence should you have at the end?
- The installed, corrected WordPress version for the site’s release branch
- A documented successful test of the site’s business-critical functions
- A confirmed test of data handoffs to connected systems
- An assessed list of unexplained changes or anomalies
This does not prove that the site was never affected. It does provide a clear basis for the next decision and shows where deeper investigation may be required.
Missing any of this evidence? With the DKSIGN WordPress Security Check, we verify the installed version, critical website functions and unusual changes, then provide a prioritised list of next steps.