The WordPress core security team issues patches for two dozen old release lines, not just the current one. Nothing in wp-admin tells you whether yours is among them, whether a patch exists for your version, or what is quietly stopping it from arriving.

Here’s how to find out and get control over your core auto-updates.

The Problem: Silent Drift

Two WordPress sites, both on 6.8.7 — a release WordPress.org classifies as insecure. No one has ever touched an update setting on either site.

Overnight, one site updates to 6.8.8, which is secure. The other leaps forward to 7.1, which is also secure. Why the difference? How did this happen?

One site took a same-branch security patch delivered as a small delta package. The other went straight from the 6.8 branch to the latest release on the 7.1 branch. Nobody chose either outcome. It was decided by a value during the original install process years ago, based on nothing but the date when each site was created.

A third site, configured almost identically, stays on 6.8.7 and remains vulnerable. Why?

This post explains how a security fix actually reaches a WordPress site and the handful of settings — including the install date nobody sets on purpose — that stop security updates from arriving at all. Read this as a companion to my post on core update defaults, which explains where that install-date value comes from and many other technical details about WordPress core’s auto-update logic.

WordPress patches old branches, not just the current one

WordPress doesn’t only fix the latest release and version line when there’s a security update. Your 6.4 site’s path to a secure version of core wasn’t just 7.1, which was released on August 19, 2026. As of August 12, you also had 6.4.10 as an option, and you still do.

When a vulnerability is found, the security team may backport applicable fixes to eligible older branches, shipping them as they become ready. That may be ahead of the latest release carrying the same security fixes, or the backports may come later.

You can see the whole set of backports currently available through the stable-check endpoint in the WordPress.org API. WordPress.org publishes a status for every release it lists, going back to 1.0.2: https://api.wordpress.org/core/stable-check/1.0/

As I write this, there are 884 versions, each tagged with one of three status labels:

• latest — the current release. Exactly one version has this.
• outdated — not the current release, and not presently classified as insecure. That is the most this status asserts. It does not mean the line is supported: WordPress quietly backports to older branches where necessary and feasible, as a courtesy, and those fixes ship as they are ready, separately from the current release. Today there are 24 outdated releases.
• insecure — has known vulnerabilities. 859 versions are in this bucket.

Filtering for the branch tips gives you the versions that are not presently flagged as insecure:

4.7.35   4.8.30   4.9.31   5.0.27   5.1.24   5.2.26
5.3.23   5.4.21   5.5.20   5.6.19   5.7.17   5.8.15
5.9.16   6.0.14   6.1.12   6.2.11   6.3.10   6.4.10
6.5.10   6.6.7    6.7.7    6.8.8    6.9.7    7.0.4

Twenty-four patched branch tips, plus 7.1 as current, i.e. latest as of September 2026.

Ask WordPress.org what updates exist for your version, and it rolls a ladder down to wherever you stand: one entry per release branch, from the current latest down to the next outdated release you’re eligible for, with each branch represented only by its newest patch.

Send version=5.4.20 and you get 19 offers ending in 5.4.21.

curl -s "https://api.wordpress.org/core/version-check/1.7/?version=5.4.20&locale=en_US" | jq '[.offers[] | {response, version}]'

What matters is the label on the rung above you. For a site on 5.4.20, the 5.4.21 entry comes back as "response": "autoupdate", not "upgrade" — so a 5.4 site left at its defaults installs that patch on its own, without anyone logging in. Five years past its release, the 5.4 branch is still quietly patching itself.

To check any specific version:

curl -s https://api.wordpress.org/core/stable-check/1.0/ | jq -r '."6.8.7"'

And to find the patched tip of a branch you’re on:

curl -s https://api.wordpress.org/core/stable-check/1.0/ \
  | jq -r 'to_entries | map(select(.key | startswith("6.8.")))
           | map(select(.value != "insecure")) | .[].key'

Worth knowing: WordPress core doesn’t use this endpoint. Nothing in core queries stable-check — it exists for external tooling, which is why your admin screens will never show you this. Your site can be insecure by this measure and say nothing about it.

What your site is actually offered

Ask WordPress.org what’s available for a 6.8.7 site, and you get five offers, not one:

response=upgrade      current=7.1
response=autoupdate   current=7.1
response=autoupdate   current=7.0.4
response=autoupdate   current=6.9.7
response=autoupdate   current=6.8.8

Four of those are flagged for automatic installation, and the last one is your branch’s patched tip. It even ships with a delta package — wordpress-6.8.8-partial-7.zip — built specifically for sites coming from 6.8.7. The backport is real, it’s offered, and it’s ready to install itself.

So which one do you get? find_core_auto_update() walks the list and keeps the highest version your settings permit:

if ( ! $auto_update || version_compare( $update->current, $auto_update->current, '>' ) ) {
    $auto_update = $update;
}

Highest, not nearest. That’s the whole story of the two divergent sites in the opening example about silent version drift.

I built a 6.8.7 site and ran the background updater against the live API, changing nothing but two options:

Rows one and two both end up secure. They get there by completely different routes, and which route a site takes was decided by whether its installer wrote enabled or unset into auto_update_core_major — which, as my companion post explains, depends only on whether the site was built before or after the WordPress 5.6 release.

The third row — minor updates switched off — is the one to worry about.

Backports arrive as minor updates

A backport is, by construction, a same-branch release. 6.8.7 to 6.8.8 doesn’t change the branch, so when the updater evaluates it, it takes the minor path:

// 4: Minor in-branch updates (3.7.0 -> 3.7.1 -> 3.7.2 -> 3.7.4).
if ( $current_branch === $new_branch ) {
    return apply_filters( 'allow_minor_auto_core_updates', $upgrade_minor );
}

Your security backports and your routine maintenance releases are the same channel. There is no separate security track, no way to accept only the urgent ones, and nothing that overrides your configuration because a fix is important.

So every one of these silently opts you out of security patches:

The first row is the one I would expect to catch people most often. If what you want is “patch me, but never move me to a new feature release,” the constant has a value for exactly that, and it isn’t false:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

That keeps minor and security releases flowing and blocks major ones outright. Reaching for false when you meant 'minor' is a plausible way a site that looks carefully managed stops receiving security fixes.

Version control is the other one worth calling out, because nobody sets it deliberately. Core scans for a repository directory and refuses to auto-update if it finds one — sensibly, since it doesn’t want to fight your deploy process. But it means a site deployed from Git receives no automatic security patches at all, forever, with no admin notice beyond an email for core updates. If that’s your setup, backports are your responsibility and nothing will remind you about it.

The git file gotcha: If WordPress sees stray .git files — unintentional, unnoticed remainders of an earlier version-controlled state — it will refuse auto-updates.

The blocker nobody sets: HTTPS

There’s one more gotcha!

When WordPress asks the .org API what’s available over the version-check endpoint, it builds an http:// URL, then upgrades it:

$url      = 'http://api.wordpress.org/core/version-check/1.7/?' . http_build_query( $query, '', '&' );
$http_url = $url;
$ssl      = wp_http_supports( array( 'ssl' ) );
if ( $ssl ) {
    $url = set_url_scheme( $url, 'https' );
}

And a few lines later, if that HTTPS request fails, it retries against $http_url — the plain-HTTP original.

The two endpoints do not return the same thing. Over HTTPS, a 6.8.7 site gets the five offers above. Over plain HTTP, it gets exactly one:

response=upgrade   current=7.1

No autoupdate entries at all! This makes complete sense as a security measure — WordPress.org will not tell a site over an unencrypted, tamperable channel which packages to silently install — but the consequence is stark. A site whose OpenSSL is broken, or whose egress firewall blocks HTTPS to api.wordpress.org, quietly receives an offer list containing nothing it will ever install automatically.

That site is not misconfigured in any way an admin would recognize. Its options are correct. Its constants are unset. Its filesystem is writable. No update-failure state is recorded, and the Updates screen shows a perfectly normal “please update” button. It simply never auto-updates again, including for security releases, and nothing anywhere in the system will tell you this. It is an uncommon failure — but where it happens, it is silent and total, and it persists until somebody thinks to look for it.

Two ways to end up there, and only one is obvious

The site can’t do SSL at all. wp_http_supports( array( 'ssl' ) ) returns false, so WordPress never attempts HTTPS — it goes straight to the plain-HTTP URL. Rare, and easy to detect.

The site can do SSL, but the request fails. An egress firewall, a proxy that breaks certificate validation, a stale CA bundle, a clock skewed enough to put certificates outside their validity window. WordPress tries HTTPS, gets a WP_Error, and falls back. This is the common trap — and the site remains, by every measure you would think to check — perfectly SSL-capable.

That distinction matters, because wp_http_supports() is a capability check, not a connectivity one. Follow it down, and it resolves to whether any HTTP transport could do SSL in principle — whether curl_version() reports CURL_VERSION_SSL, or whether the openssl extension is loaded. Nothing there touches the network. So the check you would naturally reach for returns true on a site in the second situation: it catches the rare failure and misses the common one.

Stop asking whether the site could reach WordPress.org securely, and look at what actually came back. If offers exist but none is flagged autoupdate, the site is on the HTTP endpoint:

wp eval '
delete_site_transient( "update_core" );
wp_version_check();
$t = get_site_transient( "update_core" );
$all  = count( (array) $t->updates );
$auto = count( array_filter( (array) $t->updates, fn( $u ) => "autoupdate" === $u->response ) );
printf( "%d offers, %d flagged autoupdate\n", $all, $auto );
'

On a healthy site behind on its branch, the second number is greater than zero. “Offers exist, but zero are flagged for automatic installation” is the signature.

The fallback isn’t quite as silent as it looks, either. It fires wp_trigger_error() first — at E_USER_WARNING when WP_DEBUG is on, E_USER_NOTICE otherwise — which on a production site means it lands in the PHP error log (if you keep one) and nowhere else. Find it with a grep:

grep -r "could not establish a secure connection to WordPress.org" /path/to/logs/

Know where the floor is

Backports don’t go back indefinitely. Of the 54 release branches in WordPress history, 25 currently have a secure tip. The other 29 — everything from 1.0 through 4.6 — have no patched release at all. Every version on those branches is marked insecure.

That includes 3.7, the branch that introduced automatic updates in the first place, and which WordPress backported to for many years. C’est la vie.

The practical consequence: if you are running something older than 4.7, there is no configuration that will help you. The patch you’d be waiting for doesn’t exist and isn’t coming. The only fix is to move to a branch that’s still being maintained, and you really, really need to do that ASAP.

A caveat on that number: 4.7 is what the data shows today. I’m reading it off the live API, not off a published support commitment, and the floor has moved before. Treat it as the current state rather than a promise — and re-check it rather than trusting this blog in a year, unless I update it!