Media Library Assistant CVE-2026-95609

Exploitation requires the attacker to persist a crafted script payload into a Media Library Assistant field (media item metadata/attachment data the plugin renders in the admin interface) on a site running version 3.41 or earlier. It is NOT fully self-contained: it requires user interaction (UI:R) - a victim such as an administrator or editor must subsequently load the page where the unsanitized value is output - and realistically requires the attacker to have some content-submission capability on the target site to store the payload, despite the input's PR:N. Limiting factors: the Low C/I/A impacts (browser-context script execution, not direct server compromise), the dependency on a victim viewing the affected page, and the need for the vulnerable plugin version to be installed and active.

This is a stored (persistent) cross-site scripting flaw (CWE-79) in the Media Library Assistant WordPress plugin, versions through 3.41, reported by Patchstack. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L) yields 7.1 (High) and models network reach, low complexity, no privileges, required user interaction, and a scope change - consistent with injected script executing in a victim's authenticated browser context. No EPSS probability was provided in the input, there is no CISA KEV listing, and no public proof-of-concept was supplied, so the signals point to 'no public exploit identified at time of analysis' rather than active exploitation. SIGNAL CONFLICT: the vector asserts PR:N (unauthenticated), but a *stored* XSS in a media-library plugin realistically requires an actor who can submit/persist content (e.g. an authenticated contributor/author uploading or editing media metadata) - verify with the vendor whether the injection point is truly unauthenticated or whether PR should be L. Net: a genuine but not emergency priority - a widely-installed plugin flaw worth patching on a normal cycle, downgraded in urgency by the UI:R requirement, the only-Low confidentiality/integrity/availability impacts, and the absence of exploitation evidence.

An attacker with the ability to submit content (e.g. a low-privileged authenticated user, or an unauthenticated submitter if the vendor's PR:N holds) stores a malicious script payload in a media-library field that the plugin renders without proper neutralization. When an administrator or other user later views the affected media-library page in wp-admin, the script executes in their browser session, enabling session/cookie theft or admin-context actions. No public proof-of-concept was identified in the provided data, and successful exploitation depends on a victim viewing the poisoned page (UI:R).