Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article5 min readViews0

WordPress 7.1.4: What to Check Before an Urgent Update

On October 28, WordPress released 7.1.4 with security fixes. We examine the affected branches, the safe update sequence, and acceptance criteria for sites, stores, and integrations.

ДенисCommunity author★ 19
Comments 0

A manipulator replaces a damaged site module under a purple protective dome
In this article

If you have a self-managed WordPress installation, today is the day to verify the actual core version, create a recoverable backup, and install the patched release for your branch. After updating, simply seeing a green checkmark is not enough: you must confirm the version, open public pages and the admin panel, run a critical site scenario, and review the error log.

On October 28, 2026, WordPress released 7.1.4 as a security update. It includes fixes for a vulnerability in the update process that could lead to code execution during the update window, several stored XSS issues, denial of service in the Interactivity API, partial data disclosure, and an update to the bundled root certificate set following the revocation of eMudhra. Stored XSS is a malicious snippet that is written to a site and later executed in a user's browser with appropriate permissions.

The mere publication of vulnerabilities does not prove that a specific site was compromised. However, delaying an update until an incident occurs is a strange way to test the accuracy of the term 'urgent'.

Who this release affects

First and foremost, owners of self-managed WordPress installations and teams responsible for their updates. On managed hosting, the provider may perform updates, but this must be confirmed against the site's actual version and the provider's notification. Automatic updates are not equivalent to acceptance testing: the process may not have finished yet or may have stopped due to permissions, disk space, or incompatibility.

WordPress stated that the fixes were backported to branches still receiving security updates, down to version 4.7. However, only the latest version is actively supported. Therefore, an older branch can be temporarily secured with a security release, but the long-term plan must still lead to the current version after compatibility verification.

Which version should be targeted after the update

  • 7.1 → 7.1.4, current WordPress release;

  • 7.0 → 7.0.8 and 6.9 → 6.9.11: both branches include all 22 fixes;

  • 6.8 → 6.8.12 and 6.7 → 6.7.11: 20 fixes each;

  • 6.6 → 6.6.11, 6.5 → 6.5.14, and 6.4 → 6.4.14: 19, 17, and 17 fixes;

  • 6.3 → 6.3.14, 6.2 → 6.2.15, 6.1 → 6.1.16, and 6.0 → 6.0.18: 9 fixes each;

  • 5.9 → 5.9.20: 9 fixes;

  • 5.8 → 5.8.19, 5.7 → 5.7.21, 5.6 → 5.6.23, 5.5 → 5.5.24, 5.4 → 5.4.25, 5.3 → 5.3.27, 5.2 → 5.2.30, 5.1 → 5.1.28, and 5.0 → 5.0.31: 6 fixes each;

  • 4.9 → 4.9.35, 4.8 → 4.8.34, and 4.7 → 4.7.39: 4, 2, and 2 fixes;

  • 4.6 and older: no security release.

The number of fixes varies between branches: it cannot be assumed that any old release received all 22 changes. Branches 4.6 and older have no fixes in this release; such sites require a separate migration plan, not another attempt to wait for a patch.

Safe update sequence

  1. Record the current core version, active theme, critical plugins, PHP version, and the person responsible for the maintenance window. On managed hosting, confirm whether the provider updates the site core specifically.

  2. Create a backup of the database and files. Verify that the backup completed without errors, is accessible outside the site being updated, and that the restoration procedure is clear.

  3. For a store or other critical site, first repeat the update on a compatible staging environment. Check the theme, plugins, integrations, scheduler, and PHP requirements.

  4. Install the fixed release of your branch via the standard WordPress mechanism. Do not replace individual files with a random archive: this complicates integrity verification and rollback.

  5. Immediately after the update, confirm the version number and perform a brief acceptance test. If the update does not complete, stop, save the logs, and revert to the working version using a pre-verified plan.

What to verify after the update

  • the homepage, several internal pages, and loading of static files without 5xx errors;

  • access to the admin area, opening the editor, and saving a safe test change;

  • for a store: product card, cart, placing a test order without real payment deduction, and receiving a notification;

  • contact forms, REST API, webhooks, and other integrations that depend on authorization or background tasks;

  • the WordPress scheduler and system cron, if it is used instead of the built-in visitor-triggered execution;

  • PHP and web server logs: no new fatal errors, no infinite retry loops for the same task, and no sharp increase in 4xx/5xx responses.

Success criteria: the site reports the corrected version, public and administrative scenarios execute correctly, critical integrations return expected results, and no new errors appear. A single accessible URL returning a 200 status code confirms only that specific response, not the full functionality of the store.

If the update has already run automatically

Do not run a repeat update just for peace of mind. First, check the actual version, completion time, and logs. Then perform the same short acceptance test. If the version remains unchanged, look for the cause of the stop: file permissions, free space, a stuck WordPress maintenance mode, extension incompatibility, or a managed hosting policy.

If there are signs of compromise

Do not treat the update as an investigation. Save the logs and a state snapshot, restrict access to the affected site, check for unknown administrators, file changes, and cron jobs. Change passwords and keys only after preserving evidence and eliminating the entry point; otherwise, you may lose context and leave the cause in place.

Sources and boundaries

In the official WordPress 7.1.4 release announcement, the classes of fixed issues are listed along with a recommendation to update sites immediately.

The WordPress 7.1.4 documentation page contains branches, fixed release numbers, and the count of backported fixes. Data verified on October 29, 2026; for a specific site, its plugins, theme, PHP version, and hosting model are additionally critical.

GENERAL IT

Help with your project

GENERAL IT

Read more on this topic

Discussion 0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.