WordPress 7.1.4 is a security release, and the flaw it fixes is already being exploited in the wild. The uncomfortable part is that on an unpatched site, the update itself is the attack window: WordPress unpacks the new files into a folder inside your web root and finishes installing them while still running the old, vulnerable code. Two habits close that window — take a backup, and block web access to wp-content/upgrade before you click Update.

The flaw is CVE-2026-119977, a time-of-check to time-of-use race in WordPress’s core upgrade process. It affects versions 4.7 through 7.1.3. WordPress shipped the fix on October 28, and CISA has since added the flaw to its known-exploited list after confirming attacks in the wild; Wordfence said it blocked 13,095 attempts against it in a single 24-hour stretch. This is not a theoretical hardening post.

The short version

• CVE-2026-119977 can give an unauthenticated attacker code execution during a core update. It is fixed in WordPress 7.1.4.
• Versions 4.7 to 7.1.3 are affected, and the patch was backported to older branches, so check what you are actually running.
• Blocking /wp-content/upgrade/ at the web server kills the attack without stopping the updater.
• Order matters: back up, block, update, verify. Blocking after the update is too late for that update.
• The plugin queue is bigger than the core queue — 549 plugin vulnerabilities were disclosed in a single week.

What the flaw actually does

When WordPress updates core with a full package, it downloads a complete copy of the new version and unpacks it into a temporary folder inside wp-content/upgrade/. That copy includes the installer. The folder lives under the web root, so the web server will happily serve files from it.

The temporary folder used to have a name an attacker could predict or find. So the sequence is: you start the update, WordPress writes the new files into a reachable folder, and an attacker who is polling for that folder loads the installer and completes an install before WordPress deletes the copy. That is code execution with no account and no password. The 7.1.4 fix gives the temporary folder a random name, so there is nothing left to guess.

Worth being honest about the shape of the risk: it is a narrow window and a high-complexity attack. It is not a drive-by. But narrow windows are exactly what automated scanners are built to hit, and “high complexity” stops meaning much when the scanning is free.

Who is actually exposed

• Sites on 4.7 to 7.1.3 that have not updated since October 28. That is the whole affected range, including old installs people forgot they own.
• Shared hosting, most of all. When WordPress cannot write core files directly, it falls back to the full-package upgrade — the exact code path this bug lives in.
• Anyone who turned off auto-updates and then stopped checking. Turning off auto-updates is a legitimate choice; turning off the calendar reminder that goes with it is not.

If you are already on 7.1.4 or newer, the flaw does not apply to you, but the habit still does. If your host patches for you, ask for the core version number rather than for reassurance — the answer is a version, not a feeling.

The five-minute update order

Do these in order. The block has to exist before the update runs, not after.

1. Back up the database and the files. A database export plus a tarball of the site directory. If you have never restored one, test the restore before you need it.
2. Block the upgrade folder at the web server. On nginx, add a location block that returns 403 for ^~ /wp-content/upgrade/. On Apache or LiteSpeed, add a rewrite rule in the site’s root .htaccess. This only refuses HTTP requests; PHP can still write to the folder, so the updater keeps working.
3. Update core. Dashboard → Updates → Update now, or from the command line with WP-CLI.
4. Verify. Confirm the version, verify core checksums, then load the homepage and the login page while logged out.
5. Leave the block in place. It costs nothing and closes the same trick in the next security release.

# 1. Back up before anything
wp db export ~/backup-$(date +%F).sql
tar czf ~/files-$(date +%F).tar.gz public_html

# 2. Block the upgrade folder (nginx), then reload nginx
#    location ^~ /wp-content/upgrade/ { return 403; }
#
#    Apache / LiteSpeed: put this above the WordPress block
#    in the site root .htaccess:
#    RewriteRule ^wp-content/upgrade/ - [F,L]

# 3. Update and verify
wp core update
wp core version
wp core verify-checksums

# 4. Plugin queue
wp plugin list --update=available
wp plugin update --all

If a host control panel runs updates for you and something breaks while the folder is blocked, remove the rule, run the update, and put it straight back. What you do not want is an update that starts, fails halfway, and leaves a half-unpacked copy sitting in a web-reachable directory while you go looking for the cause.

The plugin queue is bigger than the core queue

Wordfence’s weekly report for October 26 to November 1 counted 549 vulnerabilities across 351 plugins and 4 themes, including 17 critical and 132 high-severity disclosures. Forty-one had no patch at the time of disclosure. You cannot update your way out of those — the only move is to deactivate and delete.

A separate batch documented on November 9 covers 13 plugins, and four of them are common enough to check by name:

None of these plug straight into core, so they are not today’s headline. They are the reason “I updated WordPress” is not the same statement as “I patched my site”. A booking plugin with an authentication bypass is a worse day than a narrow core race condition, and it does not announce itself.

How to tell whether someone hit you during an update

Three checks, five minutes, no plugins required:

• Access logs. Search for requests to /wp-content/upgrade/, especially POSTs to an installer file from an address that is not yours. Reading access logs is the same skill as spotting a brute-force run, pointed at a different string.
• Administrator accounts. List the administrators and compare the registration dates against the day you ran the update. A new admin you did not create is the whole answer.
• Unexpected files. Anything ending in .php inside uploads, mu-plugins, or a leftover upgrade folder that you did not put there. This is part of the five-minute infection check.

If two of the three come back dirty, stop tidying and treat the site as compromised. Cleaning the symptom without finding the entry point is how a site gets reinfected a week later; the recovery order is: isolate, preserve evidence, rebuild from a known-good backup, then rotate every credential that touched the site.

The checklist I actually run

• Core version is 7.1.4 or newer on every site I am responsible for, including the one I forgot about in September.
• /wp-content/upgrade/ returns 403 from the public internet.
• A backup from the last seven days exists, and one restore has been tested this year.
• No active plugin has a published, unpatched vulnerability — those get deleted, not “monitored”.
• Access logs checked for upgrade-folder requests in the last 30 days.
• One admin account per person who actually needs it, and nobody’s old developer still on the list.

None of this is exciting, which is the point. Sites rarely get hurt because the owner lacked a clever security stack. They get hurt because a three-week-old security release looked like a maintenance chore, and the update window stayed open while nobody was watching.

Search Console is the only place Google tells you what it actually did with your site — which pages it indexed, which queries showed you, and whether a human reviewer took action against you. The setup that matters is short: one Domain property verified by DNS, one sitemap submitted, alerts going to an address you read, and a ten-minute check once a week. Everything else in the interface can wait until you have traffic worth analysing.

The short version

• Create a Domain property, not a URL-prefix property. One property covers http, https, www and every subdomain you own.
• Verify with a DNS TXT record and leave the record in place. Google re-checks it, and deleting it costs you access.
• Submit the sitemap WordPress actually generates — /wp-sitemap.xml on a stock install, /sitemap_index.xml with Yoast or Rank Math.
• Three reports are worth opening: Performance, Page Indexing, and Security & Manual Actions.
• Data lags a couple of days and new pages take weeks to be crawled. Check weekly, not hourly.

Pick the Domain property, not the URL prefix

Google offers two kinds of property. A URL-prefix property is tied to exactly one protocol, one hostname and one path: https://example.com does not include https://www.example.com, and neither includes http://. A Domain property covers all of them, plus every subdomain, because ownership is proved at the DNS level for the bare domain.

In the add-property screen, choose Domain, type the bare domain without https:// and without a trailing slash, and continue. Do not also create a URL-prefix property “just in case”: the two keep separate data and separate emails, so you end up watching two half-empty dashboards instead of one complete one.

If your DNS lives at Cloudflare, the record goes in the same place as everything else — the Cloudflare setup walkthrough covers the settings that break sites.

Verify with a DNS record and leave it alone

Google gives you a TXT value that looks like this. Copy it exactly, including the google-site-verification= prefix.

Type:  TXT
Name:  @            (the bare domain)
Value: google-site-verification=AbC123dEf456...
TTL:   Auto or 3600

In cPanel that is Zone Editor → Manage → Add Record → TXT. In Cloudflare it is DNS → Records → Add record, type TXT, name @. Save, wait a few minutes, then press Verify back in Search Console. When verification fails it is almost always one of three things: the record went on www instead of the root, the value was pasted with a smart quote or a line break from an email, or the DNS change has not propagated yet. Give it an hour before you start changing things.

The mistake I see most often is cleanup. Six months later someone tidies the DNS zone, deletes the “random TXT record”, and the property breaks. Google re-checks ownership periodically; when the record is gone, access goes with it. If you move nameservers, recreate the TXT record at the new provider before you flip the delegation.

The HTML-tag and Google Analytics verification methods are fine, but both are fragile in WordPress: a theme change can strip the tag from the header, and a plugin that removes the analytics snippet takes the property with it. DNS survives theme updates, plugin audits and migrations, which is why it is the one I use.

Submit the sitemap WordPress already builds

You do not need a sitemap plugin to start. Since WordPress 5.5 there is a built-in sitemap at /wp-sitemap.xml; if you run Yoast or Rank Math it is /sitemap_index.xml instead. Open the URL in a browser first — you should see XML, not a 404 and not a redirect to the homepage.

Then go to Indexing → Sitemaps, paste the full URL, and submit. The status column should read Success within a day or two. Couldn’t fetch usually means the URL redirects, robots.txt blocks it, or the response is HTML; fix that before submitting again, because repeated failures do not speed anything up.

Two more things worth doing once: add a Sitemap: line to robots.txt pointing at the same file, and open the sitemap index itself. A stock WordPress sitemap splits into posts, pages, categories and users, and if one of those child sitemaps errors the parent reports it as a warning. A sitemap is a hint, not a command: it tells Google where the URLs are and nothing more. Submitting the same file every day does not push a page into the index.

Read three reports and ignore the rest

Performance is the report people open first and the one most often misread. It shows queries, pages, countries and devices for a chosen date range, three months by default. Two cautions: the data lags by a couple of days, so yesterday always looks like a cliff, and “average position” is an average across every impression, not the position you see when you search from your own desk. Filter by page to see which queries actually feed one article.

Page Indexing is the honest one. It lists every URL Google knows about and why it is or is not indexed. The reasons are not equally urgent:

• Discovered – currently not indexed: Google knows the URL exists and has not crawled it yet. On a small site this is often just queue time. Internal links from pages that are already indexed help more than anything else.
• Crawled – currently not indexed: Google fetched the page and chose not to keep it. That is usually thin or near-duplicate content. Improve the page instead of requesting indexing every morning.
• Excluded by noindex: a setting, not a bug. Check the page source for the tag, then find the plugin or theme option that adds it.
• Alternate page with proper canonical tag: normal on paginated and tagged archives. Not an error.
• Duplicate, Google chose a different canonical: look at your canonical tags; on WordPress the usual culprits are archives and query strings.

Security & Manual Actions holds two sections that look similar and mean different things. A manual action is a person at Google deciding your site breaks the spam policies; a security issue is Google believing your site is hacked or serving malware. Both are emailed to verified owners and both are urgent. If either list is not empty, stop reading about search optimisation and deal with it — the five-minute infection check is the fastest first pass, and the recovery walkthrough is the order I would work in.

The weekly ten-minute check

Search Console emails you about manual actions and security issues. It will not email you when a page quietly drops out of the index, so put a recurring slot in the calendar and work through the same five items:

1. Page Indexing — did the “not indexed” count jump by more than a few pages? Open the reasons and look for a new one.
2. Performance — compare the last 28 days with the previous 28. Find one query or page that lost clicks and write down why.
3. Security & Manual Actions — confirm both sections are empty.
4. Sitemaps — status Success, with a recent “last read” date.
5. Settings → Users and permissions — once a quarter is enough; remove accounts you no longer control.

That is the whole routine. The reason to keep it boring is that the signals that matter — a page dropping out of the index, a query collapsing, a manual action — are visible within a week if you look, and invisible for months if you do not.

If you only do one thing this week: create the Domain property, paste the TXT record at your DNS provider, submit /wp-sitemap.xml, and put the ten-minute check on your calendar. Then go back to writing. Search Console rewards patience far more than it rewards fiddling, and once the property is verified and the sitemap is in, the only thing left to improve is the site itself.

When a WordPress site gets hacked, the visible symptom is usually the last thing to arrive. The real footprint is a handful of files, a couple of database rows, and one user account you did not create. If you know the six places to look, you can tell a hacked site from a broken one in about ten minutes — and you can do it without installing a security plugin.

Clean up a few of these and the pattern repeats: the same four directories, the same three tables, the same two persistence tricks. Attackers reuse what already works.

The short version

• Most infections live in wp-content/plugins, wp-content/mu-plugins, wp-content/uploads, and the active theme’s functions.php.
• mu-plugins is the favourite hiding place: files there load automatically and never appear in the Plugins screen.
• Core files usually get one or two lines changed, so run wp core verify-checksums before you trust anything else on the site.
• Check users and cron next. A rogue administrator or a scheduled event calling an outside URL is persistence, not just a symptom.
• Cleaning files without finding the entry point means you will be back here in three weeks.

Start with the file system, not the scanner

A scanner matches signatures; a hand-edited theme file that includes a remote script usually passes. These three structural checks are faster and do not depend on a signature database being current.

Run them from the WordPress root over SSH, or through your host’s file manager terminal.

# PHP files inside uploads — there should be none
find wp-content/uploads -type f -name '*.php'

# Everything modified in the last 30 days, newest last
find wp-content -type f -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM  %p\n' | sort

# Any PHP file that is world-writable, a common attacker trick
find . -type f -name '*.php' -perm -o+w

The first command should print nothing. Uploads is for images and documents; a .php file sitting next to your photos was put there by someone, and it is a backdoor.

The second command is a timeline: compare it with the dates you actually ran an update.

mu-plugins: the folder that loads and hides

This is the trick I see most often, and the one most site owners have never heard of. Anything in wp-content/mu-plugins loads on every request with no activation step and no entry in the Plugins list. Good hosts use it for a cache loader or an object-cache drop-in. Attackers use it for a single line of PHP.

ls -la wp-content/mu-plugins/

If you do not recognise a filename, read the first twenty lines. A real mu-plugin has a comment header and actual code. A malicious one is often a lone include of a file elsewhere, or one very long base64 string passed to eval, gzinflate or create_function. There is no legitimate reason for a plugin to decode a string and execute it.

Do not just delete the file. Note its name and look for the same string in the theme and in wp-config.php — a mu-plugin loader is usually called from two or three places so that removing one copy does nothing.

Fake plugins with real-looking headers

A dropped plugin differs from a real one in ways that survive a quick glance. It has a proper header block — Plugin Name, Version, Author — because that header is what makes the file a plugin at all. What it lacks is history: no changelog, no readme in the format WordPress expects, and an author URL on a recently registered domain.

wp plugin list --fields=name,status,version,update
ls -la wp-content/plugins/

Compare the two: the command lists what WordPress knows about, the directory shows what is on disk. A folder with no matching row was never installed through the admin — someone dropped it there. A plugin whose files all share one timestamp while the header claims an old version is not one anyone maintained.

Core files: one line is enough

Injections into core are small on purpose. A single line at the top of wp-settings.php or index.php, often wrapped in a check for a specific user agent or a cookie, is enough to serve a payload to Googlebot and nothing to you.

WordPress ships with checksums for every file in every release, and WP-CLI can compare your installation against them:

wp core verify-checksums

Clean output means no core file has been edited; warnings name the files that differ. Do not fix it by unpacking a fresh copy over a live site — read the diff first, then replace that one file from the official zip.

The database footprint: users, options, cron

Files get you access. The database is what keeps it. Three tables carry almost all of the persistence: wp_users, wp_options, and wp_usermeta with the serialised cron array.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list --fields=hook,next_run,recurrence
wp option get siteurl
wp option get home

On the user list, look at the registration date, not the name. Attackers pick names that blend in — wp_support, admin_backup, editor2 — but they appear on a date when you were not working. Every administrator should be a person you can name.

On the cron list, a hook with no plugin behind it is the tell. WordPress will happily schedule an event pointing at a function that a malicious mu-plugin defined; the event itself looks ordinary. If you cannot trace a hook to a plugin you installed, treat it as hostile.

For options, siteurl and home should be identical and should be the URL you expect. A mismatch is the classic way to keep an admin logged in on one hostname while sending visitors elsewhere.

Redirects and injected sitemaps

Some infections never add a PHP file. They edit .htaccess and add a rule that fires only for mobile user agents, or only for traffic arriving from a search engine. The page looks completely normal to you and redirects every visitor from Google to a casino.

Read .htaccess from the top. Rules inside <IfModule mod_rewrite.c> that reference HTTP_USER_AGENT, HTTP_REFERER, or a specific country code are not part of WordPress — the stock rules only rewrite to index.php.

The sitemap is the other quiet channel. Check /sitemap.xml and /wp-sitemap.xml against your post list. URLs you never published mean the injection is generating pages on the fly, usually only for a crawler carrying a Google referrer. That is exactly what happened when my own site was hit with Japanese keyword spam — the recovery steps are here.

Where to look, at a glance

Removing files is half the job

The other half is the entry point: an unupdated plugin, a reused password, or a theme that bundles “nulled” premium code. Locking down wp-login closes the front door; it does not remove a key already copied.

So after you clean the files: change every administrator password, change the database password, regenerate the WordPress salts in wp-config.php (which invalidates every existing login cookie), and revoke any FTP or SSH key you do not recognise. Then check your hosting account for extra FTP users — a leftover FTP account survives a full WordPress reinstall.

Be careful with the restore: if the last backup already contained the backdoor, restoring it puts you back where you started. Compare files against a known-good copy, not a snapshot from an infected week.

Then read the access log for the day the files changed — the request that wrote them is in there, with the IP and the path it used. That is how you find the entry point instead of guessing at it.

What to do today

Run the three file-system commands and wp core verify-checksums, and save the output to a file on your own machine. That file is your baseline: next time something feels wrong, run the same commands and compare. Ten minutes now beats an afternoon of wondering.