WordPress 7.0.4 addresses a security-sensitive upload path involving Imagick and Ghostscript on specific stacks. Platform teams may decide to deny or restrict PostScript and PDF delegates as a compensating control, but an untested policy can break PDF thumbnails, document previews, print workflows, or plugins that call ImageMagick outside the normal media endpoint. The control needs an inventory and a safe fixture matrix.
Use this for WordPress hosts and agencies running ImageMagick, Imagick, Ghostscript, PDF preview plugins, document portals, ecommerce downloads, or editorial upload roles.
Quick answer
Patch WordPress first. Record ImageMagick and Ghostscript versions, active policy files, delegate map, PHP worker identity, upload roles, and every required PDF or PostScript workflow. Apply the narrowest approved deny policy in staging, run harmless representative files, inspect process and error logs, then deploy with rollback. A policy pass means forbidden delegates cannot execute and required media outcomes either work or fail safely with a documented fallback.
What to check first
- Locate every ImageMagick policy file and record the effective delegate, coder, path, and resource rules.
- Inventory WordPress core media, PDF thumbnail, form upload, product document, membership, print, and custom CLI workflows.
- List users and integrations with upload_files or equivalent custom capability.
- Capture parent process, child process, temporary path, exit status, resource use, and resulting attachment metadata for each fixture.
- Test normal images, a harmless PDF, an unsupported PostScript fixture, corrupt input, a large document, and a denied role.
Why this usually happens
- ImageMagick can delegate formats to external programs whose policy is separate from WordPress permissions.
- Several policy files may exist and the process may load a different one than the administrator edited.
- Plugins can invoke conversion through background jobs or CLI workers that use a different environment.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
magick -version
magick -list policy
magick -list delegate
php -m | grep -i imagick
gs --version
wp user list --fields=ID,user_login,roles
# Join each harmless fixture to process and WordPress logs by UTC time.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Update WordPress and the relevant operating-system packages across every runtime. | Locate every ImageMagick policy file and record the effective delegate, coder, path, and resource rules. | Every reachable runtime reports WordPress 7.0.4 or the approved fixed backport. |
| Apply the narrow approved delegate or coder restriction in the effective policy file. | Inventory WordPress core media, PDF thumbnail, form upload, product document, membership, print, and custom CLI workflows. | Effective ImageMagick policy matches the documented deny decision. |
| Give required PDF workflows a documented safe fallback when previews are no longer generated. | List users and integrations with upload_files or equivalent custom capability. | Normal images and required document workflows pass or use the approved fallback. |
| Reduce upload capability and monitor unexpected child processes and temporary files. | Capture parent process, child process, temporary path, exit status, resource use, and resulting attachment metadata for each fixture. | Process logs show no unexpected Ghostscript child execution for denied fixtures. |
Decision rule
Approve when prohibited delegates cannot execute, normal image paths work, required document paths have an accepted outcome, and no alternate worker or policy file bypasses the control. Escalate unexplained process or file evidence as an incident.
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 |
|---|
| JPEG and PNG | Normal editorial images | Upload and derivatives succeed |
| Required PDF | Harmless one-page document | Approved preview or documented fallback |
| Denied delegate | Harmless unsupported format | No Ghostscript execution and safe error |
| Role boundary | Author and subscriber fixtures | Only approved role can start processing |
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.
- Update WordPress and the relevant operating-system packages across every runtime.
- Apply the narrow approved delegate or coder restriction in the effective policy file.
- Give required PDF workflows a documented safe fallback when previews are no longer generated.
- Reduce upload capability and monitor unexpected child processes and temporary files.
- Deploy through the canonical image or configuration source and verify every origin and worker.
Production verification checklist
- Every reachable runtime reports WordPress 7.0.4 or the approved fixed backport.
- Effective ImageMagick policy matches the documented deny decision.
- Normal images and required document workflows pass or use the approved fallback.
- Process logs show no unexpected Ghostscript child execution for denied fixtures.
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 successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides 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, roles, data volume, browser behavior, cache, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email route, worker clock, crawler response, or browser storage.
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, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, 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, review a WordPress media security exposure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references