Automatic Updates: What Should (and Shouldn't) Update Itself

What WordPress already auto-updates, by default

Automatic background updates were introduced in WordPress 3.7, specifically to promote better security and remove the "did I remember to update?" gap. What's actually on by default depends on how the site started out:

• Existing installations: minor core releases (the maintenance and security releases — the "x.x.1", "x.x.2" versions) and translation files auto-update by default. This is the tier that matters most for security, and it's already on for almost every WordPress site without anyone configuring anything.
• New installations on WordPress 5.6 or later: both minor and major core updates are enabled by default, unless the install detects it's under version control (a signal that a developer is managing updates deliberately).
• Plugins and themes: not auto-updated by default at all — with one exception. WordPress's security team can force an automatic update to a specific plugin or theme version when they identify a critical, actively-exploited vulnerability, independent of what any site owner has configured.

Since WordPress 5.5, there's also a plain dashboard toggle for the plugin/theme layer: on the Plugins screen, each installed plugin has an "Enable auto-updates" link in its own row; themes get the same toggle inside their detail modal on the Appearance screen. No code, no wp-config.php edit — just a link to click, checked roughly twice a day by WP-Cron.

Why security patches specifically should almost always stay on

The core reason auto-updates exist at all is timing, and the timing is worse than most site owners assume. Research on real-world exploitation shows that for the most aggressively targeted vulnerabilities, the weighted median time to first exploit is around 5 hours after disclosure — and for many high-impact vulnerabilities, roughly half get exploited within 24 hours. Proof-of-concept exploit code now often appears within hours of a public disclosure, not the day-or-more lag that used to be typical.

Set that against how site owners actually behave: for a lot of people, a week is a realistic turnaround between "I saw the update notification" and "I actually logged in and clicked update." That gap — hours for an attacker, days for a person — is exactly the window a lot of real WordPress compromises happen in. It's also why reading a CVE to judge whether a given update is closing a serious, already-public hole is a genuinely useful skill, not just trivia: it tells you which updates are worth applying the moment they're available rather than batching for later.

Why "auto-update literally everything" isn't risk-free either

This is the part that gets flattened in a lot of generic advice. An update — even a routine, non-security one — can change behavior, deprecate a function a theme relies on, or introduce its own new bug. A site with no testing step and every plugin set to auto-update blindly does carry a real, if usually smaller, risk: something breaks in production with nobody having reviewed the change first. That's a genuinely different risk than a security compromise, but it's not nothing, especially for a business-critical, heavily customized plugin (a payment gateway integration, a booking system, a page builder holding your actual page layouts).

The honest framing: delaying a security patch is usually the bigger and more urgent risk; breaking a critical plugin with an unreviewed update is a smaller but real risk that mostly hits sites with more customization and less room for surprise downtime. Both are worth planning for — they just call for different amounts of caution.

A sensible default policy

1. Leave WordPress core minor/security updates on. This is already the default for existing installs, and there's very little reason to turn it off — it's the update tier most directly tied to closing disclosed vulnerabilities quickly.
2. Auto-update any plugin or theme with a known critical vulnerability, immediately. If you see a CVE with a high severity score for something you're running, don't wait for your normal update cadence — that's the exact scenario the 5-hour exploitation window is describing.
3. For most other plugins, auto-update is a reasonable default too — most updates are routine and low-risk, and the security upside of not falling behind outweighs the occasional compatibility hiccup for a typical site.
4. For a small number of business-critical, heavily customized plugins, add a testing step rather than blind auto-update — a staging copy that gets the update first, checked before it goes to production. This is exactly the workflow covered in staging vs. production security practices, and it's worth setting up specifically for the handful of plugins where breakage would actually hurt.

The goal isn't "trust nothing" or "auto-update everything blindly" — it's putting the deliberate-review step only where the stakes of an unreviewed change are actually high, and letting the low-stakes, high-value updates (especially security ones) apply themselves.