Content Moved? Use Search to Locate
Closeup of switch in server with connectors and adapters connected to plastic device in dark room on blurred background inside

WordPress 7.0.4 Fixes Imagick Upload RCE: Update and Verify

BySplinternet Marketing

WordPress 7.0.4, released August 12, 2026, includes a security fix for authenticated remote code execution through malicious file uploads on sites using Imagick and Ghostscript. The WordPress 7.0.4 Security Release recommends updating affected sites.

This is conditional exposure, not proof that every WordPress installation is vulnerable. The practical priority for September 3, 2026, is to verify what each production, staging, and client-managed site is actually running instead of assuming that automatic updates completed successfully.

Need help checking this on your WordPress, Google Ads, Analytics, local SEO, or website setup? Splinternet Marketing can review the issue and help you prioritize the next fix.

When the vulnerability applies

Three conditions determine whether the issue is relevant:

  • Affected WordPress version: the site is running an unpatched version of a vulnerable branch.
  • Server-side processing: Imagick and Ghostscript are both installed and used in the relevant upload or image-processing path.
  • Authenticated access: an attacker obtains access to a user with the upload_files capability, including an Author-level account or higher.

The WordPress advisory describes a malicious PostScript upload that can reach Ghostscript through Imagick. Do not upload a live malicious test file to production. Use dependency inspection, access review, logs, and a safe staging test instead. The technical details are documented in the WordPress GitHub Security Advisory and NVD record for CVE-2026-65640.

WordPress 7.0.4 is the patched release for the 7.0 branch. Backported fixes are listed for 6.9.7, 6.8.8, 6.7.7, 6.6.7, 6.5.10, 6.4.10, 6.3.10, 6.2.11, 6.1.12, 6.0.14, 5.9.16, 5.8.15, 5.7.17, 5.6.19, 5.5.20, 5.4.21, 5.3.23, 5.2.26, 5.1.24, 5.0.27, 4.9.31, 4.8.30, and 4.7.35. WordPress 4.6 and earlier no longer receive security updates. Treat older branches as maintenance exceptions and document a dated upgrade plan.

What to do next

  1. Inventory the fleet. Include production, staging, development, forgotten subdomains, and sites managed by clients or third parties. Record the WordPress version, PHP version, hosting account, and whether Imagick and Ghostscript are installed.
  2. Verify the live version. Check wp-admin, hosting deployment records, automatic-update logs, or WP-CLI. The WP-CLI wp core documentation can support repeatable version and checksum checks where appropriate.
  3. Review accounts and capabilities. Inspect Author-level and higher users, stale staging accounts, shared credentials, and unexpected account activity. Confirm the business workflow before removing legitimate access; disable or rotate clearly abandoned credentials through the appropriate administrative process.
  4. Back up before production changes. Keep a tested database and file backup or hosting snapshot. Update staging first when practical, record the installed version, and document how to restore the previous state if the update causes a regression.
  5. Run a representative smoke test. Test safe media uploads, document handling, frontend rendering, forms, login, monitoring, and key WooCommerce product, cart, checkout, and confirmation paths. Check browser behavior as well as PHP, web-server, cache, and CDN errors.
  6. Review logs after the update. Look for unusual uploads, unexpected account activity, failed update attempts, PHP errors, 5xx responses, broken redirects, and cache or CDN problems. Preserve relevant logs before rotation or cleanup.

ImageMagick security policy restrictions that limit PostScript or PDF processing may provide defense in depth, depending on the hosting environment and application requirements. They are not a substitute for applying the WordPress fix or reviewing the server configuration.

For agencies and hosts, the goal is repeatability: version checks, dependency inventory, account review, backups, update records, smoke tests, log review, and exception reporting should belong to the same maintenance checklist. That makes it easier to identify whether a failed update, incompatible server dependency, or access-control issue could affect site availability, lead capture, or WooCommerce transactions.

Sources

Need help checking this on your WordPress, Google Ads, Analytics, local SEO, or website setup? Splinternet Marketing can review the issue and help you prioritize the next fix.

This article is for informational purposes only and reflects general marketing, technology, website, and small-business guidance. Platform features, policies, search behavior, pricing, and security conditions can change. Verify current requirements with the relevant platform, provider, or professional advisor before acting. Nothing in this article should be treated as legal, tax, financial, cybersecurity, or other professional advice.

Editorial note: Splinternet Marketing articles are researched from cited platform, documentation, regulatory, and industry sources. AI may assist with drafting and review; final content is checked for source support, practical usefulness, and platform/date accuracy before publication.

Related Posts

Splinternet Marketing