WordPress 7.0 Upgrade Checklist: 12 Security Steps First

WordPress 7.0 shipped on May 20, 2026. It brings the WP AI Client into core, raises the PHP floor, lands real-time collaborative editing, and ships responsive block visibility controls. Major version upgrades are opt-in, so most sites won't auto-update. The window before you click Update is your last chance to catch the issues that a bad upgrade can bake in for months.

This is the 12-step pre-upgrade audit we run on every site we manage. It takes about 90 minutes for a single site, faster if you have automation in place. Run all 12 before you upgrade anything you care about. If you'd rather skip the manual work, our free scanner covers steps 1, 3, 6, and 11 in under 30 seconds.

Why a Pre-Upgrade Audit Matters

WordPress 7.0 doesn't break a lot of plugins on its own. What it does is expose every existing issue under a new platform version. A plugin that was already silently broken under 6.9 will keep working until 7.0 changes a hook signature and now the silent break is a fatal error. A configuration that was insecure under 6.9 stays insecure under 7.0, but the new AI client surface raises the value of what an attacker can steal.

Then there's the WP AI Client itself. It's a new surface in core. The first key-exposure bug landed three days after release, filed by Patchstack's Oliver Sild. The class of bugs is going to keep coming.

Get the 12-step audit done first. Then upgrade.

Step 1: Take a Full Backup

A backup that lives on the same server as the site is not a backup. A backup that's never been tested is not a backup. A backup you can't restore in under an hour during an outage is not a backup.

Before any major version upgrade:

Snapshot the database with wp db export or your host's snapshot tool
Copy the entire site filesystem (including wp-content/uploads/)
Move both to off-site storage (S3, B2, a different host)
Verify the backup by restoring it to a staging environment

If you can't complete that last step in under an hour, treat your backup as broken and fix that before anything else. The signs your WordPress site has been hacked writeup covers what to do when restoring becomes the recovery plan.

Step 2: Confirm PHP Version Is 8.3 or Later

WordPress 7.0 recommends PHP 8.3 or later. The minimum is PHP 7.4, but running anything below 8.1 in 2026 is a security and performance problem. PHP 7.x is end-of-life for security patches.

Check your current PHP version:

Via WP Admin: Tools > Site Health > Info > Server
Via WP-CLI: wp eval 'echo PHP_VERSION;'
Via your hosting control panel (cPanel, Cloudways, WP Engine, etc.)

If you're on 7.2 or 7.3, your host should support PHP 8.x by now. If they don't, that's a hosting problem, not an upgrade-WordPress problem. Move hosts before you upgrade core.

Step 3: Inventory Every Plugin Against Known Vulnerabilities

Pull a list of every active and inactive plugin. For each one:

Check the plugin page on WordPress.org for "Tested up to" version
Cross-reference against the Patchstack and Wordfence vulnerability databases for any disclosure in the last 12 months
Check the last-updated date. Plugins not updated in 12 months are abandonware risks regardless of CVE history

The WordPress.org plugin listing now shows "Tested up to: 7.0" markers for plugins the maintainer has verified. Treat anything missing that marker as untested and run it through a staging environment first.

Our WP Vanguard scanner automates this step against a constantly-updated database of 38,000+ CVEs.

Step 4: Audit the WP AI Client Surface

If you've installed any plugin that registers an AI provider through the new WP AI Client, document:

Which providers (Anthropic, OpenAI, Gemini, others) are configured
Where each API key is stored (option, post meta, custom table, environment)
Which user roles can read or modify the AI settings
What the per-key spend limit is at the provider dashboard

If you can't answer any of those, you have a key-management gap. Fix it before you upgrade, because 7.0 is the version that's going to attract more AI-plugin installs. The risk concentration grows from here.

The WP 7.0 AI key attack surface writeup has the full background on why this matters.

Step 5: Check the REST API Index for Leakage

Open https://yoursite.com/wp-json/ in an unauthenticated browser session and search for tokens, keys, and bearer secrets. Long random-looking strings in URL patterns are almost always bearer tokens.

This is the exact pattern that exposed the AI Engine MCP token in CVE-2025-11749. It's a one-line check and it catches a class of bugs that automated scanners miss when their signature databases lag. Our step-by-step API key audit covers exactly what to search for.

Step 6: Verify Exposed-File Defenses

Before any major upgrade, confirm these URLs return 403 or 404 on your site:

/.env
/wp-config.php.bak, /wp-config.old, /wp-config~
/.git/config
/backup.sql, /dump.sql, /site.sql
/.DS_Store

If any of them return file contents, your hosting configuration is leaking. Fix that before you upgrade, because the upgrade itself can create new backup files at predictable paths that an attacker may already know to check.

Step 7: Test On Staging First

A staging environment is a copy of production that you can break without consequences. Every host worth using offers one-click staging in 2026: WP Engine, Kinsta, SiteGround, Cloudways, Pressable, and most managed hosts.

The pre-upgrade test:

Spin up staging
Run the WP 7.0 upgrade on staging
Walk through your critical user flows (login, checkout, key admin tasks)
Check /wp-admin for warning notices or PHP errors
Tail the error log for new PHP fatals
Only then promote the upgrade to production

If your host doesn't support staging, install a plugin like WP Staging or move to a host that does. This is non-negotiable for any site that earns revenue.

Step 8: Lock Down Admin Access Before Upgrading

Major upgrades attract attention. Vulnerability researchers test the new version against existing plugins on day one. Attackers watch the same disclosures and probe sites that look like they haven't patched. Before you upgrade:

Enforce 2FA on every administrator account
Audit application passwords (/wp-admin/profile.php) and revoke anything you don't actively use
Check for unfamiliar admin accounts. Run wp user list --role=administrator --format=csv
Audit recent logins via your security plugin's activity log

The WordPress security checklist covers the broader admin-hardening playbook.

Step 9: Confirm Backups for the Database Schema Changes

WordPress 7.0 makes a handful of schema changes. Most of them are additive (new columns, new tables) and reversible. But "additive and reversible in theory" is different from "actually rolled back successfully when production was on fire."

Before upgrading:

Note your current wp_db_version value
Document the rollback procedure your backup tool supports
Have the database backup from step 1 in a place you can restore from without depending on the live database

If anything goes wrong during the upgrade, the database is the part you can't recreate.

Step 10: Disable Cache and CDN During the Upgrade

Page caches and edge caches can serve stale content for hours after an upgrade. If something breaks during the upgrade, a stale cache layer can mask the break long enough that admins don't notice until customers do.

Before upgrading:

Disable any page-cache plugin (W3 Total Cache, WP Rocket, LiteSpeed)
Purge your CDN (Cloudflare, BunnyCDN, Fastly)
Disable object cache (Redis, Memcached) at least briefly
After the upgrade verifies clean, re-enable each layer one at a time

Step 11: Run a Pre-Upgrade Security Scan

The point of running a scan before the upgrade is to establish a baseline. After the upgrade, you'll want to compare. A clean scan beforehand means any new findings after are upgrade-related.

WP Vanguard's surface scan takes under 30 seconds and produces a health score. Deep scan (with SSH) takes a few minutes and covers 20 additional checks. Run one or both, save the report, then upgrade.

Step 12: Plan the Post-Upgrade Verification

The upgrade is "done" when:

The site loads without errors
WP Admin shows no warning notices
Your critical user flows work
A fresh security scan matches or exceeds your pre-upgrade baseline
The error log shows no new PHP fatals

If any of those fail, roll back to your step-1 backup, document what broke, and revisit. Do not leave a half-finished upgrade in production.

When to Bring In Help

Some upgrades are routine. Some are not. If your site:

Earns more than a few hundred dollars a day
Holds customer PII or payment data
Runs custom plugins, child themes, or bespoke integrations
Is part of a multisite network
Has been on the same WordPress version for more than 18 months

Then a human review on top of the automated checks is worth the budget. Wbcom Designs' WordPress Code Audit covers the architecture, performance, and security review that an automated scanner can't catch. It's run by the same team that built WP Vanguard, so the scanner output feeds straight into the audit findings.

For sites with ongoing maintenance needs, WordPress Maintenance bundles the monthly upgrades, monitoring, and incident response into a retainer.

The 12 Steps, Summarized

Full backup, off-site, tested
PHP 8.3 or later
Plugin vulnerability inventory
WP AI Client surface documented
REST API index checked for leaks
Exposed-file defenses verified
Staging environment test pass
Admin access locked down
Database schema rollback plan
Cache and CDN disabled during upgrade
Pre-upgrade security scan baseline
Post-upgrade verification plan

Print this, work through it once, automate the parts you can. The first time you do it on a site takes 90 minutes. The next time takes 30. The time you skip it is the time you wish you hadn't.

Scan your site before you upgrade. WP Vanguard's free surface scan establishes a security baseline in under 30 seconds. Re-scan after the upgrade to confirm nothing regressed.

Need help running the upgrade? Wbcom Designs' WordPress Maintenance and Code Audit services handle the upgrade, the pre-flight checks, and the rollback plan for sites where downtime isn't an option.