WordPress 7.0.4 is a security update released on August 12, 2026. WordPress recommends updating immediately because the release fixes an authenticated Author-or-higher file-upload issue on sites that use both Imagick and Ghostscript.
The important word is authenticated. The issue does not mean every outdated site was hacked. It means a person who already had an Author, Editor, or Administrator account could abuse a specific media-processing path when the server met the stated conditions.
Use this guide to answer three owner questions: Does the update apply to my site? What should I check after updating? When should I stop normal maintenance and ask for incident-response help?
The facts below come from the official WordPress 7.0.4 release notice and WordPress version documentation. This guide explains safe verification without reproducing an exploit or asking you to test dangerous files on a live website.
Does the WordPress 7.0.4 issue affect your site?
Check the conditions in this order. A version number alone cannot tell you whether somebody misused the issue.
| Question | What the answer means | Safe next action |
|---|---|---|
| Is WordPress older than the fixed release for its branch? | The security update still applies. WordPress 7.0 sites should move to 7.0.4. | Record the current version, take a usable backup, and update promptly. |
| Can anyone besides trusted staff publish media as an Author, Editor, or Administrator? | The official issue requires an authenticated Author-or-higher account. | Review privileged users, recent role changes, application passwords, and login history. |
| Does the server process images with Imagick and Ghostscript? | The official notice names this media stack as part of the affected condition. | Ask your host or developer to confirm the active image-processing stack. Do not upload a test payload. |
| Do recent uploads, accounts, logs, or files look unfamiliar? | An independent warning may justify a deeper review. It still needs correlation. | Preserve the evidence and escalate before deleting users, files, or logs. |
A site with no untrusted Author-or-higher accounts has a smaller practical exposure path, but it should still install the security update. Stolen credentials, old staff accounts, and role changes can alter the answer.
Update first, then prove the site still works
WordPress says sites that support automatic background updates will begin updating. Do not assume that yours completed successfully. Open Dashboard > Updates and confirm the installed version.
Use this short update sequence for a business site:
- Record the current WordPress version and update time.
- Confirm that a recent backup contains both files and the database.
- Install the fixed release from the normal WordPress update screen or your managed update process.
- Clear page, object, and CDN caches after the update completes.
- Test the homepage, wp-admin, forms, checkout, search, login, media uploads, scheduled jobs, and outbound email.
- Check the public source for the expected canonical URL and normal index settings.
If the update fails or the site shows a critical error, capture the message and stop repeating the same update. Do not leave a vulnerable version online simply because a rollback restored the page. A controlled recovery should identify the compatibility problem, apply the security fix, and retest the important workflows.
Build a short security timeline
Write down four times before changing anything else:
- The time the site installed WordPress 7.0.4 or another fixed branch release.
- The completion time of the last known-good backup.
- The first unusual traffic, error, email, upload, or account event shown by monitoring.
- The most recent expected code or configuration change made by an administrator.
Hosting activity logs, WordPress update emails, backup history, deployment records, and audit logs can help. Use UTC or one clearly labelled time zone throughout. Mixed time zones make server and WordPress events harder to compare.
Do not immediately delete a suspicious user or file if the site can remain safely contained. Record the name, timestamp, role, path, and related log entries first. That evidence can separate an incident from a legitimate deployment.
Run these seven checks after WordPress 7.0.4
1. Review Author, Editor, and Administrator accounts
List every account with permission to upload and publish media. Confirm the person, email address, role, and whether the access is still needed. Check recent role changes, password resets, new-user emails, application passwords, and login locations where your tools record them.
Pay special attention to old contributor accounts promoted to Author, shared editorial logins, and accounts that belonged to former staff or agencies. Remove unnecessary access through a controlled process. If anything looks wrong, preserve the audit record, suspend the access path, and rotate credentials from a trusted device.
2. Review recent Media Library activity
Check uploads made by privileged users around the patch window. Look for files with an unexpected type, extension, owner, timestamp, or location. Compare questionable items with the content calendar and the person who supposedly uploaded them.
Do not download or execute an unknown file on your own computer. Do not create a malicious sample to see whether the old version was vulnerable. Preserve the record and ask a security professional or host to inspect it in an isolated environment.
3. Verify WordPress core and executable files
Compare WordPress core files with the official checksums for the installed version. WP-CLI can perform this comparison without replacing files. A failed checksum does not automatically prove a breach because some hosts add legitimate files, but every unexpected difference needs an explanation.
Review recently modified PHP files in the WordPress root, wp-admin, wp-includes, active plugins, active themes, and must-use plugins. The uploads directory should normally contain media, not executable PHP. Treat an unexpected executable file there as a containment issue rather than a routine cleanup task.
4. Check plugins, themes, and hidden loading paths
Confirm that every active and inactive plugin came from an approved source. Flag abandoned, nulled, unknown, or recently added components. Inspect must-use plugins, drop-ins, and hosting-specific loaders as well as the ordinary Plugins screen.
Files such as object-cache and advanced-cache drop-ins can be legitimate. Their source, owner, and modification time should still match the stack you intended to run. Compare active theme files with your repository, vendor package, or known-good deployment.
5. Review access and error logs
Search the patch window for unexpected administrative requests, repeated login failures followed by success, unusual REST activity, PHP errors from unfamiliar paths, and outbound requests that the site does not normally make.
One unusual request is not proof of execution. Correlate it with account activity, uploads, file changes, database records, or process logs. Our guide to WordPress error log monitoring explains how to turn noisy logs into an operational signal without exposing sensitive data.
Export the relevant period before logs rotate. Some hosts retain only a short window.
6. Inspect database persistence and scheduled work
Review recent pages, reusable blocks, widgets, menus, redirects, SEO fields, and theme options for unexpected links or scripts. Check the WordPress address, site address, administrator email, default user role, and registration setting.
List scheduled WordPress events and compare them with known plugins. An unfamiliar event that runs often deserves investigation, especially when its callback does not belong to an installed component. Take a backup and use WordPress-aware tools before changing serialized database values.
7. Prove that recovery is available
Identify the newest backup that predates suspicious activity, not merely the newest backup overall. Confirm that it includes files and the database, can be downloaded, and belongs to the correct website.
Do not overwrite the live site just to test a backup. Restore it to an isolated environment, scan it, compare it with the current site, and test the workflows that matter. Our WordPress backup restore test provides a practical recovery drill.
When normal maintenance should become incident response
Escalate when two or more independent signals support the same concern. Useful combinations include:
- An unknown Author-or-higher account and a matching login or upload event.
- An unexpected media item and a changed executable file.
- A new scheduled task and a database option that it keeps rewriting.
- Outbound traffic from PHP and a recently modified plugin or theme file.
- Search spam, redirects, or altered pages that appear only to logged-out visitors.
Normal maintenance can also modify many files, write cache entries, create archives, or add a host-managed plugin. Verify the source and timing before labelling those changes malicious.
If the evidence is material, preserve logs and backups, restrict access, rotate credentials, replace software with trusted copies, remove persistence, and test the site after recovery. Do not clean only the first file a scanner reports. A partial repair can remove a symptom while leaving the access path intact.
What this means for a WordPress maintenance plan
The WordPress 7.0.4 release shows why update management needs more than an automatic-update switch. A reliable process tracks versions, privileged users, backups, update results, logs, and the business workflows that must still work after a patch.
Webless WordPress maintenance services combine controlled updates, backups, monitoring, verification, and documented follow-up. The maintenance plan options show the current scope when you want someone to handle that process consistently.
Ask for direct help when you cannot confirm the installed version, do not know whether Imagick and Ghostscript are active, find an unexplained privileged account or upload, or cannot test a safe backup. Those are investigation tasks, not reasons to guess on a production site.
Final answer
Update WordPress to 7.0.4 promptly. Then confirm the version, review Author-or-higher accounts and recent media activity, check core files and logs, and test the public site. The affected conditions describe a possible path; they do not prove that your website was compromised.
A calm, evidence-based review gives you the useful answer: either the update completed and the site passes its checks, or specific signals justify containment and professional recovery.