WordPress 7.1.3 is a maintenance and security release published October 6, 2026. Update through the official WordPress or managed-host process, then verify the installed code and the workflows affected by the fixes. A successful updater message does not establish that every live installation is patched.
What changed in this release?
The official announcement lists seven security fixes and four maintenance fixes. Security areas include comment handling, private or unpublished content disclosure, WXR exports, author permissions, URL handling, embeds and hook parameters. These are release facts, not evidence that your site was compromised.
The announcement recommends updating immediately. For an older branch, check its actual patched version in the official release information. Do not assume every supported backport carries the number 7.1.3, or that a backport means a legacy branch receives full ongoing support.
Record which installations received the update
List the production domain, application path and deployment owner. Include public staging and old migration copies. For a host with several serving nodes, ask for deployment evidence covering all nodes rather than checking only one shell session.
Use the same controlled process described in our previous security-update verification guide, with the current package. Keep a usable backup, but do not postpone an urgent patch indefinitely while waiting for a large redesign or unrelated plugin cleanup.
An authorized operator can run these read-only checks from the correct installation:
wp core version
wp core verify-checksums
The checksum command checks official core files. It does not certify plugins, uploads, accounts or database content as malware-free. Investigate mismatches using the correct package and locale rather than suppressing the warning.
Deployment: All live copies checked. Regression: Controlled workflows work. Incident: Suspicious activity investigated. Boundary: Patched does not mean malware-free. Explanatory checklist, not a customer test result.
Exercise the affected business workflows
Use synthetic content on private staging for the deeper checks. Do not reproduce exploit payloads on a live customer site.
| Workflow |
Controlled check |
Evidence to retain |
| Comment moderation |
Open and moderate an ordinary pending test comment |
Normal action completes without a new error |
| Private content |
Check a private test post while logged out |
Protected content remains unavailable |
| Author workflow |
Use the approved author role to edit its own draft |
Expected permission boundaries remain intact |
| Content export |
Export a small permitted test selection |
Intended records can be read from the export |
| Embedded content |
View an existing permitted embed |
Layout and loading still work |
Treat these as regression checks, not a security certification. A private-post test at one URL does not prove every historical disclosure path is closed; installation verification remains essential.
When the update and the incident are different jobs
If unknown administrators, unexplained file changes or suspicious requests are already present, preserve the relevant logs and investigate alongside patching. Updating does not revoke an attacker's existing sessions or remove unrelated malicious code.
After rollout, check login, editor save, one controlled form submission and the site's critical customer journey. Record any new error with its timestamp. HandL WP can investigate a failed update or suspected compromise using redacted evidence and the deployment inventory, without exposing credentials in a public ticket.
References reviewed October 7, 2026. Examples are explanatory, not customer test results.