Updated on 14 min read

WordPress automatic updates: should you enable or disable them?

Sébastien Nobour

Founder of DEVEDANOS

Practices

Should you let WordPress install its updates on its own, or disable them? For plugins and themes, we advise against the automatic updates WordPress applies on its own, without any testing. Those of a host that tests each update before applying it, and can roll back to the previous version, are suitable: in our view, for WordPress, these checks are generally enough to show that something is wrong. Without such a host, update one plugin, or one theme, at a time, then check that it has not broken anything; if there is a problem, roll back to the previous version.

The NCSC, the UK’s National Cyber Security Centre, asks every organisation to “apply software updates as soon as possible, and ideally automatically”, because attackers often study a fixed vulnerability to write an attack that exploits it; according to Amazon, AI makes this work cheaper. The NCSC points out that vendors test their own updates, while asking organisations to test them on their own systems too and to roll them out in stages. For software you install and use off the shelf (Windows, macOS, a phone, a browser, office software), we therefore advise switching on its automatic updates. For an online service, it is the provider that applies the fixes. A WordPress site falls into neither category: its owner does not develop the software and does not use it off the shelf, but assembles and configures it.

The vendor of an operating system tests its updates for the whole system. A WordPress plugin update, on the other hand, cannot be tested in advance with every other plugin installed on your site.

Why we advise against the updates WordPress applies on its own

WordPress is used, as of October 2026, by nearly four sites in ten, and most of its vulnerabilities are not in WordPress itself. According to Patchstack, 11,334 new vulnerabilities were found in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes, and only 6 in WordPress core. And 46% of these vulnerabilities had not received a fix from their developer by the time they were disclosed (Patchstack). These figures come from a company that sells protection against these vulnerabilities.

These updates install a new version shortly after its release, before anyone has had a chance to report a problem with it: malicious code slipped into a freshly published version, or a new vulnerability. So the site is not necessarily better protected. WordPress.org takes this into account: since 5 June 2026, each new version of a plugin in its directory waits up to 24 hours before automatic updates distribute it, to give everyone time to review its changes. And a WordPress site combines WordPress core, a version of PHP, and plugins and themes written by authors independent of one another. Nothing guarantees that the new version of one plugin works with the version of another, or with the server’s PHP version. Yet WordPress installs it in production without any test or any person having checked that the site still works.

A host that tests each update before applying it, and can roll back to the previous version, can handle them automatically (see below). Without such a host, the method does not change, whether you do it yourself or a service provider does it for you. It starts with a backup: WordPress asks for the WordPress files and database to be backed up before upgrades, whether automatic or manual. Then you update one plugin, or one theme, at a time, and check after each one that it has not broken anything. If there is a problem, you roll back to the previous version by restoring the backup, first the files, then the database.

For a custom-built application, we pin the exact version of every dependency, and every update, one at a time, goes through the deployment pipeline and its automated tests before it reaches production. This rule comes from Continuous Delivery, by Jez Humble and Dave Farley, and from OWASP’s Top 10 lists, the leading foundation for web application security. Dave Farley is the inventor of the deployment pipeline, often called the CI/CD pipeline. The deployment pipeline is the automated chain that takes each change to the code, tests it, records it and makes it ready to go to production. For a WordPress site, pinned versions, a pipeline and automated tests are hard to apply. They are worth it when the site comes close to an application, with custom-written code: that is the case described below.

What WordPress does by default

By default, WordPress installs only some of its updates on its own. At the time of writing (October 2026), since WordPress 3.7, minor core updates install automatically by default (WordPress). For plugins and themes, automatic updates have had to be switched on one by one since WordPress 5.5, and WordPress then runs them twice a day. For major core updates, the default setting depends on when the site was installed (see below). The same WordPress page opens with this sentence: “To keep your WordPress site secure, you should always update your plugins and themes to the latest version” (WordPress).

In 2025, Patchstack measured a median of five hours between the disclosure of a heavily exploited vulnerability and its first exploitation. Alerts can be automated; the decision to update rests with a person, who makes it as soon as the alert comes in. On a WordPress site, the administrator starts a plugin update in one click, then checks that the site works. If the company has nobody to handle this, a service provider can do it, as we describe below.

Two other factors matter just as much. In 2025, nearly half of the vulnerabilities in the WordPress ecosystem had no fix on the day they were disclosed, so no update policy, automatic or manual, covers them that day. Fewer plugins installed means fewer possible vulnerabilities, as with any dependency of an application. And a plugin abandoned by its author will never get another fix: it gets replaced.

Enabling or disabling WordPress automatic updates

For plugins and themes, we advise disabling automatic updates; for WordPress core, letting minor updates install on their own.

At the time of writing (October 2026), automatic updates for plugins and themes are set one by one, from the admin. On the Plugins screen, the “Automatic Updates” column shows, for each plugin, a link that switches its updates on or off (“Enable auto-updates”, “Disable auto-updates”); a bulk action applies to several plugins at once. For a theme, the link is on the Appearance screen, in the window that opens when you click its thumbnail. If these links do not appear, the feature has probably been deactivated by your host or by a plugin.

For WordPress core, the default setting depends on when the site was installed. Since WordPress 5.6, new installations automatically receive minor and major updates; an older installation keeps its setting, and by default receives minor updates only. The Dashboard > Updates screen lets you change this setting.

Minor core updates fix vulnerabilities and handle maintenance, and WordPress considers disabling them “strongly discouraged”. Major updates bring new features; in our view, they are handled like plugin and theme updates: one at a time, then checking that the site still works.

For your technical team

In wp-config.php, the WP_AUTO_UPDATE_CORE constant sets what core installs on its own, and takes precedence over the setting on the Updates screen: true for all updates, 'minor' for minor updates only, false for none (WordPress). The AUTOMATIC_UPDATER_DISABLED constant disables all automatic updates, core and translations included. In our view, it is only justified if every core update is tested elsewhere, as with Bedrock, described below.

// In wp-config.php: core installs only its minor updates on its own
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

For plugins and themes, the auto_update_plugin and auto_update_theme filters decide instead of the admin links. WordPress advises putting these filters in a must-use plugin, and never directly in wp-config.php. A must-use plugin goes in the wp-content/mu-plugins folder, activates itself and cannot be deactivated from the admin.

<?php
// wp-content/mu-plugins/disable-plugin-theme-auto-updates.php

/**
 * Plugin Name: Disable plugin and theme auto-updates
 */

defined( 'ABSPATH' ) || exit;

// Disables automatic updates for all plugins and all themes
add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );

A WordPress automatic update has failed: what should you do?

During an update, WordPress puts the site into maintenance mode: it creates a .maintenance file at the root of the site, and visitors see a scheduled maintenance message. If the update is interrupted, the file stays in place, and so does the message. WordPress gives the steps to follow:

  1. Delete the .maintenance file at the root of the site, over FTP or with your host’s file manager. The message disappears.
  2. Run the update again. If it fails again, do it by hand, following the WordPress procedure.
  3. If the site no longer works after the update, restore the backup: first the files, then the database.

The last step assumes a recent backup, whose restoration has already been tried: WordPress asks you to check this before enabling automatic updates for plugins.

When plugins or themes have been updated automatically, the site owner receives an email, even if some updates failed. For core, an email also reports the failure. In the admin, the failure shows up like this: “An automated WordPress update has failed to complete – please attempt the update again now.”

If automatic updates never run, look for error messages on the Tools > Site Health screen: they rely on WordPress’s scheduled tasks, which do not run correctly on every server.

Who updates PHP, and who handles maintenance?

WordPress updates only update WordPress, never PHP: depending on your hosting, either the host installs PHP fixes or you do. We recommend choosing a host that takes care of this, and asking them first who applies the fixes on your hosting plan, and how quickly.

For a WordPress site, nothing requires you to handle this maintenance yourself. Hosts specialising in WordPress take care of updating the server software, PHP included, and of automatic backups. The WordPress security guide describes the trustworthy host: it “provides the most recent stable versions of all server software”, “provides reliable methods for backup and recovery”, and readily discusses the security measures it offers.

A managed WordPress hosting offer generally updates PHP and WordPress for you. Some offers also update plugins automatically. The method does not change for all that: the host updates one plugin at a time, checks the site after each one, and can roll back to the previous version. This is the automatic option we consider acceptable: for WordPress, these checks are generally enough to show that something is wrong.

Premium plugins, those that require a licence key, and those written for the site generally remain your responsibility. Each one is updated following the method described above: one at a time, checking afterwards that the feature it brings has not regressed, and rolling back to the previous version if it has.

Before choosing a host, ask them these questions too:

  • Do you update one plugin at a time, with a check after each one?
  • Do you test updates on a copy of the site before applying them?
  • How do I restore a backup?

If you would rather not update plugins and themes yourself, hand this task to someone who administers the site and its server. The method stays the same: one plugin at a time, a check after each one, a rollback to the previous version if something regresses, and PHP updated when the host does not do it. We can take care of it: contact us.

When the site contains custom code

A custom-built application is also updated only by deliberate decision. Every update, of PHP or of a component, goes through the deployment pipeline and its automated tests; the fix for a serious vulnerability reaches production on the day it is published.

For your technical team

Everything changes on the day you have to touch the code. WordPress’s first rule applies to everyone: “Don’t touch WordPress core”, because every update overwrites its files; whatever you want to add or modify goes into a plugin. For a theme, a child theme lets you modify it without touching its code, while still receiving its updates. This custom code, child theme or plugin, is software that you develop. In Continuous Delivery, Jez Humble and Dave Farley ask for everything used to build and deploy the software to be kept under version control, and for every change to go through the deployment pipeline. In practice, this code lives in a Git repository and goes to production through the pipeline, never copied by hand onto the server.

Nobody needs to modify WordPress core. The gap in a standard installation lies elsewhere. Plugins are installed from the admin, without their versions being declared anywhere, and the configuration lives in a single file, the same for every environment. You therefore cannot rebuild, identically, on a test environment, the site that is in production, which is exactly what Jez Humble and Dave Farley ask for. This is the gap that Bedrock, from Roots, fills. It does not modify WordPress core: it wraps it. WordPress, its plugins and its themes become dependencies, installed by Composer at a precise version and locked in composer.lock. The configuration changes with the environment (development, staging, production) through environment variables. The Git repository then contains only the custom code, the configuration and the list of dependencies and, according to Roots, core and plugins can no longer be modified outside the development environment. Roots presents this setup as applying to WordPress the “Twelve-Factor App” methodology, which describes how to build web applications that are easy to deploy and maintain. Updates are then made in the code, one plugin at a time, then go through the pipeline. Bedrock’s default configuration currently disables automatic updates and installing plugins from the admin (config/application.php).

In our view, Bedrock is worth it once a WordPress site is maintained as software: custom code, several environments, a development team, a pipeline. For a site that you configure, and to which you add a child theme or a plugin, it is not necessary. And Bedrock organises the project, nothing more: the quality of the custom code remains the responsibility of those who develop it.

// Bedrock's config/application.php, default configuration
// Disables WordPress automatic updates
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Disables the admin file editor
Config::define('DISALLOW_FILE_EDIT', true);
// Forbids installing or updating plugins from the admin
Config::define('DISALLOW_FILE_MODS', true);

# With Bedrock: update a single plugin, in the code, then go through the pipeline
composer update wp-plugin/plugin-name

Without Bedrock, the WordPress hardening guide advises disabling the admin file editor, which by default lets you modify the PHP code of plugins and themes; it states that this will not stop everything, but might stop some attacks (WordPress):

// In wp-config.php: disables the admin file editor
define( 'DISALLOW_FILE_EDIT', true );

To update one plugin at a time, WP-CLI, WordPress’s command-line tool, keeps you in control: wp plugin update accepts --version to target a specific version, --patch to take only fixes, and --dry-run to see what would be updated without changing anything (WP-CLI). The WordPress documentation itself cites customisations and prior testing on a staging environment as reasons to disable automatic updates, and asks, before enabling them for plugins, that you be able to roll back to a previous version of your website.

How to secure a WordPress site

On a WordPress site too, the site must not be able to change its own code, and each program should have only the permissions it needs. WordPress supports this: only the uploaded content folder (wp-content) should be writable by the web server, and the code editor built into the admin, according to WordPress “often the first tool an attacker will use if able to login”, can be disabled.

For your technical team

The WordPress hardening guide also recommends: MySQL user limited to reading and writing data (the DROP, ALTER and GRANT privileges can be revoked, bearing in mind that some updates change the schema); wp-config.php set to 400 or 440; DISALLOW_FILE_EDIT, described above; web application firewall, with ModSecurity cited as the most popular open source option.

How we work

For the applications we develop, we pin every dependency to its exact version, check every day whether a known vulnerability affects the components in use, and monitor the servers.

A WordPress site becomes an application when its users create, edit and store their own data on it, and the site applies business rules to that data: orders through WooCommerce, a members’ area, bookings that depend on availability. For these applications, as for custom-built ones, updates and security fixes are part of the maintenance included in our offer: custom software on a fixed monthly budget, with a zero-regression guarantee.

Further reading

On 21 October 2026, the PHP team rushed out new versions of the language. They fix two critical vulnerabilities, which the people who found them named PHP2Shell. Our article on PHP2Shell explains who is affected, what to do, in order, and how to limit the damage if it is exploited.

Do you have an application to have built, or to take over? Shall we talk?

Sources

Read next

Shadow IT: definition, examples and risks

What is shadow IT? The definition from the UK's National Cyber Security Centre, examples (Excel, AI tools), the risks for the business, and why the answer is a tool that fits the work.

How to fix vulnerabilities in applications

Protect a web application, whatever its language: limit what a vulnerability lets an attacker reach, be alerted immediately, check your dependencies, apply every critical fix on the day it is published.