WordPress 7.0.4 Patches Remote Code Execution Vulnerability

What happened

The brief is tight: only the SecurityWeek facts, no invented versions or figures, and six to eight plain-prose paragraphs. I’ll draft against that constraint and check the word count before sending.WordPress 7.0.4 patches a remote code execution vulnerability that SecurityWeek reports as reachable by any attacker who already holds Author-level access or higher. The path is not an unauthenticated scan of a public login form. It requires a valid Author, Editor, or Administrator account and a malicious Postscript file submitted through WordPress’s ordinary content workflow. That pair is enough to run arbitrary code on the host if the site is still on a vulnerable release. The facts that can be stated without invention are therefore narrow and sharp: the patched release is WordPress 7.0.4, the permission floor is Author, the payload is a Postscript file, and the impact is remote code execution. SecurityWeek is the source for those constraints.

The technical shape of the bug follows from how WordPress treats uploaded media and from what Postscript actually is. An Author can create posts and put files into the media library. Core then hands many of those files to a server-side renderer so the site can build thumbnails, convert formats, and extract preview images. Postscript is not a dumb bitmap. It is a stack-based programming language designed for printers, and a Postscript file can carry operators that open files, spawn processes, or otherwise leave the drawing model. When a CMS pipeline rasterizes that file with a helper that still implements those operators, the helper runs them as the web server user. The attacker never needs a separate webshell upload or a plugin backdoor. They need the Author role and a file the media stack is willing to process. That is why a document format becomes an execution primitive: the converter is an interpreter, and the upload form is the delivery channel.

The technical detail

That matters to builders because Author is a production role, not a lab curiosity. Editorial sites, agencies, and multi-author blogs grant Author to staff writers, freelancers, and guest contributors so those people can publish without becoming administrators. The security model assumes an Author can write content and upload images but cannot run code on the box. This vulnerability collapses that assumption. A stolen Author password, a malicious guest writer, or a hijacked session is enough to take the server. Anyone who treated “Author cannot RCE” as an invariant in a threat model has to drop that invariant until 7.0.4 is installed. Plugin and theme authors who accept media from Author-level users and then shell out to image converters inherit the same trust boundary, even if their own code never parses Postscript.

Why it matters for builders

The market context is WordPress’s position as the default publishing stack for a large fraction of the public web, including high-traffic editorial properties that routinely hand Author seats to people outside the core engineering team. Competing CMS platforms have hit the same class of bug whenever they rasterize Postscript through an external converter. The pattern is older than this release: file-format parsers that implement a programming language are a recurring remote code execution surface, and WordPress is simply the largest target that still funnels Author uploads into those parsers by default. Hosts, managed WordPress vendors, and security scanners will treat 7.0.4 as a must-apply patch for that reason, not because the bug is exotic, but because the install base and the Author role are both large enough that a single media-library upload is a realistic production attack.

Market and competitive context

The practical move is to ship 7.0.4 and then shrink the remaining blast radius. Confirm the running version is 7.0.4 or later before arguing about anything else. Audit every Author and above account for seats that should have been Contributor or that belong to people who no longer write for the site. Disable or block Postscript uploads at the application or WAF layer if the site has no editorial need for that format. If the stack uses a custom image pipeline, check that it does not reintroduce a Postscript interpreter behind WordPress’s own fix. Watch for host-level converter updates and for plugin changelogs that mention media conversion, because a core patch does not automatically fix a plugin that shells out to the same helper.

What to watch next

Open questions remain around sites that cannot patch immediately and around the exact helper that executed the Postscript. SecurityWeek’s summary does not name a CVE identifier, a disclosure date, or the converter binary involved, so operators should not invent those details in runbooks. It is also unclear from the given facts whether Contributor-level users can reach the same code path through a separate upload or import plugin, or whether only the core Author upload flow is in scope. Prior art in this family includes years of converter advisories in which a crafted Postscript file escaped the rasterizer. Those earlier bugs are the reason many hardened hosts already refuse to process Postscript at all. Until every public WordPress install is on 7.0.4 and every side-loaded converter is checked, Author-level Postscript upload should be treated as a live remote code execution primitive rather than a theoretical media-library edge case.