Directorist Booking EUVD-2026-37501

Exploitation requires (a) an authenticated WordPress session at any low-privilege role that can reach the affected booking endpoint - consistent with CVSS PR:L, typically Subscriber or Customer level which the plugin's booking workflow normally permits via self-registration, (b) the Directorist Booking plugin being installed and active at any version from initial release through 3.0.3 inclusive, and (c) network reachability to the WordPress site (AV:N). No user interaction is needed (UI:N) and no non-default configuration is called out in the description, but the Scope:Changed/Confidentiality:High impact assumes the WordPress database holds sensitive cross-plugin data (which is the default WordPress topology). Exploitation is limited where the site disables open registration, where the plugin is deactivated, or where a WAF inspects and blocks SQLi-style query strings on plugin endpoints.

Signals point to a real but conditional priority rather than a mass-exploitation crisis. The CVSS vector AV:N/AC:L/PR:L/UI:N tells us this is remotely reachable over the network with low complexity and no user interaction, but PR:L confirms an authenticated session is required - consistent with WordPress subscriber/customer accounts that a booking plugin would naturally hand out. The Scope:Changed with C:H is the most important driver of the 8.5 score, signalling that the SQL context can read data beyond the plugin's logical boundary (full wp_users hashes, options table secrets, other plugins' tables). EPSS, KEV and POC data are not provided in the input, so widespread exploitation cannot be assumed; the Patchstack reporting and the fact that the affected range is 'n/a through 3.0.3' suggest the vulnerability was disclosed without a publicly confirmed fixed version at the time of cataloguing, which should be verified directly with the vendor before deprioritizing.

An attacker registers or compromises any low-privilege WordPress account on a site running Directorist Booking ≤3.0.3, then submits crafted parameters to a vulnerable booking endpoint that interpolate into a backend SQL query. Using blind techniques (conditional responses or timing differences) the attacker iteratively extracts administrator password hashes, API keys stored in wp_options, and personal data from booking tables, then pivots to full site takeover by cracking the hashes offline.