WordPress 7.0.4 fixes a remote code execution issue that the official release describes as reachable by an authenticated Author or higher through a malicious file upload on sites using Imagick and Ghostscript. Updating core closes the known WordPress path, but an exposed production site still needs a short evidence review because the patch alone cannot tell you whether a risky account, upload, conversion process, or suspicious child process existed before the update.
Use this response for self-hosted WordPress sites, multisite networks, editorial sites with Author accounts, agencies managing many sites, and hosts where ImageMagick delegates media conversion to Ghostscript.
Quick answer
Update every supported WordPress branch to the fixed security release immediately. Then inventory core version, Imagick and Ghostscript presence, users with upload capability, recent media and archive uploads, web and process logs, changed PHP files, cron events, and new privileged access. Treat credible evidence of unexpected Ghostscript execution, altered files, or unknown accounts as an incident, not a routine update.
What to check first
- Confirm the exact WordPress version on every origin, container, autoscaling image, maintenance copy, and public environment.
- Record whether the PHP Imagick extension and Ghostscript binary are installed, their versions, delegate policy, and which worker user invokes them.
- List Authors, Editors, Administrators, custom roles, application passwords, and recently changed accounts with upload_files capability.
- Review recent media uploads, web access, PHP errors, process execution, changed files, cron events, and outbound connections for the exposure window.
- Compare core checksums and inspect uploads, mu-plugins, cache, temporary conversion directories, and web root for executable or unexpected files.
Why this usually happens
- WordPress media processing can cross several trust boundaries: authenticated upload, MIME inspection, PHP image handling, ImageMagick delegates, Ghostscript, temporary files, and filesystem permissions.
- Custom roles and old editorial accounts can retain upload privileges long after their business need ends.
- A fleet may report one WordPress version while stale containers, maintenance hosts, or alternate origins continue serving an older build.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp core version
wp core verify-checksums
wp user list --fields=ID,user_login,roles,user_registered
wp cap list author | grep upload_files
php -m | grep -i imagick
gs --version
find wp-content/uploads -type f -mtime -14 -print
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Patch WordPress core across every reachable environment and deployment source. | Confirm the exact WordPress version on every origin, container, autoscaling image, maintenance copy, and public environment. | Every public origin and deployment artifact reports a fixed WordPress version. |
| Reduce upload-capable roles and revoke accounts or application passwords that no longer have an owner. | Record whether the PHP Imagick extension and Ghostscript binary are installed, their versions, delegate policy, and which worker user invokes them. | Upload-capable users and application passwords have a current owner and business need. |
| Review the exposure window and preserve suspicious media, process, file, account, cron, and network evidence. | List Authors, Editors, Administrators, custom roles, application passwords, and recently changed accounts with upload_files capability. | Core checksums, changed-file review, recent uploads, cron, and process logs contain no unexplained indicator. |
| Contain and clean any confirmed indicator, then rotate affected credentials and salts after persistence is removed. | Review recent media uploads, web access, PHP errors, process execution, changed files, cron events, and outbound connections for the exposure window. | Normal JPEG, PNG, PDF, and thumbnail workflows required by the site still work after containment. |
Decision rule
Escalate to incident response when an upload-capable account is unexplained, image processing launched unexpected commands, core checksums fail without a known deployment reason, or new executable persistence appears. A clean review can close only after every public origin is patched and normal media processing passes.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Patched core | 7.0.4 or fixed backport with normal image | Upload and thumbnail creation work |
| Least privilege | Author fixture without admin access | Only intended media capabilities remain |
| Suspicious media | Known-safe malformed fixture on isolated staging | Processing fails safely without shell or file side effect |
| Persistence review | Checksum, users, cron, uploads, and process logs | No unexplained indicator remains |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Patch WordPress core across every reachable environment and deployment source.
- Reduce upload-capable roles and revoke accounts or application passwords that no longer have an owner.
- Review the exposure window and preserve suspicious media, process, file, account, cron, and network evidence.
- Contain and clean any confirmed indicator, then rotate affected credentials and salts after persistence is removed.
- Retest normal media workflows and add fleet checks for core, Imagick, Ghostscript, roles, and unexpected process execution.
Production verification checklist
- Every public origin and deployment artifact reports a fixed WordPress version.
- Upload-capable users and application passwords have a current owner and business need.
- Core checksums, changed-file review, recent uploads, cron, and process logs contain no unexplained indicator.
- Normal JPEG, PNG, PDF, and thumbnail workflows required by the site still work after containment.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a green screen, successful request, or quiet log as proof that the customer outcome is correct.
- Do not leave debug logs, broad credentials, test orders, temporary roles, or firewall exceptions active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, roles, integrations, and server packages. Finish with one controlled production fixture when the result depends on real email routing, edge cache, crawler access, payment callbacks, or advertising diagnostics.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, secrets, order keys, and full click identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, investigate a WordPress security exposure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Verify the platform Ghostscript policy after patching WordPress
Use the WordPress 7.0.4 Ghostscript delegate policy test to inventory effective policy files, required PDF workflows, upload roles, child processes, safe denials, and production fallbacks.
Helpful references