Media Library Organizer CVE-2026-94297

Requires an authenticated WordPress account with contributor-level role or higher on a site running Media Library Organizer versions 2.0.4 through 2.1.3 (fixed in 2.1.4); no user interaction is needed. Exploitation is limited to sites where lower-trust roles like contributor are provisioned to untrusted users, and the impact is bounded to creating publicly visible taxonomy terms - there is no confidentiality or availability effect. The practical limiter is the authentication requirement: an attacker must first hold a valid contributor+ account, so this is not remotely exploitable against an anonymous visitor.

This is a low-severity, low-real-risk finding despite the 'Authentication Bypass' tag. Every corroborating signal points the same direction: the CVSS 3.1 base score is only 2.7 with impact limited to I:L (no confidentiality, no availability), and CISA's SSVC framework rates Exploitation as 'none', Automatable as 'no', and Technical Impact as 'partial' - i.e. not a prioritization candidate. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data, so there is no evidence of exploitation interest. One conflict must be flagged: the provided CVSS vector uses PR:H, but the description states the flaw is exploitable by 'contributor-level access and above', which in the WordPress role model corresponds to a low-privilege authenticated user (PR:L), not a high-privilege one. If PR:L is correct the base score rises to ~4.3, still Low. The vector is also self-consistent with a broken-access-control issue rather than a true authentication bypass, so the 'Authentication Bypass' tag overstates the class (this is CWE-862 missing authorization / broken access control). Net: real but minor authorization gap, not a patching priority beyond routine plugin updates.

An attacker who already holds (or has been granted) a contributor-level WordPress account on a site running Media Library Organizer < 2.1.4 sends the plugin's term-creation request targeting a taxonomy they should not be able to manage. Because the plugin never checks the target taxonomy's management capability, the attacker creates arbitrary, publicly visible terms in any registered taxonomy. No public exploit code is identified at time of analysis, and impact is limited to unauthorized content/term creation (integrity), not code execution or data theft.