WordPress 7.0.4 landed on August 12, 2026 — a security-only point release that the core team says should be applied to all production sites immediately. We've been running the update across our managed client fleet this week, and we want to share exactly how we're handling it and what you should know before you click "Update Now."
What's in the release
WordPress 7.0.4 is a targeted security patch — no new features, no block editor changes, no admin UI tweaks. The core team flagged a single security fix as the sole contents of this release, following the same pattern as 7.0.2 earlier this summer.
At the time of writing, the full CVE disclosure hasn't been published in complete detail (that's standard practice — the core team waits a short window after release before publishing specifics so site owners have time to patch before exploit details are widely known). What we do know from the release announcement:
- One security vulnerability addressed — classified as requiring an immediate update for all sites running 7.0.x
- No database schema changes — the update does not touch the database, which meaningfully reduces upgrade risk
- No breaking changes to themes or plugins — this is a targeted patch, not a compatibility event
- Auto-updates eligible — sites with automatic background updates enabled for minor releases will have already received this patch without any manual intervention
If you're on 7.0.3 or any earlier 7.0.x version, you're unpatched. If you're still on 6.x, this specific fix doesn't apply, but you're carrying a different and growing set of exposure risks — that's a separate conversation worth having.
Our take
Security-only releases like 7.0.4 put agencies in a familiar position: the right answer is obvious (patch everything now), but the execution requires a little care so you're not creating new problems while solving the one Core flagged.
The urgency is real. When WordPress Core describes a release as "recommended that you update your sites immediately," that's not boilerplate. The project has a clear internal severity rubric, and security-only releases that hit all 7.0.x installs are sitting at the higher end. Our assumption is always that exploit code is being developed in parallel with the patch — the window between release and active exploitation in the wild has consistently shrunk over the past few years. We treat "update immediately" as meaning within 24–72 hours for all production sites, not "queue for the next sprint."
Auto-updates are your best friend here — if you've set them up. We configure every managed WordPress site to automatically apply minor releases (point releases like 7.0.4). If you're doing this too, most of your fleet probably already patched itself on August 12. That's exactly what minor-release auto-updates are for. If you haven't enabled auto-updates for minor releases yet, this is a good moment to reconsider. The argument against auto-updates ("something might break") is almost always weaker than the argument for them when we're talking about security-only patches with no schema changes.
The sites to watch are the ones with customized update workflows. Some of our clients operate environments where all deployments flow through a staging gate — no direct production pushes, even for minor updates. We respect that discipline, but it introduces a delay. For 7.0.4, we're recommending those clients compress the staging validation window to same-day: deploy to staging, run a 30-minute smoke test, promote to production. Don't run a full regression cycle for a patch this targeted.
Managed hosting platforms (Kinsta, WP Engine, Pantheon, Pressable) have already handled most of the heavy lifting. These platforms typically push security minor releases to their entire fleet within 24 hours of publication. If your clients are on managed WordPress hosting, verify in the dashboard that the update applied — but don't assume it hasn't just because no one mentioned it.
One honest caveat: without the full CVE detail published yet, we're working with incomplete information about the actual attack surface. That's not a reason to slow-walk the update — it's a reason to patch first and read the disclosure later. When the full details do publish, we'll update our assessment if anything changes the calculus.
What to do right now
If you manage WordPress sites directly:
- Log in to each site's dashboard and check the current version — 7.0.4 should already show as installed if auto-updates are on
- For sites still showing 7.0.3 or earlier, update now and note the timestamp for your records
- Run a quick smoke test post-update: admin login, front-end load, any critical form submissions, checkout if WooCommerce is present
- No database backup required before a patch-only minor update, but a full backup immediately before is never wrong if it takes under five minutes in your workflow
If you manage clients on managed WordPress hosting:
- Confirm in your hosting dashboard that 7.0.4 is active on all sites
- Send a brief update note to clients — something like "WordPress received a security update this week; we've confirmed it's applied to your site" goes a long way toward building trust and demonstrating active management
If you're still on WordPress 6.x:
This specific fix doesn't apply, but the gap between 6.x and 7.0's security baseline is widening with each release. Let's talk about your upgrade path before the gap becomes a liability.
Originally referenced: WordPress 7.0.4 Release on WordPress.org.
If you have WordPress sites you're not sure are patched, or you want to hand off managed updates so you're never in this position again — get in touch. Keeping production sites current is one of the most concrete things an agency relationship should guarantee.
