# WordPress updated itself: what happened

> A security update pushed onto every installation doesn’t happen every year. When it does, it isn’t a precaution: it means the flaw could be exploited with no account and no password.

- Source canonique : [https://allaux.fr/en/securite/wordpress-s-est-mis-a-jour-tout-seul](https://allaux.fr/en/securite/wordpress-s-est-mis-a-jour-tout-seul)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Check the version number shown at the bottom right of the dashboard first, or under Dashboard then Updates. If the site displays « Briefly unavailable for scheduled maintenance », a .maintenance file has been left at the root: delete it over FTP and the site comes back. A white screen appearing the same day almost always comes from an incompatible plugin or theme, to be disabled one by one.

## What was fixed on 17 July 2026

If an email titled « Your site has been updated » arrived without you asking for anything, nothing has gone wrong. On 17 July 2026 WordPress released 7.0.2, 6.9.5 and 6.8.6, and WordPress.org switched on forced automatic updates for the affected versions. The official advice is one line long: update immediately.

Two flaws were patched. CVE-2026-60137 is an SQL injection enabled by the author__not_in parameter of WP_Query; it has been present since WordPress 6.8 and WordPress.org rates it critical. CVE-2026-63030 is a route confusion issue in the batch REST API, introduced in WordPress 6.9; WordPress.org rates it high and Tenable gives it a CVSS score of 9.8. Separately, two serious problems. Chained together, they allow unauthenticated remote code execution on 6.9.x and 7.0.x installations — no account, no password, no click required from an administrator. Tenable lists 6.8.0 to 6.8.5, 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1 as vulnerable.

Patchstack’s report on the state of WordPress security in 2026 puts the median delay between public disclosure and mass exploitation at five hours, and estimates that around half of high-impact vulnerabilities are exploited within twenty-four hours. Public proof-of-concept code appeared within hours of the 17 July disclosure, and real-world exploitation was confirmed by several teams, including Patchstack, in the days that followed. That is the whole reasoning behind a forced update: on that timescale, waiting for each site to update itself was not defensible.

## Signs of an update you didn’t ask for

- A WordPress email titled « Your site has been updated » around 17 July 2026, with no action on your side.
- A version number that changed in the dashboard although nobody pressed the update button.
- A blank screen, an error or broken layout appearing the same day, usually a plugin or theme that doesn’t get on with the new version.
- A site stuck on « Briefly unavailable for scheduled maintenance », meaning a .maintenance file was left behind.
- The opposite, and the case that should worry you: no email, no version change, and the site still running an older release.

## Checking in thirty seconds that you are on the fixed version

Only one question matters right now: which version is actually running. From the admin, the answer sits at the bottom right of the dashboard and under Dashboard → Updates. You should see 7.0.2, 6.9.5 or 6.8.6, or something released later. If you see 7.0.1, 6.9.4, 6.8.5 or anything older, the update never happened and the site is still on a vulnerable release.

On the command line, two commands do the job, and they read the version from the files rather than from an admin page that may be cached. The second one also queries the official update server and tells you whether anything is still pending.

## terminal — at the site root

```
wp core version
wp core check-update
```

## The site is stuck on an older version

1. **Check automatic updates haven’t been switched off** — The AUTOMATIC_UPDATER_DISABLED constant in wp-config.php, or WP_AUTO_UPDATE_CORE set to false, is enough to block any forced update. Some maintenance and optimisation plugins set the same thing without saying so plainly.
2. **Ask whether your host controls updates** — On a managed plan the host sometimes decides when updates land, after its own testing. The question to ask isn’t « why » but « when », and an acceptable answer is measured in hours.
3. **Check the core hasn’t been hand-edited** — Modified core files make updates fail, sometimes silently. And the version number on display proves nothing if someone edited the file holding it: when in doubt I compare the core files against an official archive of the same release.
4. **Free a site stuck in maintenance mode** — A .maintenance file left at the root after an interrupted update blocks the whole site. Deleting it is easy, but you then have to confirm the update actually completed, not merely that pages load again.
5. **Count every installation, not just the main one** — A multisite, a staging copy, an old install in a subfolder forgotten two years ago: those are the ones left on a vulnerable version, because nobody reads their email.
6. **Back up, then update by hand** — Full backup of files and database first, update second, from the dashboard or the command line. A broken plugin can be fixed afterwards; an open remote code execution cannot.

## The update closes the door, it doesn’t clear out what came in earlier

> Moving to a fixed version prevents fresh exploitation. It does not remove a file that was dropped, an administrator account that was created, or a scheduled task that was added while the door stood open. And it is worth being honest about what was known: as of 20 July 2026 there had been no public attribution and no specific indicators of compromise published. There is no filename or account to look for that would settle the question. Verification falls back on the general methods: unknown administrator accounts, files created or modified from 17 July 2026 onwards, unusual scheduled tasks, server access logs across that window. Interim measure cited by Tenable for installations that cannot be updated straight away: block /wp-json/batch/v1 at the web application firewall and monitor attempts against that endpoint.

## Related reading

- **Emergency security update** — Applying a forced update without breaking a live shop. ([/wordpress-woocommerce/mise-a-jour/urgence-securite](/wordpress-woocommerce/mise-a-jour/urgence-securite))
- **Recovering from a failed update** — If the forced update broke a plugin or the theme. ([/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee))
- **Checking whether your site is compromised** — The method to use when no precise indicator has been published. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **What to do within two hours** — The order of operations if you find more than just an update. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))

## FAQ

### I got the « Your site has been updated » email. Should I worry?

The email itself is good news: the update went through. What needs checking is that the site still behaves normally, and that nothing happened during the exposure window between the 17 July 2026 disclosure and the moment the patch landed.

### Can I undo this update or roll back?

Technically yes, and I strongly advise against it. Rolling back puts the site on a version vulnerable to unauthenticated remote code execution, with public proof-of-concept code in circulation. If a plugin broke, fix the plugin.

### My site runs 6.8.x — am I less affected?

Less, but not in the clear. The chain leading to code execution concerns 6.9.x and 7.0.x installations, but CVE-2026-60137 has been present since 6.8 and versions 6.8.0 to 6.8.5 are listed as vulnerable. The fixed release on that branch is 6.8.6.

### How do I know whether I was hit before the update?

By looking at what changed on the site from 17 July 2026 onwards: new administrator accounts, files created or modified, scheduled tasks added, unusual access logs. As of 20 July 2026 no specific indicator of compromise had been published, so there is no shortcut.

### Is a web application firewall enough in the meantime?

It is a stopgap, not a fix. Tenable cites blocking /wp-json/batch/v1 and monitoring attempts against that endpoint for installations that cannot be updated immediately. That buys hours, not weeks.