aThemeArt Theme Helper EUVD-2026-102870

Exploitation requires an authenticated WordPress user - in practice an administrator or other privileged user of a site running aThemeArt Theme Helper version 1.0.8 or earlier - to be logged in and then tricked (UI:R) into visiting an attacker-controlled page or link that submits the forged request. The limiting factors are significant: the targeted user must have an active authenticated session, must interact with attacker-supplied content, and the forged action is constrained to whatever privileged operation the plugin exposes without a CSRF nonce. There are no special server-side configuration prerequisites noted; the flaw stems from the plugin's missing CSRF token validation rather than an optional feature, but successful impact depends on the victim's privilege level.

The input CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 8.8) indicates a network-reachable, low-complexity, unauthenticated flaw requiring user interaction, with high confidentiality, integrity, and availability impact. However, the vulnerability class is CWE-352 (CSRF), which is inherently interaction-dependent: exploitation requires tricking a logged-in user (typically an administrator) into submitting a forged request, so the real-world barrier is higher than the headline 8.8 suggests. No EPSS score, CISA KEV listing, or public POC is present in the provided data - all three exploitation-probability signals are absent, not negative, so exploitation likelihood cannot be quantified. There is no conflict between the signals, but the high C/I/A ratings assigned to a CSRF are optimistic and depend entirely on what privileged action the forged request performs, which the vague description does not specify. Overall this is a credible but not urgent issue: a high-CVSS WordPress plugin flaw with no evidence of active or automated exploitation, affecting a low-footprint plugin.

An attacker crafts a malicious web page or email containing a forged request targeting the aThemeArt Theme Helper plugin and lures a logged-in WordPress administrator into visiting it. When the authenticated admin's browser automatically submits the request, the plugin performs a state-changing action without verifying a valid nonce/CSRF token. No public exploit code is identified in the provided data at the time of analysis.