WordPress 7.0.4 security release: a remote code execution flaw is patched
WordPress shipped the 7.0.4 security release on August 12, 2026 and recommended updating sites immediately. The flaw it closes allowed a user with Author level permissions or higher to achieve remote code execution by uploading a malicious file on installations using Imagick and Ghostscript.
Author level is enough
Per the WordPress release note dated August 12, 2026, 7.0.4 is a security release requiring an immediate update. The patched flaw is described as authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript.
The issue is tracked as CVE-2026-65640 and GHSA-8vr3-7mxf-gx8w.
The critical detail here is the permission level. Exploiting the flaw does not require administrator rights, Author is enough. On multi author sites, blogs that accept guest writers and corporate sites with a content team, that role is widely distributed.
Who is affected and how far the fix was carried
The condition is two components being present together: Imagick and Ghostscript. Both are widely used for image processing and ship enabled by default in many shared hosting packages, so a site owner does not need to have installed them deliberately.
The fixes were not limited to the current branch. Per the release note, backports were applied as far as the 4.7 branch, and for 7.1 RC3 as well.
Normally only the most recent WordPress version receives active support. The release note states that security backports were extended to older branches as a courtesy given the severity of this vulnerability. This is not a flaw being treated lightly.
Update paths: direct download or the Updates screen under Dashboard. Automatic background updates are also rolling out to compatible installations.
Role assignment is a security setting
What this flaw really teaches is administrative rather than technical. The Author role is treated as harmless on most sites. It writes content, publishes it, cannot touch other people work. In this flaw the same role reaches code execution. That assessment is ours.
Second, the invisibility of server components. Imagick and Ghostscript are not things the site owner decides on, they are part of the hosting package. Your exposure can therefore depend on a configuration you never knew about.
Third, backporting as far as older branches is a signal. When a security team does extra work for versions it does not normally support, the blast radius of that flaw is wide.
Fourth, the limit of automatic updates. Background updates only run on compatible installations. Sites that do not receive them because of a plugin conflict, file permissions or a manually disabled setting can stay quietly exposed. That note is ours.
What it means for businesses in Türkiye
The assessment below is not in the sources, it is our reading. The release note contains no Türkiye specific information.
A very large share of corporate sites and blogs here run on WordPress and a significant portion use shared hosting. Imagick and Ghostscript are common components in those packages, so the number of affected sites may be higher than assumed.
Four practical steps. First, check your version number in the panel and update immediately if it is not 7.0.4. Second, open your user list and count the accounts with Author level or higher, removing those that no longer belong there. Third, ask your agency or hosting provider whether Imagick and Ghostscript are enabled. Fourth, verify that automatic updates actually run rather than assuming they do.
One more reminder: last week the 7.0.3 release closed 12 vulnerabilities. Two security releases arrived a week apart. That shows update tracking on a WordPress site needs to be a routine job rather than an occasional one.
The UNALSOFT take
On the web design side we put update responsibility in writing before a project closes, because the scenario we see most often is this: the site ships, everyone leaves happy, and six months later nobody remembers who was supposed to run updates. When exploitation does not even need administrator rights, as here, that gap gets expensive. Role assignment sits in the same scope. Permissions handed to a content team look like a convenience question when they are a security setting. We apply least privilege as a rule, because an old account nobody removed is a door nobody closed.
Sources
WordPress News, the 7.0.4 release · SecurityWeek, WordPress 7.0.4 patches remote code execution