WP Compress EUVD-2026-102793

Exploitation requires the WP Compress - Instant Performance & Speed Optimization plugin to be installed and active at version 7.25.00 or earlier. The attacker needs no WordPress account: the stored plugin API key is first harvested through the unauthenticated wpc_send_critical_remote nopriv AJAX action, but ONLY when the external critical-CSS service returns an apiResults field, causing initCritical() to echo the key via wp_send_json_success - this external dependency is the primary limiting factor and the reason for AC:H. Once the key is obtained, it is replayed as the apikey parameter to the start_comms dispatcher (hooked on every front-end request), which performs no capability check and no nonce verification, passing group/setting/value straight to change_setting() with no allow-list. The resulting control is scoped to the plugin's optimization, CDN, and critical-CSS settings surfaces rather than the full WordPress site.

This is a moderate-severity (CVSS 4.8) unauthenticated privilege-escalation chain in a WordPress plugin, and the signals are mostly consistent rather than conflicting. The CVSS vector (AV:N/PR:N/UI:N) confirms a network-reachable flaw requiring no authentication or user interaction, which is inherently attractive for mass, automated scanning of WordPress sites. The tempering signal is AC:H: the full chain depends on the external critical-CSS service returning an apiResults field so that initCritical() echoes the stored API key back - a condition not fully under the attacker's control, which is why impact is scored only C:L/I:L/A:N (control is confined to the plugin's optimization/CDN/critical-CSS settings rather than full site takeover). No EPSS score was provided in the input, so exploitation probability cannot be quantified; this is a genuine data gap, not a low score. It is NOT in CISA KEV and no public exploit was supplied, so exploitation status is 'no public exploit identified at time of analysis.' Net assessment: a credible, prioritize-for-patching issue because it is unauthenticated and WordPress plugins are heavily scanned, but not an emergency - the medium CVSS, high attack complexity, limited (plugin-scoped) impact, and absence of KEV/POC/EPSS evidence argue against treating it as actively weaponized.

An unauthenticated attacker first calls the wpc_send_critical_remote nopriv AJAX action, which under the right service response causes the plugin to echo its stored API key back in a wp_send_json_success response. The attacker then supplies that leaked apikey on an ordinary front-end request to the start_comms dispatcher, writing arbitrary permission keys into WPS_IC_SETTINGS so that checkAndAddCaps() grants a low-privilege or anonymous caller the manage_wpc_settings capability, yielding plugin-administrator-equivalent control. No public proof-of-concept was provided in the input, and the chain's reliance on the external critical-CSS service response (AC:H) adds uncertainty to reliability.