Three WordPress dates to put in your calendar before New Year

On 28 October WordPress put out version 7.1.4 and asked site owners to update immediately. The release fixes a bug that could let an attacker run code on a site during an update, plus several smaller cross-site scripting flaws. Within 21 hours, Wordfence counted more than 18,500 requests from bots looking for sites that had not updated yet. After that comes WordPress 7.2 in early December, and PHP 8.2 runs out of security support on 31 December.

That is the first of three dates in the last two months of 2026 that matter if your business runs on WordPress. The other two are still ahead of you.

28 October: the security release you may already have

Most WordPress sites install minor releases like 7.1.4 by themselves, so there is a good chance yours already has it. It is still worth thirty seconds to check, because automatic updates are often switched off by a host, a developer or a plugin, and nobody remembers doing it.

Go to Dashboard > Updates in your admin. The page says which version you run. If it shows anything below 7.1.4, update now, then load your homepage, a contact form and, for a store, the checkout.

The fixes were also backported to every branch back to 4.7. If your site runs an old major version for a reason, such as a plugin that has never been updated, the patched version for that branch is waiting for you too.

Early December: WordPress 7.2

The first beta of WordPress 7.2 came out on 20 October and the second on 27 October. The release team plans to ship it in early December, with 8 to 10 December as the target.

For a business site, these are the changes to know about:

• Sudo mode. WordPress will ask you to log in again before sensitive actions. If someone steals a logged-in session, they can do less with it.
• A Secrets API. A safer place for plugins to keep API keys and passwords, which today often sit in plain text in the database.
• Suggestion mode in Notes. Editors can propose changes to a page for someone else to accept.
• A new default theme, Ipsum. It only matters if you start a new site on it.

Real-time co-editing, where two people edit the same page at once, is not in this release. It was pulled from 7.0 on 8 May over stability and server load, and the 7.2 roadmap says it is “intentionally not on the roadmap”. If you were waiting for it before changing how your team works, keep waiting.

Major releases are where things break, because every plugin and theme on your site has to keep up with them. In August, for example, 7.1 moved the post editor into an iframe for every theme, which changes how plugins that add to the editor load their styles. So test each major release on a staging copy of your site before it goes near the live one. If you sell online, do not update on the first day, especially in the run-up to the holidays. Install security releases as soon as they come out; give a feature release a quiet week.

31 December: PHP 8.2 loses security support

WordPress runs on PHP, and each version of PHP gets security fixes for a fixed period. PHP 8.1 lost that support on 31 December 2025. PHP 8.2 loses it on 31 December 2026.

You will not see a warning on your site when this happens. Nothing changes on 1 January. The risk is that the next serious bug found in PHP 8.2 will not be fixed for you.

To check your version, open Tools > Site Health > Info and look under Server. WordPress now needs PHP 7.4 at least and recommends 8.3. If you are on 8.2 or older, ask your host to move the site to 8.3 or newer. Most hosts let you switch it yourself in their control panel.

Before you switch the live site, switch a staging copy and click through it. Old plugins and themes sometimes use functions that newer PHP versions removed, and the usual symptom is a blank page or a “critical error” message. If that happens, the answer is to update or replace the plugin, not to stay on old PHP.

Why this does not wait until January

Patchstack’s yearly report counted 11,334 new security holes in WordPress plugins and themes in 2025, up 42% on the year before. For the ones attackers went after hardest, the typical time from public disclosure to mass attacks was five hours. We wrote about what that speed means in Five hours: how fast a plugin bug becomes an attack.

Old PHP and skipped updates are what turn those bugs into break-ins. Neither is hard to fix. Both are easy to forget.

A 20-minute check for this week

1. Confirm the site is on WordPress 7.1.4 or a patched older branch.
2. Note your PHP version in Site Health. If it is 8.2 or lower, book the change with your host for November.
3. Delete plugins you no longer use. Deactivated plugins still sit on the server.
4. Make sure a backup runs every day, is stored off the server, and that someone has restored one in the last six months.
5. Put a reminder in the second week of December to test WordPress 7.2 on staging.

If nobody on your team owns these jobs, that is the real problem to solve. Updates, backups and PHP versions are exactly what a care plan is for.

If you would rather not track this yourself, our website care service handles WordPress 7.2 and every update after it. For why speed matters here, read how fast a plugin bug becomes an attack.