WordPress: core, plugin and theme updates that keep sites safe

Updated November 2026

Most WordPress break-ins start in an outdated or abandoned plugin or theme, not in WordPress core. Keep core on the latest release (7.1.4 as of November 3, 2026), turn on auto-updates for plugins and themes, and delete every plugin you don't use.

7.1.4Latest release, a security release (October 28, 2026)
13Issues fixed in 7.1.4
4.7Oldest branch that still gets backported fixes
2×Auto-update runs per day by default

What you are patching

A WordPress site has four layers, and each one needs updates: core (the WordPress files), plugins, themes, and the PHP runtime underneath. Core gets regular security releases from the WordPress Security Team. Plugins and themes come from thousands of separate authors. Some patch quickly, some slowly, and some never. That is why plugins are the usual way in, and why you should cut down the number of plugins before you worry about anything else.

Check the installed versions

Use WP-CLI. It refuses to run as root unless you add --allow-root, so run it as the user that owns the site files. In these examples that user is siteuser and the site is in /var/www/example.com.

sudo -iu siteuser                   # switch to the file owner
cd /var/www/example.com
wp core version --extra             # version, database revision, locale
wp core check-update                # newer core releases, if any
wp plugin list --update=available   # plugins with an update waiting
wp theme list --update=available    # themes with an update waiting
wp plugin list --status=inactive    # candidates for deletion

Without WP-CLI, read the version from the file: grep wp_version /var/www/example.com/wp-includes/version.php. In the dashboard, Dashboard > Updates lists core, plugin, theme and translation updates in one place.

Supported versions

WordPress officially supports only the latest release, which is the 7.1 series as of November 2026. The Security Team also copies security fixes back to older branches as a courtesy, so older sites can still get critical fixes through auto-updates. The 7.1.4 announcement says those backports currently go back to 4.7. Each older branch gets its own point release, for example 7.0.8 on the same day as 7.1.4. WordPress 7.2 is planned for December 8, 2026.

Recent WordPress security releases, as of November 2026
Release	Date	What it fixed
7.1.4 (and 7.0.8)	Oct 28, 2026	13 issues, including a remote code execution risk during upgrades and many stored XSS (cross-site scripting) bugs
7.1.3	Oct 6, 2026	7 security fixes
7.1.2	Sep 22, 2026	1 critical vulnerability
7.1.1	Sep 17, 2026	11 security fixes
7.0.2	Jul 17, 2026	SQL injection and REST API remote code execution; WordPress.org forced auto-updates

WordPress 7.0 and 7.1 need PHP 7.4 or newer and are marked compatible with PHP 7.4 through 8.5. That only tells you WordPress will run. PHP itself must also be a supported, patched version. A critical PHP security release came out on October 21, 2026. See PHP updates.

Distro packages, tarball or Docker

Most sites run WordPress from the wordpress.org download and let it update itself. Some distributions also package it. Debian 13 ships 6.8.12 (from its security archive) and Debian 12 ships 6.1.9. Compare those numbers with the latest point release of the same branch before you rely on them. The FreeBSD port www/wordpress is at 7.1.4. A packaged install is updated by the package manager (sudo apt upgrade, or pkg upgrade wordpress as root on FreeBSD). Plugins and themes are still updated by WordPress or WP-CLI. Pick one way to update core and stick to it.

With the official wordpress Docker image, the image only provides the first install. After that, the files in /var/www/html manage themselves, so pulling a newer image does not update an existing site. Either let WordPress update itself inside the volume, or build your own read-only image and redeploy it for every release.

Update now

Take a backup, then update core, the database, plugins, themes and translations:

sudo -iu siteuser
cd /var/www/example.com
wp db export ~/example-$(date +%F).sql   # database backup, outside the web root
wp core update                           # latest release
wp core update-db                        # database changes, if any
wp plugin update --all
wp theme update --all
wp language core update

To stay on your current branch and take only its security and maintenance releases, use wp core update --minor. To preview plugin updates, add --dry-run. To hold back one plugin you are testing, add --exclude=plugin-slug. None of these commands restart services. If you upgraded PHP itself at the same time, restart PHP-FPM so it loads the new binary and clears OPcache: sudo systemctl restart php8.3-fpm on Debian and Ubuntu (adjust the version number; this restarts the service).

The same order works by hand, from cron, or in the dashboard.

Turn on automatic updates

Since WordPress 5.6, new installs update core automatically for both minor and major releases. Older installs that were upgraded may still be set to minor releases only. Minor releases include security releases. Set the policy in wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', true );      // all core updates
// define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // security and maintenance only

Never set AUTOMATIC_UPDATER_DISABLED to true. It turns off every automatic update, including the forced security updates that WordPress.org sometimes pushes, as it did for 7.0.2.

Plugin and theme auto-updates are opt-in, one item at a time (WordPress 5.5 and later). Click "Enable auto-updates" on the Plugins screen, or switch them all on at once:

wp plugin auto-updates enable --all
wp theme auto-updates enable --all
wp plugin list --fields=name,version,auto_update

WordPress runs auto-updates twice a day through WP-Cron, and emails the site admin after each attempt. Two things often break this. First, WP-Cron only runs when someone visits the site, so a quiet site may never update. Second, if you lock the files down so the web server cannot write them (see the tips below), WordPress cannot update itself. In both cases, run the update commands from the file owner's crontab instead, for example nightly at 03:15:

15 3 * * * cd /var/www/example.com && /usr/local/bin/wp core update --minor && /usr/local/bin/wp plugin update --all && /usr/local/bin/wp theme update --all

Check Tools > Site Health for cron and update errors. Premium plugins sold outside WordPress.org update through their vendor's licence system. Check that the licence is still active, or they will quietly stop getting fixes.

Verify the result

wp core version
wp core verify-checksums              # core files against WordPress.org checksums
wp plugin verify-checksums --all      # plugin files against WordPress.org checksums
wp plugin list --update=available     # should print an empty table

verify-checksums reports any core or plugin file that differs from the official release. That is also a quick check for planted code. Plugin checksums come from WordPress.org, so plugins from other sources can't be checked this way. If files fail the check and you did not change them, treat the site as possibly compromised and follow our hacked-website steps.

Where advisories appear

WordPress News, Security category, with an RSS feed. Every core security release is announced here.
The changelog of each plugin on its WordPress.org page. If the page says the plugin has been closed, it gets no more updates through WordPress.org, so replace it.
Several security companies publish free plugin vulnerability databases. Any of them, checked against your wp plugin list, will show plugins with known holes.
Our vulnerability pages for the most serious issues.

Quick hardening tips

Delete plugins and themes you don't use with wp plugin delete <slug>. Deactivated code is still on disk and can still be reached and exploited. Keep one default theme as a fallback.
Prefer plugins that are still maintained: check the "last updated" date and the open support threads before you install one.
Set ownership to your user account, directories to 755 and files to 644. Make wp-config.php readable only by you and the web server (often 440 or 400). Only wp-content, or just wp-content/uploads, should be writable by the web server.
Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php to turn off the built-in plugin and theme editor.
Give the database user only the rights WordPress needs for day-to-day work. WordPress's hardening guide says DROP, ALTER and GRANT can usually be revoked. Allow them again temporarily if an update needs to change tables.
Block PHP execution in wp-content/uploads in your web server configuration.
Use unique admin passwords and two-factor login (MFA), and remove admin accounts nobody uses.
Keep daily off-server backups of the files and the database, and test a restore.