W3 Total Cache, the caching plugin active on more than 900,000 WordPress sites, fixed a critical unauthenticated file-write vulnerability in version 2.10.5. The flaw, tracked as CVE-2026-18051, carries the maximum possible CVSS score of 10.0. Every version before 2.10.5 let an attacker with no login at all write a file into almost any directory that already exists on the server, including outside the web root. Update to 2.10.5 now if you haven’t already.
What the Bug Actually Does
Security researcher Jakub Herman found that W3 Total Cache’s Disk Enhanced page caching mode didn’t properly validate the paths it used when building cache file names. That’s a classic path traversal issue, CWE-22, but the impact here is worse than a typical read-only version of the bug. An unauthenticated attacker can send a crafted request that gets the plugin to write a file wherever they want, as long as the target directory already exists, and that write overwrites whatever’s already there.
On Apache hosting specifically, that means an attacker can overwrite .htaccess files. Losing that file doesn’t just risk breaking URL rewrites and redirects. It can silently strip out the hardening rules a security plugin or a host added to block directory listing, PHP execution in uploads folders, and similar protections, and most site owners won’t notice until something else goes wrong.
Who Should Care
Anyone running W3 Total Cache below 2.10.5 with the Disk Enhanced page cache method enabled is exposed right now, and it doesn’t matter whether the site takes logins from the public. The vulnerability needs zero authentication and zero user interaction. Given how widely W3TC is bundled or recommended for WordPress performance, plenty of sites are running it without the site owner even knowing which caching method is active.
The researcher’s advisory is holding a public proof of concept until September 17 specifically to give people time to patch. That’s not a long runway once attackers start reverse-engineering the fix from the changelog diff, which is exactly what tends to happen with a CVSS 10.0 bug in a plugin this widely installed.
What to Do
- Update W3 Total Cache to 2.10.5 or later immediately, from Plugins in wp-admin or via WP-CLI.
- If you can’t update right away, switch the page cache method away from Disk Enhanced as a stopgap, though updating is the only real fix.
- Check your live
.htaccessagainst a known-good backup if you suspect the site was already hit, since a quietly overwritten file is easy to miss.
This is the kind of bug that’s easy to miss if plugin updates aren’t part of someone’s regular routine. That’s exactly what we check first in a WordPress Development audit: which caching and security plugins are actually running, what version they’re on, and whether anything critical like .htaccess has drifted from what it should be. We covered a similar file-integrity bug in Sucuri’s own plugin last week, and an unauthenticated CVSS 9.8 admin takeover in User Profile Builder a few days before that. Unauthenticated, maximum-severity bugs in widely installed plugins are showing up often enough this month that “we’ll update plugins next sprint” isn’t a safe posture anymore.
