The WordPress 7.0.4 security update deserves prompt attention from site owners, agencies, and anyone responsible for a business website. WordPress released version 7.0.4 on August 12, 2026, described it as a security release, and recommended updating sites immediately.
Quick Answer
Update WordPress core to a patched, supported version as soon as you can do so safely. Before updating, take a verified backup and confirm that you can restore it. Afterward, review users with Author-level access or higher, check recent media uploads and server logs, update plugins and themes, and test critical forms and transactions. An update reduces future exposure; it does not prove that a previously vulnerable site was never accessed.
TL;DR
- WordPress 7.0.4 addresses a security issue involving authenticated users with Author-level access or higher.
- The reported risk involves malicious file uploads on certain environments using Imagick and Ghostscript.
- Back up first, update core promptly, then verify the version and test the website.
- Audit privileged users, recent uploads, logs, plugins, themes, and business-critical functions.
- If anything looks suspicious, preserve evidence and ask a qualified security professional to investigate.
Why the WordPress 7.0.4 security update is urgent
The official WordPress 7.0.4 release notice says the release fixes a remote-code-execution vulnerability involving malicious file uploads by authenticated users with Author-level privileges or above on sites using Imagick and Ghostscript. The issue is identified as CVE-2026-65640 and GHSA-8vr3-7mxf-gx8w. Fixes were also backported to older WordPress branches.
The WordPress 7.0.4 security update matters, but it is not a reason to panic or assume that every WordPress website is compromised. It is a reason to reduce avoidable exposure promptly and to check the parts of the site most closely related to the reported issue.
Security updates compete with legitimate operational concerns: a plugin may be fragile, checkout may be busy, or nobody may be available to test a deployment. The practical response is a controlled update, not an indefinite delay. Choose the earliest low-risk maintenance window, make restoration possible, and assign someone to verify the result.
Step 1: Confirm the WordPress 7.0.4 security update and hosting environment
In the WordPress dashboard, open Dashboard → Updates and note the installed WordPress version. If your host manages WordPress updates, verify the deployed version in the host panel or ask support to confirm it. Do not assume that an “automatic updates enabled” setting means this particular release has completed successfully.
Ask your host or developer whether the server uses Imagick and Ghostscript for image or document processing. A site that does not use that combination may have a different exposure profile, but the official recommendation is still to install the patched release. Version confirmation is more useful than guessing from the site’s appearance.
Record the check in a change log: date, time, current version, updater, backup location, and planned verification owner. A short record is invaluable if an issue appears later.
Step 2: Back up before the WordPress 7.0.4 security update
A backup is not merely a success notification from a plugin. It should include the database and all required site files, including uploads, themes, plugins, and configuration. Confirm where the backup is stored and that the storage is separate from the production server.
For a high-value ecommerce, membership, booking, or lead-generation site, check the host’s restoration process before the update. Know who can restore, how long it normally takes, and what recent transactions could be lost if rollback becomes necessary.
If you maintain a staging environment, test there first. Make sure staging is reasonably current; a six-month-old copy cannot reliably reveal conflicts in today’s production stack.
Step 3: Update core, plugins, themes, and server components
Install the patched WordPress core version through your normal controlled process. Then review available plugin and theme updates. Core security is only one layer: an abandoned extension or unsupported PHP version can leave a separate weakness in place.
Update one logical group at a time when practical, and retain a record of version changes. Avoid making unrelated design changes during the same maintenance window. A focused change makes troubleshooting faster.
If your organization manages the server, ask the infrastructure owner to review Imagick, Ghostscript, PHP, the web server, and operating-system packages against supported versions and vendor guidance. WordPress core updating and server patching are related controls, but they are not interchangeable.
Step 4: Verify the WordPress security update and test critical flows
After installing the WordPress 7.0.4 security update, return to Dashboard → Updates and confirm the installed WordPress version. Clear only the caches your normal procedure requires, then test the site in a private browser window and on a mobile device.
Prioritize functions tied to revenue or customer trust:
- contact, quote, and application forms;
- checkout, payment, booking, or donation flows;
- login, password reset, and account pages;
- search, navigation, and important landing pages;
- image uploads and media rendering;
- analytics, conversion events, and email notifications.
Check the browser console and server error logs if you have access. A visually correct page can still hide a failed form submission or tracking request.
Step 5: Audit users with publishing privileges
The disclosed issue requires an authenticated user with Author-level access or higher, so review privileged accounts carefully. In Users, identify Authors, Editors, Administrators, and custom roles with upload capabilities.
Disable accounts that are no longer needed. Reset credentials for suspicious or shared accounts, require unique accounts for each person, and enable multi-factor authentication where your identity or security tooling supports it. Confirm that agency, contractor, and former employee access still has a legitimate owner and expiration date.
Do not downgrade a role blindly if the person needs it for daily work. Apply least privilege: each account should have the lowest access that still allows its assigned tasks.
Step 6: Review recent uploads and logs
Inspect recent Media Library items, especially uploads by privileged users during the period before patching. Look for unfamiliar file names, unexpected types, unusual timestamps, duplicate-looking files, or uploads attributed to an account owner who says they did not perform the action.
Review available WordPress activity logs, web-server access logs, security-plugin alerts, host malware scans, and file-integrity reports. An isolated anomaly is not automatic proof of compromise, and the absence of an alert is not proof of safety. Treat the evidence proportionately.
If you find a suspicious file or account event, avoid deleting everything immediately. Preserve logs and a forensic copy, restrict access where safe, and involve a security professional. Evidence can help determine scope and prevent a rushed cleanup from hiding the original path.
Step 7: Strengthen the update process for next time
Security maintenance becomes easier when it is routine. Assign an accountable site owner, enable appropriate update notifications, maintain a supported stack, and schedule recurring access reviews. Document the emergency contact for your host and developer.
Separate editorial access from administration. Most writers do not need plugin installation or site-configuration privileges. Remove unused plugins and themes, because inactive software still adds maintenance work and can be forgotten.
RightJob Solutions’ technical SEO audit checklist can help teams review crawlability and site health after technical changes. For implementation and maintenance support, see our web development services.
What not to do
Do not postpone the update simply because the front end “looks fine.” Vulnerabilities are not visual defects. Do not install an unverified patch from a forum or social post. Use WordPress, your managed host, and original software vendors as the sources of update files and instructions.
Do not publish technical exploit details in a staff memo or public incident update. Share only what people need to complete their responsibilities. Finally, do not claim the website is “100% secure” after updating. Security is a continuing risk-management process.
Frequently Asked Questions
Is WordPress 7.0.4 a security release?
Yes. WordPress identifies 7.0.4 as a security release and recommends immediate updating. Fixes were also made available for several older branches.
Does every WordPress site have the same level of risk?
No. Configuration, server components, user roles, and patch level affect exposure. However, the safest general response is to run a supported patched WordPress version and verify the update.
Is updating enough to prove my site was not compromised?
No. Updating closes the known vulnerable path for future attempts, but it does not establish what happened before the patch. Review users, uploads, logs, and integrity alerts if the site may have been exposed.
Should I update a busy ecommerce site immediately?
Use the earliest controlled maintenance window with a verified backup, restoration plan, and post-update testing. “Immediate” should mean prompt and managed, not reckless.
Can RightJob Solutions help review or maintain the website?
Yes. If you need help with updates, testing, performance, or a broader security and maintenance process, contact RightJob Solutions.
Final WordPress security update checklist
Use this WordPress 7.0.4 security update checklist: confirm the version, make a restorable backup, apply the patched release, test critical flows, audit privileged users, review uploads and logs, and document the result. That sequence turns an urgent security notice into a controlled business response.
