Directorist WordPress Plugin EUVD-2026-85026

Requires an authenticated subscriber-level WordPress account on a site running Directorist 8.9.1 through 8.9.4 (the unscoped REST collection endpoint was reintroduced in 8.9.1); sites on 8.8.1-8.9 are NOT vulnerable because the endpoint was correctly scoped there. Exploitation is limited by the need for account access - realistic on sites that allow open/self-registration, which is common for directory/classified plugins, but blocked where registration is closed. No user interaction or admin privileges are needed; the attacker simply invokes the customer order/payment REST collection endpoint that fails to filter results to the requesting user.

This is a genuine but moderate-severity broken-object-level-authorization flaw (CWE-639, IDOR). The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N = 4.3) is internally consistent with the description: a network-reachable REST endpoint, low attacker complexity, and a low privilege requirement (any subscriber-level account, which many Directorist sites permit via open registration). No EPSS score, KEV entry, or public POC was supplied, so there is no signal of active exploitation or automation - this reads as a real but not urgent priority rather than a high-CVSS-but-low-real-risk item or an emergency. The one contestable metric is confidentiality: the vendor rated C:L, but the flaw exposes EVERY customer's order and payment records in bulk (PII, contact and transaction data), which arguably warrants C:H - I diverge on this point below. The most notable nuance is versioning: the description states 8.8.1-8.9 are NOT affected (endpoint was correctly scoped in 8.8.1) and the bug was REINTRODUCED in 8.9.1 - a regression, which conflicts with the EUVD affected-range of '8.5 <8.9.5'. Defenders on 8.9.1-8.9.4 are exposed; those on 8.8.1-8.9 are not. Verify exact affected build against the WPScan advisory before triaging.

An attacker registers a free subscriber-level account on a Directorist-powered site (self-registration is commonly enabled) and authenticates. They then call the unscoped REST collection endpoint, which fails to filter results to the requesting user, returning every customer's order and payment records. No public exploit code was identified at time of analysis, but the attack requires only a routine authenticated REST request and low complexity.