WOLF CVE-2026-14234

Exploitation requires that the WOLF plugin (version below 1.1.0) is installed and active, and that a logged-in administrator with post-authoring rights is socially engineered into triggering the attacker's cross-site request while their session is valid (UI:R). The specific enabling weakness is the missing nonce AND capability check on one WOLF AJAX action, which allows the forged request to be processed. Limiting factors: the attack cannot succeed without an authenticated admin's active session and interaction, so it is not a direct unauthenticated compromise despite PR:N - the 'unauthenticated attacker' initiates the request but relies entirely on the victim admin's privileges.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L, base 7.1) reflects network reach and no attacker privileges but requires user interaction - the admin must be lured into visiting a malicious page - which meaningfully lowers real-world exploitability. The scope change (S:C) accounts for script executing in victims' browsers beyond the vulnerable app. Signals conflict on urgency: publicly available exploit code raises capability, yet EPSS is only 0.12% (2nd percentile) and there is no KEV listing, suggesting low observed exploitation volume - consistent with the UI:R dependency and the niche footprint of a single plugin. No SSVC decision data was provided in the input. Net assessment: a legitimate patch-soon issue for sites running WOLF, but not an emergency compared with unauthenticated, no-interaction WordPress flaws.

An attacker crafts a web page hosting a hidden auto-submitting form that fires the unprotected WOLF AJAX action, then lures a logged-in WordPress administrator to visit it (e.g., via a phishing link). The forged request, carrying the admin's cookies, writes attacker-controlled JavaScript into a post; that script then executes in the browser of every subsequent visitor to the post. Public exploit code for this flow is available via WPScan.