MotoPress Hotel Booking CVE-2026-15237

The WordPress REST API must be accessible from the network, which is the default state for all modern WordPress installations - no special server configuration or feature enablement is required. The attacker must know or enumerate a valid booking ID to target; booking IDs may be sequential integers or exposed through confirmation flows. No authentication, administrative credentials, or privileged access is required - exploitation is unauthenticated by design of the flaw (CVSS PR:N). Exploitation is bounded to booking payment integrity: the attacker cannot read confidential data, execute code, or disrupt availability. Sites that have explicitly disabled the WordPress REST API for unauthenticated users, or that enforce REST API authentication globally via a security plugin, would not be exploitable.

The NVD CVSS score of 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N accurately reflects the technical exposure: trivially reachable with no prerequisites, but limited to an integrity-only impact with no scope change. The I:L rating, however, understates the business logic impact - forging payments can cause direct revenue loss to hotel operators accepting bookings for which no money was received. EPSS at 0.15% (4th percentile) suggests low automated/widespread exploitation activity, consistent with absence from CISA KEV. The availability of a public POC from WPScan elevates risk above purely theoretical: opportunistic attackers targeting WordPress hotel sites are technically capable of exploiting this with minimal effort. The gap between low EPSS and trivial attack complexity (AC:L/PR:N) may narrow as the POC circulates. Overall: legitimate medium-severity finding with outsized business-logic consequences for affected hospitality operators; patching is clearly warranted.

An attacker targeting a hotel website identifies it is running a vulnerable version of MotoPress Hotel Booking - discoverable via WordPress plugin enumeration. The attacker obtains a booking reference ID (through a legitimate reservation, confirmation email exposure, or sequential enumeration) and sends an unauthenticated HTTP POST request to the plugin's payment REST endpoint specifying that booking ID and a completed payment status. The booking is immediately marked as paid in the system, allowing the attacker or a collaborating guest to receive reservation confirmation with no actual payment processed. A publicly available proof-of-concept from WPScan demonstrates this technique.