# Checksum Verification Closes the Gap Auto-Update Status Leaves Open ## Claim "Auto-update reported success" and "this install is actually patched" are different claims, and only checksum verification against trusted upstream artifacts closes the gap between them. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for any software that ships forced or automatic updates as a security promise — the promise is only as strong as the verification step behind it. - `wp core verify-checksums` runs before WordPress loads, which matters specifically because it doesn't depend on trusting already-compromised application code to report on itself. - Doesn't cover `wp-content` — premium and custom plugins/themes need separate vendor-artifact comparison, since core checksum verification has no visibility into them. - Breaks down if the checksum source itself is compromised or unreachable (e.g., a fully air-gapped or heavily proxied environment) — the technique assumes a trustworthy external reference point. ## Evidence The WordPress 7.0.2 chain's own incident guidance treats "forced auto-updates rolled out" as insufficient evidence of patch status: filesystem permissions, maintenance locks, and custom deploy pipelines can all silently block an update that the dashboard reports as successful. The article explicitly frames checksum verification as valuable *because* it doesn't depend on trusting code that may already be compromised — a self-report from a possibly-compromised system is not evidence. ## Links - [[3. Resources/Permanent Notes/Temporary Privilege Changes Require Re-Entrancy Guards]] — sibling claim from the same source: both are about not trusting a system's internal state without independent verification, applied to different layers (identity vs. patch status). - [[3. Resources/Permanent Notes/A Maintenance Release Earns Fast-Update Trust by Fixing Only Not Adding]] — extends: fast-update trust and verified-update trust are related but distinct; this note is about confirming the fast update actually landed. - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — applies-in: this is a concrete, runnable step for any hosting or agency incident-response runbook. - [[3. Resources/Permanent Notes/Restoring a Backup Restores the Entry Point]] — extends; that note names the same status-versus-reality gap on the restoration side of an incident: "the backup restored cleanly" is not "the hole is closed," just as "auto-update reported success" is not "this install is patched." - [[3. Resources/Permanent Notes/A Green Pipeline Proves the Stages Ran Not That the Deployed Build Behaves]] — has evidence from: A green pipeline reports that each configured stage exited cleanly. ## Tests / falsifiers - Audit a sample of sites that reported successful auto-update to 7.0.2/6.9.5/6.8.6 and independently run `wp core verify-checksums`; a non-trivial mismatch rate would confirm the gap this note describes. - Track whether hosting providers offering "we auto-update for you" as a security promise actually run a verification step, or only expose update-trigger telemetry. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/How Two WordPress Core Bugs Chained into Pre-Auth RCE]] — BugBunny.ai, 2026; incident-response guidance distinguishing update-triggered from checksum-verified.