CVE-2026-66699

The EPSS score of 0.00184 is dangerously misleading for CVE-2026-66699. This broken access control in the Dokan marketplace plugin operates in a context where privilege escalation directly translates to unauthorized financial and vendor data access — a category traditional exploitation probability models fail to capture. The CVSS 5.3 reflects a structural simplicity in the attack — likely no authentication bypass or complex chain required — but it abstracts away what actually matters: Dokan is not a blog plugin or a contact form. It's the permission infrastructure for entire storefronts. A broken access control affecting custom roles means vendors could potentially access administrative functions, view competitor data, modify settings outside their scope, or interfere with orders outside their authorized domain. The 'custom role' specificity is telling — this isn't a blanket WordPress role confusion, it's a failure in how Dokan enforces the boundaries it explicitly defines for its own role system. That suggests the vulnerability lives in the business logic layer, where the plugin is making nuanced decisions about what each vendor type can do — and getting those decisions wrong. What makes this particularly dangerous is the architectural split between WordPress core roles and Dokan's custom role store. The plugin maintains its own role definition layer separate from WordPress, which means broken access control can persist even when WordPress roles appear correctly configured. Vendor-scoped queries using get_current_user_id() checks versus explicit ownership validation on the resource object may not be consistently applied across endpoints handling orders, withdrawal requests, and product management. There is also a persistence problem: custom role definitions created under older Dokan versions may not cleanly map to the current permission model. When the plugin refactors its role system between versions, old role definitions can become orphaned — referencing capability strings that have been renamed, split, or had their enforcement logic changed. The "broken access control" may not be fresh logic error in 5.0.10; it may be legacy role definitions that became dangerous when the enforcement layer changed underneath them without a downstream audit. The low EPSS probably reflects that exploitation requires some legitimate access (vendor account, custom role configuration) rather than remote unauthenticated entry. But that doesn't make this low-stakes — it makes it a privilege-abuse scenario, which often has worse real-world consequences than an unauthenticated RCE precisely because the attacker already has a trusted foothold. A compromised vendor role in a marketplace can enable fraud multiplication across multiple storefronts. Analysts should examine whether this creates horizontal or vertical privilege escalation: can Vendor A access Vendor B's pricing data, order volumes, and customer information? Can a vendor escalate to admin functions? The horizontal scenario is particularly severe — it exposes the competitive intelligence that defines marketplace dynamics, handing one vendor asymmetric information advantage over every competitor. That's a fundamentally different risk category than unauthorized code execution.

Reviewed through automated stages and approved by a human before publication.