WP BASE Booking CVE-2026-61962

The affected component is WP BASE Booking at any version up to and including 6.3.0 installed and active on a WordPress site; the code-injection sink is reachable remotely over HTTP without authentication (PR:N) and without user interaction (UI:N), so the primary prerequisite is simply that the vulnerable plugin be present and network-accessible. The main limiting factor is deployment footprint - only sites that actually run this specific booking plugin are exposed - and the exact request path or parameter carrying the payload is not disclosed in the available data, so the precise triggering feature within the plugin should be confirmed against the Patchstack advisory. There is no indication of a non-default configuration requirement, meaning default installations of the affected versions appear exploitable.

The signals available point to a genuine high priority rather than an inflated score: the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H describes remote, low-complexity, unauthenticated exploitation with high impact to confidentiality, integrity, and availability, and the vendor's scope-changed rating produces the maximal 10.0. The offsetting factor is the sparse corroboration: no EPSS probability, no CISA KEV entry, and no confirmed proof-of-concept were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Given that the barrier to abuse is minimal once a working exploit exists, defenders - from large hosting fleets down to a mid-sized municipal IT team running a handful of WordPress sites - should treat unauthenticated RCE in a booking plugin as urgent and patch ahead of any weaponization, while recognizing that the absence of EPSS/KEV data means real-world exploitation is currently unquantified rather than confirmed.

An attacker discovers a WordPress site running WP BASE Booking 6.3.0 or earlier and sends a crafted request to the plugin's booking handler containing an injected code payload, without needing any account or user interaction. The plugin evaluates the attacker-controlled input as code, executing it in the WordPress PHP context, after which the attacker plants a web shell and takes over the site. No public proof-of-concept has been confirmed in the available data, but the low attack complexity means exploitation would be trivial once a working technique is published.