A caching plugin builds file names out of the URL you requested. That is the entire job. When it does that without checking what is in the URL, an anonymous visitor gets to choose where on your server a file lands.
CVE-2026-18051 is a CVSS 10.0 (WPScan assessment) path traversal in W3 Total Cache versions below 2.10.5, one of the most widely deployed performance plugins in WordPress, that lets an anonymous visitor overwrite any existing file on the server, including .htaccess. There is a clock attached: a public proof-of-concept is scheduled for 17 September 2026.
What it is
| Field | Value |
|---|---|
| CVE | CVE-2026-18051 |
| CVSS | 10.0 Critical (WPScan): network, no privileges, no interaction |
| Class | CWE-22: path traversal leading to arbitrary file write |
| Authentication | None |
| Affected | W3 Total Cache < 2.10.5 |
| Fixed in | 2.10.5 |
| Advisory | WPScan, 17 August 2026 · CVE published 19 August (reserved 28 July) |
| Public PoC | Scheduled 17 September 2026 |
| Record | NVD · CVE.org |
How the bug works
A page cache exists to avoid rebuilding a page twice. To do that it needs a filename per URL, so it derives one from the request path.
W3 Total Cache does not properly validate that path before using it to build the cache file name. Feed it a crafted path and the plugin writes its file into a directory of the attacker's choosing (inside the web root or outside it), overwriting whatever already occupies that name.
GET /<crafted path>
│
▼
cache filename built from the request path ── no validation
│
▼
file written to an arbitrary EXISTING directory
│
▼
whatever was at that path is now gone
Two properties of this bug decide how bad it is for you.
It is a write to existing directories. The attacker is not creating a tree wherever they like; they are landing a file in a directory that already exists. That still covers every interesting location on a WordPress host.
The destructive power is in the overwrite, not the content. The headline scenario in the advisories is .htaccess. On Apache, .htaccess is where a great deal of WordPress security actually lives: PHP execution blocks in uploads, deny rules on wp-config.php, rate limiting, redirect and rewrite rules. Overwrite it and two things happen at once: the site's routing breaks, and every hardening rule that file enforced silently stops applying.
That second effect is the one to think hardest about. A .htaccess overwrite is not only a denial-of-service; it can be preparation. Remove the rule that stops PHP executing in wp-content/uploads, and a file-upload bug that was previously inert becomes a web shell. Chained with any of the upload flaws circulating this month, that is a full compromise assembled from two "partial" bugs.
Why CVSS 10.0 and not 9.8
Worth a moment, because the number is unusual. A 10.0 requires maximum impact across confidentiality, integrity and availability with no privileges and no user interaction. Arbitrary file write as an anonymous user gets there: integrity is obvious, availability follows from breaking the site, and confidentiality follows from the ability to disable protections around files that should not be readable.
Whether it deserves the full 10.0 rather than a high 9.x is the kind of thing scoring committees argue about. It does not change what you should do, and it is the wrong argument to be having while a PoC is scheduled.
The deadline is the story
Most WordPress advisories describe a race that already started. This one hands you the starting gun's timestamp:
| Date | Event |
|---|---|
| 28 July 2026 | CVE reserved |
| 17 August 2026 | WPScan advisory published |
| 19 August 2026 | CVE published |
| 17 September 2026 | Public proof-of-concept scheduled |
The pattern from vBulletin, from wp2shell, from every mass-exploited WordPress bug of the last two years is the same: the exploitation curve does not follow the patch, it follows the PoC. Unpatched installs sit quietly for weeks and then get swept in bulk within days of working code appearing.
You have until roughly mid-September before the cost of not patching changes sharply. That is a comfortable window and a completely wasted one if nobody acts on it.
What to do today
- Update W3 Total Cache to 2.10.5 or later. This is a plugin update, not a migration; there is no good reason to defer it.
- If you genuinely cannot update immediately, treat the plugin as an exposed attack surface: restrict access to it and monitor the filesystem for unexpected writes. This is mitigation, not a fix, and it expires on 17 September.
- Verify your
.htaccessfiles are intact (see below). Do it before you patch, so you know whether anything already happened. - Keep a known-good copy of every
.htaccesson the host. If you cannot say with certainty what yours should contain, you cannot tell whether it has been changed.
How to detect exploitation
Start with modification times. An .htaccess that changed when nobody deployed anything is the signal:
find . -name '.htaccess' -newermt '2026-07-28' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
Then compare content against what you expect. If you keep the site in version control, git status and git diff answer this instantly: one of several reasons a WordPress install belongs in version control at all, and something we set up as standard in DevSecOps work.
Also worth scanning for: files with cache-like names in directories that have no business holding cache files, and, because of the chaining risk above, executable files under wp-content/uploads:
find wp-content/uploads -type f -name '*.php' -newermt '2026-07-28'
If .htaccess protections were stripped and a PHP file appeared afterwards, assume execution happened. Rotate the database credentials in wp-config.php, rotate administrator and application passwords, and audit the users table and scheduled tasks. Catching this sequence as it happens rather than during a post-mortem is what SOC as a service is for.
The general lesson
Caching layers are trusted infrastructure that almost nobody threat-models. They sit in front of everything, run early in the request, and write to disk by design: the same properties that make them useful make them dangerous when input handling is loose.
Any component that turns user-controlled input into a filesystem path deserves the same scrutiny as an upload form, whether it calls itself a cache, a logger, an exporter or a backup tool. That is a question we ask of every caching and file-handling layer during a penetration test, and if you would like someone to ask it of yours before 17 September, talk to us.
