WordPress 7.0.4 Patches Remote Code Execution Vulnerability

What happened

WordPress 7.0.4 closes a remote code execution flaw that SecurityWeek reported as reachable by any account with Author-level permissions or higher. The exploit path is not a public, unauthenticated smash of the login page. It is a trusted-user attack: someone who can already write posts and, on a typical WordPress site, upload files, feeds the platform a malicious Postscript document and gets code to run on the server. That is a different threat model from a drive-by against an anonymous visitor. Author is a role many editorial teams hand out to staff writers, freelancers, and agency partners. The patch in 7.0.4 is the product fix for turning that ordinary publishing privilege into host-level execution.

The technical shape of the bug follows from what Postscript actually is. Postscript is a programming language that happens to draw pages. A .ps file is a stream of operators, procedures, and file-system hooks, not a inert picture. When a CMS accepts that file as an upload and then interprets it—to generate a preview, to rasterize a page, to extract metadata, or to convert it into a format the media library can display—the interpreter becomes part of the application’s attack surface. Remote code execution here means the interpreter, or the code that wraps it, can be steered into running attacker-controlled instructions with the privileges of the web process. The SecurityWeek summary ties that execution to a malicious Postscript file and to Author or higher. It does not require an Administrator account. Anyone who can reach the Author upload and publish path is in scope.

The technical detail

That matters to engineers because WordPress role design is widely treated as a trust boundary that it is not. Teams lock down Administrator, then treat Author as a content-only sandbox. The sandbox assumption fails as soon as the media pipeline executes a language the Author is allowed to upload. On a multi-author magazine, a university department site, or a client portal where vendors get Author so they can file updates, the blast radius is the whole host: database credentials in wp-config, other sites on the same account, scheduled jobs, and any secrets the PHP worker can read. Builders who wrap WordPress as a headless CMS or who expose the REST and upload endpoints behind SSO still inherit this, because the privilege check is the WordPress role, not the identity provider. If your threat model stopped at “no unauthenticated RCE,” this class of bug is outside that model and still fully live until 7.0.4 is installed.

Why it matters for builders

The market context is that WordPress remains the default CMS for a huge share of the public web, which makes every Author-level RCE a mass-incident candidate rather than a niche vendor advisory. Competing platforms have the same structural tension—rich media upload plus a document interpreter plus a mid-tier editorial role—but WordPress concentrates that tension at a scale no other CMS matches. Attackers who already buy or phish Author accounts, or who compromise a freelancer’s laptop, get a reliable escalation path that does not depend on guessing an Administrator password. SecurityWeek’s report is one data point in a long pattern: file-format parsers and print-language interpreters keep showing up as the bridge from “can publish a post” to “owns the box.” Site owners who compare WordPress unfavorably to static generators or to locked-down headless stacks are, on this specific issue, pointing at a real difference in default attack surface, not a branding argument.

Market and competitive context

The practical next step is mechanical. Apply WordPress 7.0.4. Do not wait for a convenient maintenance window if Authors, Editors, or anyone above Author can log in from the public internet. While the update rolls out, treat every Author account as a privileged account: remove unused ones, require unique credentials, and stop granting Author to people who only needed a draft box. If you control the upload allowlist, stop accepting Postscript until you have confirmed the patched release is live and the conversion path no longer executes untrusted operators. After the upgrade, assume a malicious .ps that was already sitting in the uploads directory may still be dangerous if any remaining code path reprocesses it. Watch for a follow-up from SecurityWeek or from WordPress that names the exact processing component and whether a workaround exists for sites that cannot move to 7.0.4 immediately.

What to watch next

Open questions remain because the public summary is thin. SecurityWeek states the permission floor and the file type; it does not say whether Contributor or lower can reach any part of the same parser, whether the flaw is in core or in a bundled library, or whether successful exploitation leaves a durable web shell or only a one-shot command. Those details change incident response. A one-shot RCE during preview is still a full compromise, but a stored file that executes on every thumbnail rebuild is a persistence mechanism you will miss if you only rotate the compromised Author password. Prior art in this area is the long history of print-language and image-pipeline bugs: Postscript and its cousins have repeatedly turned document conversion into code execution in servers that thought they were only making a preview. Until the missing internals are published, the conservative read of the SecurityWeek report is enough to act on: Author plus a Postscript upload was remote code execution, and WordPress 7.0.4 is the release that patches it.