WordPress 7.1.1 Security Update: 9 Checks After You Patch

WordPress 7.1.1 arrived on 17 September 2026 as a maintenance and security release. The official announcement lists 11 security fixes, 17 core bug fixes and 19 Block Editor fixes, and WordPress recommends updating immediately.

Start by checking whether your site already received the automatic background update. If it did not, take a restorable backup and apply 7.1.1 now. Then work through the checks below.

The reason the checks matter is simple. A patch closes a vulnerability going forward. It does nothing about what happened while the hole was open, and a "successful update" message only proves that files changed. It does not prove that your enquiry form still delivers, that your checkout still completes, or that nobody used the old vulnerability before you closed it.

Do not delay a security patch because a redesign or plugin cleanup is unfinished.

What WordPress 7.1.1 fixes

The security fixes cover stored cross-site scripting, authorization and permission checks, path traversal in the REST Templates Controller, and disclosure of information relating to private or unpublished content.

You do not need to understand an exploit to decide whether the release matters. WordPress has labelled 7.1.1 a security release and advised immediate updating. If a provider manages core updates for you, confirm the installed version rather than assuming the job is done.

Version 7.1.1 also sits on top of WordPress 7.1, which introduced responsive block styles, a revised media workflow and client-side media processing. If you are coming from an older core version, those changes are the ones most likely to affect how your site looks and how your editors work.

How much process the update needs

Every supported site should move to 7.1.1 promptly. What varies is the testing around it, not whether you patch.

If the site is several major versions behind, the WordPress upgrade handbook recommends verified database and file backups and an incremental path across major releases. An older installation may also need PHP, database, theme or plugin work before core can be updated safely.

Nine checks after applying WordPress 7.1.1

1. Confirm the version and record the change

Open Dashboard → Updates and verify the site reports WordPress 7.1.1. Cross-check under Tools → Site Health → Info → WordPress for the exact version string. If your host manages updates, check their update history too.

Record the time, who or what applied the update, the previous version, and anything else that changed in the same window. Avoid bundling unrelated changes into a security patch. If core, the theme, ten plugins and custom code all move together, diagnosing a regression becomes guesswork.

2. Verify the backup can actually be restored

The WordPress handbook says to back up both the database and all files, and to verify the backups are usable. A green "backup complete" label is not a tested recovery path.

Check the timestamp, the storage location and the restore instructions, and confirm who can restore outside business hours. For a store or membership site, rehearse a restore on an isolated environment. Keep backups somewhere other than the server they came from, with at least 30 days of history.

3. Verify core file integrity and scan for compromise

This is the check most teams skip, and on a security release it is the one that matters most. WordPress publishes a checksum for every file in every release. If a file on your server does not match, it was modified after install.

With WP-CLI:

wp core verify-checksums

Wordfence, Sucuri and MalCare run the same comparison plus a full malware scan covering the uploads directory for PHP files that should not be there, the database for injected scripts, cron events for unfamiliar jobs, and .htaccess for redirect rules. Run the scan after patching so the results reflect your current state.

Investigate anything flagged rather than overwriting it. If the entry point is still open, the same file returns.

4. Test templates, layouts and responsive behaviour

Review the homepage, a standard page, a post, search, a 404 and any custom templates, at desktop, tablet and phone widths. Look for missing CSS, shifted headers, broken menus, blank blocks and banners covering controls.

This matters more if you are landing on 7.1 at the same time, since it expanded responsive block styling and interactive states. Existing themes, custom blocks and page builders still need visual verification.

5. Complete the most valuable customer journey

Do not stop at "the homepage loads." Follow the path that produces revenue from beginning to end:

• Submit each important enquiry form and confirm the message reaches the correct inbox or CRM.
• Complete a test purchase using an approved payment sandbox where possible.
• Make and cancel a test appointment if the site handles bookings.
• Register, sign in, reset a password and reach protected content on a membership site.
• Test coupon, shipping, tax and confirmation email behaviour on a store.

Use non-production customer details and remove test records afterwards. If a live transaction is necessary, agree the amount and refund process first.

6. Audit users, roles and private content

Several 7.1.1 fixes concern authorization and information exposure, which makes this a good moment to test permissions deliberately rather than assume them.

Open Users → All Users and sort by role. Look for administrator accounts you do not recognise, registrations on dates when nobody should have signed up, and former contractors who still have access. Delete what should not be there and reassign their content. Drop anyone who does not need administrator down to editor or author.

Then sign in with representative administrator, editor, contributor, subscriber and customer accounts and confirm each sees and changes only what it should. Test drafts, private posts, media, template editing and multisite functions where relevant.

Finally, rotate your authentication keys and salts. WordPress stores eight of them in wp-config.php, and they sign the cookies that keep users logged in. Generating a fresh set at api.wordpress.org/secret-key/1.1/salt/ invalidates every active session, which removes anyone holding a stolen session cookie even after a password change. Everyone has to log back in, and that is the point. Pair it with two-factor authentication on all administrator accounts.

7. Review the Block Editor and media workflow

Create a private test draft. Add and rearrange the blocks your team actually uses, preview, save and reopen. If the site relies on custom or third-party blocks, test their inspector controls and their front-end rendering separately.

Upload a permission-cleared test image, crop it, and check the generated sizes. WordPress 7.1 introduced client-side media processing and a redesigned media editing workflow, so this is a sensible regression test when upgrading from an earlier version. Check captions, alt text and any optimisation or offload service while you are there.

8. Validate integrations, scheduled tasks and email delivery

A page can look perfectly normal while background processes fail silently. Test contact form email, CRM delivery, payment webhooks, marketing subscriptions, search, maps, stock synchronisation, API connections and any single sign-on flow the business depends on.

Check scheduled tasks and cron events directly rather than waiting for a missed report or an abandoned-order email that never sent. Review the email provider's delivery log and the receiving system, not just the form's on-screen success message.

Form delivery breaking quietly after an update is the most expensive failure on a small business site, because nothing looks wrong. You find out weeks later when you notice the enquiries stopped.

9. Check caches, analytics, logs and the rollback boundary

Purge page, object and CDN caches in that order, then revisit key pages in a private browser session. A stale cache can keep serving broken assets long after the application is healthy.

Use a real-time report or debug view to confirm page views, conversions and consent-dependent tags still fire. Check canonical tags, robots directives, XML sitemaps and key structured data if the window included theme or SEO plugin changes. Compare response times against a recent baseline, and check PHP and web server error logs, application monitoring, failed background jobs and uptime alerts. A rising error rate is more actionable than a single synthetic speed score.

Then define what would trigger a rollback: checkout failure, widespread editor errors, loss of customer access. Cosmetic issues are usually safer to repair forward, because rolling back a security release reintroduces the patched vulnerability. The WordPress handbook warns that a rollback needs a complete pre-update backup and can create complications when database structures differ. Make that call with a developer who knows the site.

A compact update workflow

Keeping that record turns maintenance from a hopeful click into a repeatable process, and it removes the ambiguity if a regression surfaces three weeks later.

What to do if something looks wrong

If you find an unexplained administrator account, modified core files or a scanner hit, treat it as an active compromise rather than a curiosity. Put the site into maintenance mode, change hosting and database passwords alongside the WordPress ones, rotate the salts, restore from a backup predating the earliest suspicious activity, and patch before bringing it back up. Restoring without patching resets the clock on the same break-in.

Common mistakes to avoid

• 1. Waiting for exploit details before patching: WordPress has already classified the release and recommended immediate action.
• 2. Assuming auto-update means verified: Automation installs files. It cannot confirm your enquiry, payment or membership flow still works.
• 3. Testing only as an administrator: Customers and lower-permission roles hit different caching, access and interface behaviour.
• 4. Updating without a named rollback owner: A backup helps less when nobody knows who can restore it at 9pm.
• 5. Rolling back over a visual difference: A rollback can restore a known vulnerability. Assess severity and repair forward where practical.

Frequently asked questions