CVE-2026-103896: 10Web Booster <= 2.34.5 - Unauthenticated Limited File Write / Cache Poisoning via Query-string Parameter Traversal in Page-Cache Path
The 10Web Booster – Website speed optimization, Cache & Page Speed optimizer plugin for WordPress is vulnerable to a limited file write via path traversal in versions up to, and including, 2.34.5 This is due to the OptimizerWebPageCache::getcachefiledir() function concatenating raw, unsanitized $GET parameter names and values into the on-disk cache path, and the cachecontent() sink calling mkdir() and fileputcontents() on the result with no realpath containment check — unlike the sibling deletepagecache(), which does perform one. This makes it possible for unauthenticated attackers to create arbitrary directories (mode 0777, recursively) outside the cache root and write a cached page into them. The write is LIMITED: the filename is always 'source.html', so the extension is fixed, and the content is the rendered page buffer rather than attacker-supplied data. PHP files cannot be written and code execution is not possible; the demonstrated impact is cache poisoning and arbitrary directory creation.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
No authentication or user interaction is required. An attacker can exploit the vulnerable cache-path handling remotely by supplying crafted query-string parameter names or values.
What is the practical impact of the file write?
The attacker can create directories recursively outside the intended cache root with mode 0777 and cause a cached page to be written as source.html. They cannot choose the filename extension or supply arbitrary file contents, so PHP file creation and code execution are not possible from this issue.
Are sites affected in a default exposure scenario?
The issue is in the page-cache path generation and cache write flow. The provided data does not state whether page caching is enabled by default, but exploitation depends on the vulnerable cache functionality handling the crafted request.
What should teams do if they cannot update immediately?
Restrict or disable the affected page-cache functionality if operationally feasible, since it is the component that creates directories and writes the cached source.html file. Monitor for unexpected directories outside the cache root and unexpected source.html files.
How can defenders look for evidence of exploitation?
Inspect the filesystem for unexpected recursively created directories, particularly paths outside the intended cache root, and for source.html files in those locations. Review web requests for suspicious query-string parameter names or values containing path-traversal sequences.