Booking and Rental Manager CVE-2026-78257

Exploitation requires an authenticated WordPress account with at minimum the Contributor role (CVSS PR:L confirmed). The Booking and Rental Manager plugin must be installed and active on a WooCommerce-enabled WordPress site. Full arbitrary code execution further depends on the presence of a usable POP chain within the PHP class library loaded at runtime - this is common but not universal in WooCommerce deployments. Exploitation is limited by the contributor role requirement: anonymous or subscriber-level users cannot exploit this vulnerability. Non-WordPress installations are not affected. No evidence of special plugin configuration being required is present in the available data.

The NVD CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a high-severity, network-accessible flaw requiring only contributor-level WordPress authentication. The PR:L requirement is the primary risk-reduction factor: in most WordPress deployments the contributor role is restricted to known users, meaningfully narrowing the attacker surface compared to unauthenticated vulnerabilities. Full RCE impact is conditional on the presence of a usable POP chain in the installed PHP class library - in a lean WordPress install this might not exist, but in a typical WooCommerce deployment the probability is high. No EPSS score was provided in the input data, so exploitation probability cannot be quantified precisely. The absence of CISA KEV listing and confirmed public exploit code suggests opportunistic mass exploitation has not yet begun, but the low attack complexity and network accessibility make this a priority for any site where contributors are not fully trusted users. No data conflicts are present, though the fixed version is not specified in available intelligence.

An attacker who holds a contributor account on the target WordPress site - obtained through registration, credential stuffing, or social engineering - crafts a serialized PHP object payload designed to trigger a POP chain available in the WooCommerce or plugin class scope. The payload is submitted through a booking-related form or AJAX endpoint handled by the vulnerable plugin without input validation, and PHP's unserialize() processes it server-side, invoking magic methods that ultimately execute arbitrary OS commands or exfiltrate the WordPress database. No public exploit code has been confirmed, but the technique is well-documented for PHP Object Injection in WordPress plugins.