MDTF WordPress Plugin EUVD-2026-102235

Exploitation requires an authenticated WordPress account with at least low-level privileges (PR:L) on a site running the MDTF (Meta Data and Taxonomy Filters) plugin version 1.4.0 or earlier, plus the ability to submit input into a plugin-controlled field that is stored and later rendered without sanitization. Execution is further limited by the need for a victim user (UI:R) - typically an administrator or another privileged user - to subsequently load the page or admin view containing the stored payload; the script only runs in that victim's browser context. These two gates (prior authentication and required victim page view) materially reduce real-world exploitability compared to an unauthenticated, zero-interaction flaw.

This is a moderate, not top-tier, priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L, base 6.5) describes a stored XSS that is remotely reachable but gated by two meaningful barriers: PR:L means the attacker must already hold a low-privileged authenticated WordPress account, and UI:R means a victim (typically an administrator or other user) must subsequently view the page where the malicious payload is rendered. The scope-change flag (S:C) and the Low ratings across confidentiality, integrity, and availability reflect that executed script runs in the victim's browser session rather than granting direct server compromise. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The combination of required authentication plus required victim interaction, and the absence of any exploitation signal, argues against treating this as an urgent widespread threat; it is a legitimate but routine-patch-cycle issue typical of Patchstack-reported WordPress plugin XSS. Note the signals are internally consistent (authenticated low-priv + stored payload + victim view), so no contradiction needs flagging - the main limitation is simply that exploitation likelihood data (EPSS) is missing.

An attacker who holds a low-privileged authenticated account (e.g., contributor/subscriber-level) on a WordPress site running MDTF ≤1.4.0 submits a crafted input into a plugin field that is stored without proper neutralization. When an administrator or other user later views the page or admin screen that renders this stored data, the malicious JavaScript executes in their browser session, potentially hijacking the session or performing actions as that user. No public exploit code is identified in the provided data.