Media Library Assistant CVE-2026-54198

Exploitation requires a target WordPress installation with the Media Library Assistant plugin at version 3.35 or earlier installed and active, plus a victim user (ideally a logged-in administrator or editor) who clicks an attacker-controlled URL - this is the UI:R requirement reflected in the CVSS vector. No authentication on the attacker side is needed (PR:N), and the vulnerable endpoint must be reachable over the network. Limiting factors: the exploit only succeeds when a user actually interacts with the crafted link, the impact scales with the privilege of the clicked-through user (a non-logged-in visitor click yields little, an admin click yields full site compromise), and any WAF or browser-side XSS auditor that blocks reflected payloads will reduce reliability.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L indicates network-reachable, low-complexity, unauthenticated exploitation that requires user interaction (UI:R) and triggers a scope change (S:C) - typical of reflected XSS that crosses from anonymous attacker context into an authenticated WordPress admin browser context. No EPSS score, KEV listing, or public POC was supplied in the intelligence package, so this should be treated as no public exploit identified at time of analysis. Real-world risk is moderate rather than critical: phishing-style delivery is required, but WordPress plugins of this class are widely deployed and admin-session hijack via XSS can chain to plugin/theme upload and full site takeover. No data is conflicting, but the absence of an EPSS value and any fixed-version reference in the input means urgency must be inferred from CVSS alone.

An attacker crafts a malicious URL containing a JavaScript payload in a vulnerable Media Library Assistant parameter and sends it via phishing email or social media to a logged-in WordPress administrator. When the admin clicks the link, the payload reflects into the response and executes in their browser session, allowing the attacker to steal authentication cookies, create a new admin user via the REST API, or upload a malicious plugin - effectively achieving site takeover. No public exploit code has been identified at time of analysis, but reflected XSS in WordPress plugins is trivially weaponizable once the vulnerable parameter is known.