Rox Appointment Booking EUVD-2026-114645

Stage one requires only that the plugin (version ≤1.3.1) be installed with its public booking REST route /rox-appointment-booking/v1/public/booking reachable - the default state - allowing any unauthenticated visitor to persist a customer row with an arbitrary wp_user_id, because CustomerModel::$fillable includes the internal wp_user_id column and no authorization check is applied. The attacker must know or guess a valid administrator user ID (default user ID 1 is a reliable guess). Stage two is the key limiting factor: an administrator must subsequently open the poisoned customer record and click Update Customer, at which point SaveCustomer::handleRequest() passes the stored wp_user_id and attacker email to wp_update_user() (permitted because LinkedAccount::canChange() unconditionally returns true for users with edit_users). No non-default configuration is needed, but the mandatory administrator interaction (UI:R) and the user-ID guess bound realistic exploitation.

This is a genuine, high-severity issue but not a drop-everything emergency, and the signals are internally consistent once the two-stage mechanic is understood. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, 8.8) correctly captures that the initial mass-assignment write is remote and unauthenticated (PR:N) and that the ultimate impact is full compromise (C:H/I:H/A:H), while UI:R honestly reflects the hard dependency on an administrator later opening and saving the poisoned customer record. The vuln.today decision label is 'this_week' rather than 'act_now'/'emergency', which aligns with the UI:R gating and the attacker's need to know or guess a valid administrator user ID. No EPSS score was supplied, so exploitation probability cannot be quantified from the input; there is no CISA KEV listing (not actively exploited per available data) and no working exploit code is provided - the references are the Wordfence advisory and plugin source on plugins.trac, not a weaponized PoC. The main reason to prioritize is the low barrier to the first stage (any unauthenticated visitor can plant the poisoned record against default user ID 1) combined with the catastrophic outcome; the main reason it is not an emergency is the required administrator interaction. Net: a real priority to patch promptly, consistent with the 'this_week' label, not a high-CVSS-but-trivial-impact paper cut.

An unauthenticated attacker sends a crafted request to the public /rox-appointment-booking/v1/public/booking REST endpoint, mass-assigning the internal wp_user_id field (e.g. 1, the default admin) together with an attacker-controlled email, persisting a poisoned customer row. Later, when an administrator opens that customer record and clicks Update Customer, the plugin calls wp_update_user() with the stored admin user ID and attacker email, overwriting the administrator's address; the attacker then issues a standard WordPress password reset to take over the account. No public exploit code is identified at time of analysis, though the vulnerable code paths are documented in the Wordfence advisory and plugin source references.