Verifying WordPress 7.1.4 Core and Plugin Updates Against the Unauthenticated RCE

WordPress 7.1.4 is a security release that fixes 22 flaws, one of them an unauthenticated remote code execution. That much comes from a single secondary report published 2026-10-29 and attributed to CyberSecurityNews. Everything else you would need in order to scope your own exposure — starting with which component the RCE lives in — is missing. This post is about what you can still do with that little: verify the 7.1.4 core update actually landed on every install you own, audit plugin and theme updates for compatibility and drift, and hunt for the persistence mechanisms an unauthenticated RCE in any CMS gets used for.

It is also the exact spot most site owners end up in — a headline, a version number, a maintenance window, and a decision to make before the details arrive.

My position, up front: patch to 7.1.4, but don't pretend you can detect exploitation of it yet. The report doesn't name the vulnerable component, the request path, or any preconditions. Anyone shipping an "IOC list" or a "7.1.4 WAF signature" right now is pattern-matching a headline, not code. What you can do today is confirm the patch actually landed on every install you own, prove nothing touched core files before or after, and scan for the persistence mechanisms an unauthenticated RCE in any CMS gets used for. That work is real, repeatable, and doesn't require knowing which function had the bug.

The rest of this post is that work, in order.

Why an Unauthenticated RCE in WordPress Is a Supply-Chain Event

The "~40% of the web" figure that follows every WordPress security release comes from continuous CMS usage tracking, most often cited from W3Techs' WordPress entry. Two corrections to how it usually gets used:

It's a share of all websites, not a count of exploitable installs. It includes wordpress.com, managed platforms that patch on their own schedule, and a long tail of sites with no reachable admin surface.
It measures the population that has to decide, not the population that's vulnerable. Real blast radius of a pre-auth RCE depends on whether the affected code path is reachable in a default config, which nobody has confirmed here.

What the number does legitimately imply is coordination cost. If roughly four in ten websites run the same codebase, a core security release becomes a synchronized event across an enormous number of independent operators: agencies with 200 client sites, shared hosts with thousands of tenants on a single PHP pool, managed WordPress platforms that stage releases behind their own change control. A bad patch rollout has a blast radius comparable to the vulnerability itself.

Plugin developers are on the critical path here despite not having shipped the bug. They can't test compatibility against 7.1.4 until 7.1.4 exists, and site owners can't safely update until the plugins they depend on are known to work. That produces a familiar compression:

Actor	What they need	When they need it
Core team	Ship the release	Done (7.1.4 exists)
Hosts / managed platforms	Stage and canary	Hours to days after release
Plugin developers	Test against 7.1.4, ship a compatible fix	Days
Site owners	Update core, then plugins	Now, in that order

The correct sequencing isn't "update everything at once." It's: update core, verify it, then update plugins — because a plugin that breaks under 7.1.4 is a known failure mode, and an unpatched pre-auth RCE is an unknown one.

What WordPress 7.1.4 Confirms, and What the Public Record Still Does Not

What the 7.1.4 Coverage Actually States

Narrow on purpose, because the source is a single secondary report.

Claim	Status
WordPress 7.1.4 exists and is a security release	Stated by the source report
It fixes 22 security flaws	Stated by the source report
One of those flaws is an unauthenticated RCE	Stated by the source report
It is described as mandatory for self-hosted WordPress	Stated by the source report
Report published 2026-10-29	Stated by the source report

Everything above is reported, not independently verified by me. Note also that "22 CVEs" isn't the same as "22 flaws" — the source says flaws. WordPress core fixes routinely ship without individual CVE identifiers, and nothing in the report establishes that 22 were assigned.

The Unknowns: CVE IDs, Affected Version Ranges, and Preconditions

These determine your actual risk, and none of them are in the record I have:

Which component the RCE lands in — core file handling, an image processing path, a REST endpoint, a bundled theme, or a serialization path. Untested; unknown.
Which versions are affected below 7.1.4.
Whether preconditions exist — a non-default PHP extension, a specific server configuration, a rewrite rule, or an enabled feature.
Whether the 22 includes bundled theme and bundled plugin fixes, which is common in WordPress releases and would change the priority ordering considerably.
Whether exploitation has been observed in the wild. No source in front of me says so.

⚠️

Do not fill these gaps with plausible-sounding values. A wrong "affected versions: 6.x–7.1.3" line in an internal ticket turns into a wrong scoping decision, and a wrong CVE id turns into a monitoring rule that never fires.

How to Read the Official 7.1.4 Changelog Without Over-Claiming

Primary sources, in order: the WordPress security release announcements, the Make WordPress Core posts around the release date, and the changesets in core Trac. What to extract:

The release post's fixed-issues list. Security releases typically enumerate issues with credit lines and a component description. If a component is named, you now have a real scoping input.
The props/credits block. Reporters get credited alongside the area they reported in, which narrows the component even when the prose is vague.
The diff between the previous tag and 7.1.4. Ground truth. If you run a mirror, git log --oneline between the two tags tells you which files changed — and a security-only release touches far fewer files than a normal one.

If the release post doesn't name the component, you're in the position this post assumes: verify the patch landed, then look for generic post-exploitation artifacts.

Triaging the 22 Fixes by Exploitability and Attack Surface

You'll get a list eventually. When you do, the ranking rubric matters more than the list.

Reasoning About the Unauthenticated RCE's Preconditions from the Sink Up

Pre-auth RCE in WordPress core is rare, and the rarity tells you something: core's request handling is heavily reviewed, so serious bugs historically cluster in a few areas — file upload and image handling, archive/PHAR deserialization, $wpdb prepare misuse that becomes injection combined with a gadget, REST callbacks with permissive permission_callback values. I'm not claiming 7.1.4's bug is in any of these. I'm saying those are the categories to think in while the advisory is thin.

Reasoning chain for any reported pre-auth RCE:

Is the sink a code-execution primitive? eval, include/require on an attacker-influenced path, call_user_func with an attacker-chosen callback, unserialize on attacker data, system/exec/popen.
Is the source attacker-controlled and pre-auth? $_GET, $_POST, $_COOKIE, php://input, multipart filenames, headers.
Is there a gate you're missing? A nonce check that's actually enforced, a capability check, a current_user_can call earlier in the stack.
Is that path reachable on your installs? This is where a lot of theoretical severity evaporates: a REST route that requires a plugin to register it, a feature disabled by your host, a rewrite rule that never matches.

Pre-Auth and Low-Privilege Vectors That Rank Next

Below the RCE, rank by privilege required and reachability:

Unauthenticated, default config — top of the list, patch immediately.
Unauthenticated but requires a non-default feature — high, but check whether you even have it enabled.
Subscriber-level — high in practice, because self-registration is common and subscriber is often treated as "not a user."
Contributor-level — meaningful on multi-author sites; less so on a brochure site with one admin.

Authenticated, Contributor-Level, and Admin-Only Issues Rank Last

Admin-only issues get mis-ranked in both directions. An admin-only XSS isn't nothing — it's a privilege-escalation primitive once you pair it with a CSRF or a malicious plugin — but it isn't a pre-auth RCE, and treating it like one trains your team to ignore severity labels.

Building a Triage Table When the Advisory Is Thin

Build the table with explicit placeholder semantics. The row below is a template, not data — swap in real advisory content when you have it.

Fix	Privilege required	Internet-reachable by default	Component	Priority
(example) Unauthenticated RCE	none	unknown	unknown	P0 — patch now
Fix 2	contributor	yes	REST	P2
Fix 3	admin	yes	admin UI	P3
Fix 4	none	unknown	unknown	P1 — assume reachable

The discipline that matters: for every row you can't fill, write "unknown" and assign the higher priority. Unknown-reachable is treated as reachable until proven otherwise. Uncomfortable, and correct.

Staging the Core Update Without Losing the Ability to Roll Back

Rollback is what separates "we patched" from "we patched and we can prove we didn't break anything." Get it in place before wp core update runs.

Snapshotting Files and the Database Before the Core Update

cd /var/www/example.com
STAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p /var/backups/wp/$STAMP

wp db export /var/backups/wp/$STAMP/db.sql --add-drop-table
tar -czf /var/backups/wp/$STAMP/wp-content.tar.gz wp-content
tar -czf /var/backups/wp/$STAMP/core.tar.gz --exclude=wp-content .
cp wp-includes/version.php /var/backups/wp/$STAMP/version.php.before

Three things people forget:

wp-content separately from core. You roll back core far more often than you roll back uploads, and a combined tarball makes the restore unnecessarily scary.
The database, every time. A core update can trigger wp core update-db, and restoring files won't undo a schema change.
version.php on its own. It's the authoritative record of what was running when you took the snapshot, and it's the first thing you want when reconciling two installs that "should" be identical.

Capturing a Checksum Baseline of the Current Install

Run pre-update verification before you update. If the install is dirty now, you need to know it was dirty before, or you'll spend the post-update window chasing your own drift.

wp core verify-checksums; echo "exit=$?"
find . -type f -not -path './wp-content/uploads/*' -print0 \
  | sort -z | xargs -0 sha256sum > /var/backups/wp/$STAMP/baseline.sha256
wc -l /var/backups/wp/$STAMP/baseline.sha256

Success: WordPress install verifies against checksums.
exit=0
14872 /var/backups/wp/$STAMP/baseline.sha256

Those are the shapes these commands actually emit — the file count is yours, not mine. If your pre-update run does not verify, stop and read the next section before going further; you may be updating a compromised install.

Freezing Deploys and Plugin Auto-Updates During the Window

Freeze the things that move underneath you, and only for the window:

wp config set AUTOMATIC_UPDATER_DISABLED true --raw
wp plugin list --fields=name,status,auto_update

AUTOMATIC_UPDATER_DISABLED suppresses background updates so your wp core update is the only change in flight; otherwise you can't attribute post-update breakage to anything. The trade-off is real: you're disabling the mechanism that would have patched you. Set a calendar reminder to flip it back the same day, and note the exception in your change record.

A core-file modification freeze — DISALLOW_FILE_MODS — is the wrong tool here, because it also blocks the update you're trying to run. Use it after the update, if at all.

Updating WordPress Core and Proving the Update Took

The WP-CLI Update Sequence with Verification Output

wp core check-update
wp core update --version=7.1.4
wp core update-db
wp core version

wp core check-update renders a table with version, update_type, and package_url. On a security release the update_type column reads security, which is a cheap confirmation that you're looking at the right release and not a stale transient:

+---------+-------------+-------------------------------------------------------------+
| version | update_type | package_url                                                 |
+---------+-------------+-------------------------------------------------------------+
| 7.1.4   | security    | https://downloads.wordpress.org/release/wordpress-7.1.4.zip |
+---------+-------------+-------------------------------------------------------------+

If that table is empty and you believe 7.1.4 exists, your update transient is stale. Clear it and retry:

wp transient delete update_core
wp core check-update

Reading wp core verify-checksums Correctly, Including False Positives

wp core verify-checksums compares your files against the manifest for your exact version and locale. It's the strongest single verification signal you have, and it produces false positives constantly.

Result	Common cause	Real problem?
`File doesn't exist: wp-config-sample.php`	Hardening removed it	No
`File doesn't exist: readme.html`, `license.txt`	Hardening removed them	No
Checksum mismatch on a core file	Host applied a hotfix, or a WAF vendor patched core	Maybe — investigate
Checksum mismatch on many files	Wrong locale compared against	No — pass `--locale=`
Extra files reported	`.DS_Store`, editor backups, stray archives	Usually no
Missing files across `wp-admin/`	Partial upload or failed extraction	Yes — reinstall

The locale case wastes the most time. Run a non-English install with checks against the en_US manifest and you get a wall of mismatches that means nothing:

wp core verify-checksums --locale=de_DE

A second limitation worth internalising: checksums only tell you about files that are supposed to be there. A backdoor dropped in wp-content/uploads/2026/10/x.php, or an edited wp-content/mu-plugins/loader.php, is invisible to this check. That's why the post-patch scan below is a separate step and not a bonus.

Confirming the Running Version from the Filesystem, Front End, and Database

Three independent confirmations, plus one correction to the usual advice.

## 1. Filesystem — authoritative
wp core version
grep "^\$wp_version" wp-includes/version.php

## 2. Front end — often absent, because plenty of themes/plugins strip it
curl -s https://example.com/ | grep -o '<meta name="generator"[^>]*>'

7.1.4
$wp_version = '7.1.4';
<meta name="generator" content="WordPress 7.1.4" />

Correction: the WordPress core version is not stored in the database. There's no wp_options row you can read to learn what core version is running; core reads wp-includes/version.php on every request. What is in the database is the schema version:

wp db query "SELECT option_name, option_value FROM wp_options
             WHERE option_name IN ('db_version','_site_transient_update_core');"

db_version tells you whether wp core update-db completed. _site_transient_update_core tells you what the site currently believes about available updates — the thing that goes stale and lies to you. Use it to confirm update state, not update version.

If you need a version check that doesn't depend on the install's own code being honest (relevant when you suspect compromise), fetch the file directly and hash it, or compare against the release zip:

curl -sSL https://downloads.wordpress.org/release/wordpress-7.1.4.zip -o /tmp/wp-7.1.4.zip
unzip -p /tmp/wp-7.1.4.zip wordpress/wp-includes/version.php | grep wp_version

What an Unclean Verification Result Tells You

Split the result into three buckets and act accordingly:

Cosmetic drift (removed sample files, editor backups, .DS_Store): record it, move on.
Core file modified but functionally intact (a host hotfix): identify the diff. If you can't explain it, treat it as a compromise indicator — a modified core file is exactly what a competent attacker leaves behind.
Missing or truncated core files: reinstall the version cleanly rather than hand-patching. wp core download --version=7.1.4 --force re-extracts core without touching wp-content.

Auditing WordPress Plugins and Themes After Core Ships

Inventorying Everything That Runs in the Request Path

wp plugin list doesn't cover everything that executes. Get the whole picture:

wp plugin list --fields=name,status,version,update,update_version --format=table
wp theme list --fields=name,status,version,update --format=table
ls -1 wp-content/mu-plugins/ 2>/dev/null
ls -1 wp-content/ | grep -E '^(object-cache|advanced-cache|db|maintenance|sunrise)\.php$'

Must-use plugins and drop-ins run on every request and are the least visible part of the stack. A mu-plugins/ directory left behind by a previous agency, with a loader that includes from an undocumented path, is a genuine blind spot.

Prioritizing Abandoned, Unmaintained, and Low-Install Plugins

Three signals, most useful first:

Last updated date from the plugin API. Two years untouched is a liability regardless of this release.
tested up to — if it claims compatibility with a version several majors back, you're the test suite now.
Install count — not because popular means secure, but because unpopular means nobody has looked.

The plugin API gives you all three without installing anything:

curl -s 'https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=akismet' \
  | jq '{version, last_updated, requires, tested, active_installs}'

{
  "version": "5.3.1",
  "last_updated": "2026-09-14 22:11:03",
  "requires": "6.5",
  "tested": "7.0",
  "active_installs": 5000000
}

Swap the slug for your own plugin names. A tested value below your new core version is a flag, not a verdict — nobody has published a compatibility claim, so you own the testing.

Verifying Plugin Checksums Against the wordpress.org Plugin API

wp plugin verify-checksums --all

Success: Verified 14 of 17 plugins.
Warning: Could not find akismet in the WordPress.org plugin directory.
Warning: Could not find acme-pro in the WordPress.org plugin directory.
Warning: Could not find site-customizations in the WordPress.org plugin directory.

Premium and private plugins can't be verified this way — there's no manifest to compare against. That's not a failure of the tool, it's a gap you close with your own hashes. For those, compare against your pre-update baseline:

sha256sum -c /var/backups/wp/$STAMP/baseline.sha256 2>/dev/null | grep -v ': OK$'

Every line of that output is a file that changed outside a package manager. Most will be logs, caches, and uploads you excluded. The ones that aren't are the interesting ones.

Deciding Between Updating, Removing, and Accepting Residual Risk

Update when there's a compatible release and the plugin is in the request path.
Remove when the plugin is inactive. An inactive plugin is still a file tree on disk, and some vulnerable plugins are exploitable via direct file access even when deactivated. Deleting is free.
Accept residual risk only with a written expiry date and a named owner. "We'll deal with it later" isn't a decision; "we accept this until the vendor ships in Q1, reviewed by X on this date" is.

Post-Patch Integrity Scan: Finding What the Patch Did Not Remove

Patching closes the door. It doesn't remove anyone already inside.

Files That Should Never Change in a Core Install

After a successful update, re-run the baseline comparison. In a clean install, wp-admin/, wp-includes/, and root PHP files should differ from your pre-update baseline only as a result of the update itself. Anything else is a finding.

wp core verify-checksums
find wp-admin wp-includes -name '*.php' -newermt '2026-10-29' -ls

The second command is deliberately coarse. On a normal update it lists hundreds of files — expected, the update touched them. What you're looking for is a file dated after the update completed.

Searching for Injected PHP in uploads/ and Drop-In Locations

## PHP anywhere under uploads is almost always wrong
find wp-content/uploads -type f -name '*.php' -ls

## Recently written PHP anywhere outside the update window
find wp-content -type f -name '*.php' -newermt '2026-10-30' -ls

## Common obfuscation primitives in drop-ins and mu-plugins
grep -rInE '(eval|assert|create_function|base64_decode|gzinflate|str_rot13|preg_replace)\s*\(' \
  wp-content/mu-plugins wp-content/*.php 2>/dev/null

Drop-in filenames worth checking by name, because they load before plugins and rarely get reviewed: advanced-cache.php, object-cache.php, db.php, db-error.php, maintenance.php, sunrise.php, wp-tmp.php, and the multisite variants blog-deleted.php, blog-inactive.php, blog-suspended.php.

A hardened install should have no PHP under uploads/. If uploads is writable and your web server will execute PHP from it, a single uploaded file is a full shell. Fix the server config, not just the file.

Database Checks: Rogue Administrators, active_plugins, and Autoloaded Options

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp option get active_plugins --format=json
wp db query "SELECT SUM(LENGTH(option_value)) AS autoload_bytes
             FROM wp_options WHERE autoload='yes';"
wp db query "SELECT option_name, LENGTH(option_value) AS len FROM wp_options
             WHERE autoload='yes' ORDER BY len DESC LIMIT 20;"

Three things to look for:

An administrator you can't explain. Check user_registered against what you know of the site's history; an admin created at 03:00 on a Sunday is a finding.
active_plugins containing an entry with no corresponding directory — a common trick is to register a plugin path a later request recreates.
Autoloaded option bloat. An autoloaded option carrying a large serialized payload is a known persistence shape. autoload_bytes in the multi-megabyte range on a site with a modest plugin list deserves a look.

Cron Entries and Scheduled Tasks as a Persistence Surface

wp cron event list --fields=hook,next_run_relative,recurrence
wp option get cron --format=json | jq 'to_entries[] | {hook: .key, cb: (.value[0].callback // "unknown")}'

WordPress cron callbacks are stored as serialized arrays. An entry whose callback isn't a recognizable function name — or that points at a file in uploads/ — is worth investigating no matter what the hook is called. Also check system cron and the host's scheduler; persistence often lives one layer below WordPress.

Hunting for Exploitation Attempts in Logs and Telemetry

Request Patterns Worth Grepping For in Access Logs

Be honest about what this is: heuristic hunting, not signature matching. With the vulnerable component unnamed, you can't write a detection for this vulnerability. What you can do is find the generic pre- and post-exploitation traffic that accompanies almost any web-shell drop.

## Top requested paths — look for outliers
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -40

## Requests that hit PHP directly under uploads
grep -E 'wp-content/uploads/[^ ]*\.php' access.log | head -50

## Successful POSTs to pre-auth entry points
grep -E '"POST /(wp-login\.php|xmlrpc\.php|wp-admin/admin-ajax\.php|wp-json/)' access.log \
  | awk '$9 ~ /^2/' | wc -l

## Traversal and encoding tricks in the query string
grep -Ei '(%2e%2e|\.\./|%00|base64|eval\(|php://input)' access.log | head -50

Field positions vary by log format — check $7 and $9 against a known line before trusting an aggregate. And weight by outcome: a thousand 404s against /wp-content/uploads/shell.php means someone was scanning; one 200 means someone succeeded.

Server-Side Indicators: Unexpected Child Processes and Outbound Connections

ps -eo pid,ppid,user,etime,cmd --sort=start_time \
  | grep -E '(php|sh -c|curl|wget|nc )' | grep -v grep | head -40

ss -tunp | grep -vE ':(80|443)\b'

What you're looking for: a PHP-FPM child alive for hours when your workers normally recycle in seconds, a sh -c process with a web-server parent, or an outbound connection from a web process to an address that isn't one of your documented integrations.

When to Treat the Site as Compromised Rather Than Patched

Treat as compromised, not patched, when any of these is true:

A core file differs from the manifest and you can't attribute the difference to your host or your own tooling.
PHP exists under uploads/ and the web server can execute it.
An administrator account exists that no one will claim.
A cron callback resolves to a file rather than a function.
There's an unexplained outbound connection from a web worker.

In those cases the patch isn't the fix, it's the first step. Rotate credentials, rebuild from known-good artifacts, and don't try to clean a shell you haven't fully mapped.

WAF Rules as a Bridge, Not a Fix for an Unnamed RCE

What a WAF Can Realistically Block for This Vulnerability Class

A WAF sits in front of code it doesn't understand. For a pre-auth RCE with an unknown request shape, that means it reliably does the generic things and unreliably does the specific one:

Can block reliably	Cannot block reliably
Direct access to PHP under `uploads/`	A payload that looks like a legitimate admin-ajax request
Obvious traversal in paths	Encoded payloads inside a valid multipart upload
Known-bad scanner fingerprints	A bespoke exploit against a route you allow
Bulk credential stuffing	Anything reaching a REST callback you permit

The highest-value rule during this window is blocking direct execution of PHP in wp-content/uploads/. It's cheap, it has essentially no false positives on a healthy install, and it converts a common post-exploitation step into a 403.

Virtual Patching Hygiene, Rule Drift, and Expiry Dates

Tag every rule with the advisory or release it responds to. Six months from now, an untagged rule is one nobody dares delete.
Set an expiry date at creation. A rule written for 7.1.4 with no sunset becomes permanent attack surface.
Log before you block on anything touching admin-ajax.php or /wp-json/, where legitimate traffic is highly variable.
Measure false positives weekly. A WAF rule that breaks a client's checkout gets disabled by someone under pressure, and then it protects nothing.

The honest position: a WAF is a bridge across the days between "core shipped" and "every install in my fleet is on 7.1.4." It isn't a substitute for the last mile, and treating it as one is how fleets end up six months behind.

Hardening the Window Between Release and Full Rollout

Credential and Secret Rotation Plus Session Invalidation

If there's any chance an install was reachable while unpatched, assume session material is suspect. Rotating salts invalidates every auth cookie at once:

wp config shuffle-salts
wp user session destroy admin --all
wp user list --role=administrator --field=user_login \
  | xargs -I{} wp user session destroy {} --all

shuffle-salts is the blunt instrument — it logs out everyone, including you. That's usually the correct trade during a security window. Rotate database credentials, any API keys stored in wp-config.php, and integration tokens at the same time; an attacker who read wp-config.php has all of them.

Reducing Pre-Auth Attack Surface on Internet-Facing Installs

wp config set DISALLOW_FILE_EDIT true --raw
wp config set DISALLOW_FILE_MODS true --raw   # after updates are done

Plus, at the server layer: deny direct PHP execution under uploads/, restrict /wp-json/ to the routes you actually serve if you aren't running the block editor or a headless front end, and disable XML-RPC if nothing depends on it. Each removes a pre-auth path that exists independently of this release.

💪

Do these changes on staging first and watch the error log for 24 hours. XML-RPC and REST restrictions are the two that break things quietly — a mobile app or a Jetpack-style integration fails days later, not immediately.

Coordinating with Hosts and Managed-Platform Update Schedules

On managed WordPress hosting, ask two specific questions and write down the answers: which 7.1.4 build is being deployed, and what's the rollout date for your plan tier. "We're on it" isn't an answer you can put in a change record. If the platform stages over a week, your WAF bridge needs to last a week, and your plugin updates shouldn't race the platform's core update.

For Plugin Developers: Shipping a Fix Compatible with 7.1.4

The 7.1.4 Assumptions Your Plugin Code May Silently Rely On

Security releases change internals with less ceremony than feature releases. I can't tell you which internals changed in 7.1.4 — that needs the diff — but I can tell you how to find out and which class of assumptions breaks:

git clone --bare https://github.com/WordPress/WordPress.git wp-core.git
cd wp-core.git
git log --oneline 7.1.3..7.1.4 -- wp-includes/
git diff --stat 7.1.3..7.1.4 -- wp-includes/ wp-admin/includes/

The assumptions that break most often:

Escaping and sanitization behaviour on functions your plugin passes unescaped data through.
Capability and nonce enforcement that got tightened, so a request that used to pass now 403s.
REST schema and permission_callback handling, where a previously tolerated null callback becomes a hard error.
Deprecation notices escalating to behaviour changes under WP_DEBUG.

Capability Checks, Nonces, and REST permission_callback Values

The most common plugin-side RCE enabler isn't a missing esc_html. It's this:

register_rest_route( 'acme/v1', '/import', [
    'methods'             => 'POST',
    'callback'            => 'acme_import_handler',
    'permission_callback' => '__return_true', // pre-auth by construction
] );

__return_true on a route that touches the filesystem is an unauthenticated file-write primitive with extra steps. The correct shape:

register_rest_route( 'acme/v1', '/import', [
    'methods'             => 'POST',
    'callback'            => 'acme_import_handler',
    'permission_callback' => function ( WP_REST_Request $request ) {
        if ( ! current_user_can( 'manage_options' ) ) {
            return new WP_Error( 'forbidden', 'Insufficient capability', [ 'status' => 403 ] );
        }
        // Nonce is enforced by the cookie auth layer for authenticated requests,
        // but validate explicitly if you also accept header-based auth.
        return true;
    },
    'args' => [
        'target' => [
            'required'          => true,
            'validate_callback' => function ( $value ) {
                return is_string( $value ) && ! preg_match( '#\.\./|^/#', $value );
            },
        ],
    ],
] );

Two rules: any handler that writes to disk validates its path against an allowlist, never a denylist; and any handler that calls include or unserialize gets a capability check with no exceptions.

Testing Against Both Patched and Unpatched Core in One Matrix

A compatibility matrix that only tests 7.1.4 tells you half the story — you also need to know whether your fix works on the versions your users are still running.

## Two throwaway installs, one per core version
for V in 7.1.3 7.1.4; do
  wp core download --version=$V --path=/tmp/wp-$V --force
  wp core verify-checksums --path=/tmp/wp-$V
  wp plugin install my-plugin --path=/tmp/wp-$V --activate
  wp eval 'echo "core=" . get_bloginfo("version") . PHP_EOL;' --path=/tmp/wp-$V
done

Run your integration suite against both. A test that fails on 7.1.4 only is a compatibility break you'd otherwise have shipped into thousands of sites at the worst possible moment. One that fails on 7.1.3 only means your fix silently requires the patched core — document that, because users on a frozen version will not read the changelog.

A WordPress 7.1.4 Verification Checklist You Can Run Today

#	Check	Command	Pass condition
1	Core version on disk	`wp core version`	`7.1.4`
2	Checksums clean	`wp core verify-checksums`	`Success`, or only cosmetic drift
3	Update transient honest	`wp transient delete update_core && wp core check-update`	Reports `security` type
4	DB schema current	`wp db query "SELECT option_value FROM wp_options WHERE option_name='db_version'"`	Matches release expectation
5	No PHP in uploads	`find wp-content/uploads -name '*.php'`	Empty
6	Drop-ins reviewed	`ls wp-content/*.php wp-content/mu-plugins/`	All accounted for
7	Admin users known	`wp user list --role=administrator`	Every account claimed
8	Plugins verified	`wp plugin verify-checksums --all`	Only premium plugins unverified
9	Inactive plugins removed	`wp plugin list --status=inactive`	Empty, or justified
10	Cron reviewed	`wp cron event list`	No unknown hooks or file callbacks
11	Sessions invalidated	`wp config shuffle-salts`	All users re-authenticated
12	WAF bridge live with expiry	Rule tagged with release + sunset date	Dated in the ticket

Run 1–4 immediately after the update. Run 5–11 within 24 hours. Item 12 only matters if your fleet can't reach 7.1.4 in that window.

What Would Change This Assessment of 7.1.4

I've written this as "patch urgently, verify thoroughly, don't believe anyone's detection signature yet." Three developments would change that:

If the advisory names an unauthenticated, default-configuration path — say, a request to a core file every install exposes — then this moves from "P0, patch today" to "P0, patch today and assume compromise for anything reachable in the last N days." The response changes from verification to incident response.
If the advisory shows the RCE requires an authenticated user or a non-default plugin — then site-owner urgency softens considerably, and plugin developer urgency rises, because the vulnerable surface is in code you control.
If public exploitation is confirmed — the priority ordering in the triage table collapses; everything becomes "patch, then hunt."

What would not change it: another outlet repeating the same headline. Two articles citing one report is still one source, and the details that would let you scope your exposure — component, versions, preconditions — are the details nobody has published.

Until they are, the checklist above is the work. Not glamorous, and the only part of this you can actually prove.

Introduction