Media Library Assistant EUVD-2026-112878

Exploitation requires an authenticated WordPress account with at least low privileges (CVSS PR:L) and a victim who interacts with the attacker-influenced content (UI:R), so it is not remote-unauthenticated against a default install. The affected component is the Media Library Assistant plugin (versions up to and including 3.42); the description labels this DOM-based XSS but does not name the exact parameter, page, or configuration that triggers it, so the precise injection point is not described in the available sources. Limiting factors are the need for a pre-existing account, the dependence on victim interaction (typically a higher-privileged user viewing the malicious content), and the requirement that the vulnerable plugin be installed and active.

This is a DOM-based cross-site scripting flaw (CWE-79) in the Media Library Assistant WordPress plugin, scored CVSS 6.5 (medium). The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L indicates network-reachable, low-complexity exploitation that requires an already-authenticated low-privilege account (PR:L) plus victim user interaction (UI:R), with a scope change (S:C) reflecting script execution in the victim's browser context. The vuln.today decision label is 'this_month', not 'act_now' or 'emergency', consistent with a medium-severity, interaction-dependent XSS rather than a drop-everything issue. No KEV listing is present, so there is no confirmed active exploitation; no EPSS score was supplied, so exploitation probability cannot be quantified from this data; and the only reference is a Patchstack advisory page, not proof-of-concept exploit code, so no public exploit is identified. The combined signals point to a genuine but moderate, secondary-priority issue: exploitation needs both a foothold account and a tricked victim, which limits mass, unauthenticated abuse. The 'from n/a through 3.42' wording means a fixed version is not stated in the available data - this should be verified against the Patchstack/vendor advisory before concluding a patch exists.

An attacker with a low-privilege authenticated WordPress account (e.g., contributor/author) injects a crafted payload into a Media Library Assistant input that is later reflected into the DOM; when a higher-privileged user such as an administrator views the affected page, the script executes in their browser session. No public proof-of-concept exploit code was identified, and the attack requires the victim to interact with the malicious content.