# WordPress's Postscript Problem: How a 40-Year-Old File Format Became an RCE Gateway
The patch notes for WordPress 7.0.4 read like a routine maintenance release. Buried in the security advisory is a vulnerability that should make every multi-contributor WordPress site administrator uncomfortable: authenticated users with Author-level access could achieve remote code execution by uploading a crafted Postscript file.
The word "authenticated" will do a lot of heavy lifting in how this gets covered. It will be used to suggest the risk is limited. It isn't.
## What Author-Level Access Actually Means in the Wild
On a personal blog, the permission model makes intuitive sense — you know who has Author access, and it's probably you. Scale that to how WordPress actually operates across the web, and the threat surface opens considerably.
WordPress runs roughly 43 percent of all websites. Among those are thousands of multi-author publications, regional news sites, marketing agencies managing client sites, content farms, and enterprise CMS deployments where Author credentials are distributed across freelancers, contractors, and part-time contributors. In those environments, "authenticated attacker" is not a hypothetical — it describes anyone who has ever been onboarded to produce content, including people who no longer work there, accounts secured with recycled passwords, and anyone whose credentials were taken in the last decade of credential-stuffing campaigns.
Requiring authentication lowers the likelihood of an opportunistic attack. It does not lower the severity of what happens once someone gets through.
## Postscript in 2026: A Legacy Format With Teeth
The technical vector deserves more attention than it typically receives in patch coverage.
Postscript is a programming language developed by Adobe in the early 1980s. It is Turing-complete, which means a Postscript file is not a static document — it is executable code. When software processes a Postscript file without appropriate sandboxing, it runs that code. This is not a new observation. Ghostscript, the most widely deployed Postscript interpreter, has an extensive vulnerability history: CVE-2018-16509, the "GhostButt" bug that enabled RCE through malformed Postscript, was actively exploited within days of disclosure and affected virtually every Linux distribution and application that leaned on Ghostscript for document handling — including earlier WordPress setups.
The question worth asking, and one the advisory does not answer publicly, is whether 7.0.4's vulnerability involves Ghostscript in the processing chain, or whether WordPress's own image and file handling was the entry point. The use of Postscript specifically as the malicious payload format suggests some kind of backend processing — thumbnailing, format conversion, or preview generation — that interprets the uploaded file rather than simply storing it.
WordPress administrators who have locked down file upload extensions should verify that .ps files are actually blocked. Extension filtering is famously inconsistent when it interacts with server-side processing libraries that accept MIME types independent of file extension.
## The Upload-to-Execution Pipeline
Author-level users in WordPress can upload media. That's core to the role. The vulnerability path, as described, appears to run through that upload surface — an Author submits a malicious .ps file, the WordPress backend or an underlying library processes it, and that processing triggers code execution in the server context.
This matters for how defenders think about mitigation. Patching is the correct answer, and 7.0.4 should be applied immediately. But the secondary controls that would have limited the blast radius before a patch existed are worth examining: Was file processing being run under a least-privilege user? Was the upload directory on a separate partition without execution permissions? Was outbound network access from the web server process restricted?
For sites that cannot patch immediately — and there are always sites that cannot patch immediately, for reasons ranging from plugin incompatibility to change-freeze windows — disabling Postscript processing at the server level or restricting Author-level uploads to explicitly safe MIME types are viable interim controls.
## Who Gets Hit First
Targeted exploitation of authenticated WordPress vulnerabilities follows a predictable pattern. The first victims are typically not random. They are sites where credentials are obtainable through prior breaches, sites where Author accounts are numerous and poorly managed, and high-value targets where an attacker is willing to invest in obtaining a valid account before escalating.
Media companies, in particular, warrant heightened attention. They maintain large contributor pools, frequently work with external authors under deadline pressure, and have historically been targeted for both data theft and as distribution vectors for malware (compromising a news site's server provides an attacker with a trusted platform to host malicious content). A newsroom running unpatched WordPress with dozens of active Author accounts is an attractive target in a way that a patched single-author blog simply is not.
The same applies to WordPress-based agency deployments where a single vulnerable installation could expose multiple client sites through shared infrastructure.
## Patching Is Not Optional Here
Version 7.0.4 is a security release. The upgrade path exists. The argument for delay is difficult to construct when the vulnerability enables remote code execution.
For administrators who manage multiple WordPress installations, this is a good moment to audit which sites are running outdated versions and which Author accounts are still active but should have been deprovisioned. Stale accounts are a persistent problem — the person who wrote three posts in 2023 still has credentials, and those credentials are as valid as they ever were.
Restricting the file types that Author-level users can upload is a sensible long-term hardening measure independent of this specific vulnerability. Most publications do not need their contributors uploading Postscript files. Blocking it costs nothing and closes a category of risk that has, historically, caused real damage.
---
## HackWire Analysis
The Postscript vector here is the detail that other coverage is likely to underplay in favor of the "authenticated attacker" framing. The authentication requirement is real mitigation — but Postscript-as-exploit-payload connects this vulnerability to a pattern that predates modern web security by decades.
Ghostscript vulnerabilities have surfaced repeatedly because Postscript's design as an executable language makes safe sandboxing genuinely difficult. Every application that processes Postscript — printers, PDF converters, image handlers, CMS backends — inherits that risk. The 2018 Ghostscript RCE reached through ImageMagick, Gimp, and WordPress media handling simultaneously, because they all called the same underlying interpreter. Whether 7.0.4's vulnerability runs through the same chain is worth confirming once researchers publish technical details.
What defenders are missing in the routine patch-and-move-on response is the account hygiene angle. The authentication requirement means that fixing this vulnerability does not just mean patching — it means auditing who holds Author credentials and whether those credentials are protected by anything beyond a password. Sites without MFA on contributor accounts are running with a permanently cracked door, independent of which CVE is currently trending.
WordPress's market share makes every authenticated RCE in its codebase a significant event. The install base is too large and too heterogeneous for universal rapid patching. The sites that get hit six months from now will not be running 7.0.4. They will be running whatever version was current when their administrator last had time to check.
— HackWire Editorial
---
## Related Coverage