CVE-2026-9180: MotoPress Appointment Booking Authorization Bypass – Unauthenticated Booking Data Modification

Technical summary

CVE-2026-9180 is an authorization bypass vulnerability in MotoPress Appointment Booking up to version 2.4.4. The REST endpoint `POST /motopress/appointment/v1/bookings` is registered with an empty permission callback (`__return_true`), permitting unauthenticated access. The `BookingsRestController::createBooking()` handler accepts attacker-supplied `payment_details.booking_id` values and uses `findById()` to load the associated booking without ownership verification. When a request with no reservation items is submitted, the plugin loads an existing booking and persists it with attacker-controlled customer data (name, email, phone, customer_id). Victim booking IDs can be enumerated via the also-unauthenticated `GET /motopress/appointment/v1/bookings/reservations` endpoint using guessable service IDs and date ranges. Only non-confirmed bookings (pending or auto-draft status) are vulnerable.

Business impact

Organizations using MotoPress for appointment scheduling face data integrity risks and potential customer experience degradation. Attackers can corrupt customer records in pending bookings, leading to incorrect contact information, lost follow-up communications, and customer confusion. This could result in missed appointments, billing complications, and reputational harm if customers receive communications addressed to incorrect names or phone numbers. Multi-tenant booking environments are particularly at risk, as cross-customer data tampering becomes feasible.

Affected systems

All versions of the MotoPress Appointment Booking plugin for WordPress up to and including version 2.4.4 are affected. WordPress sites with this plugin installed and the REST API enabled are vulnerable if they accept appointment bookings through the plugin's standard interface.

Exploitability

Exploitation requires no authentication, no user interaction, and no special network access—only HTTP POST capability to the target WordPress site. The attack is straightforward: an attacker discovers valid booking IDs (via the public reservations endpoint or through enumeration), then submits a POST request with attacker-controlled customer data and a target booking ID. The barrier to exploitation is low, making this a practical attack vector for adversaries targeting booking systems. However, the impact is limited to non-confirmed bookings, which narrows the window of opportunity.

Remediation

Update MotoPress Appointment Booking to a patched version released after July 2026. Verify the specific version number in the vendor's security advisory. If a patch is not immediately available, disable or remove the plugin until remediation is confirmed. Additionally, review recent booking modifications in your plugin logs to identify any suspicious changes to customer details in pending bookings.

Patch guidance

Check the MotoPress plugin repository or vendor advisory for the patch version that resolves this issue. Apply updates through the WordPress plugin dashboard or via direct file replacement, following the vendor's upgrade instructions. After patching, verify that the REST endpoint permission callback is properly enforced and that booking modification requests require ownership verification. Test with a non-admin user account to confirm that unauthenticated access to booking endpoints is blocked.

Detection guidance

Monitor for POST requests to `/motopress/appointment/v1/bookings` from unexpected or unauthenticated sources. Log and alert on modifications to booking records where the `customer_id`, customer name, email, or phone number changes without corresponding confirmed payment status. Query your booking database for records with sudden customer detail changes in non-confirmed bookings, particularly if the modification timestamp aligns with periods of unusual traffic. Examine WordPress REST API logs for repeated requests to the bookings endpoint with different booking IDs (enumeration pattern).

Why prioritize this

Although the CVSS score is MEDIUM (5.3) with no integrity loss potential, this vulnerability merits prompt remediation because it enables unauthenticated data modification on customer-facing systems. The ease of exploitation combined with direct access to customer PII (email, phone, name) creates friction for customers and potential fraud vectors. The lack of CISA KEV status should not delay patching, as the technical barrier is negligible. Organizations should prioritize patching within standard maintenance cycles, not on emergency timelines.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects: AV:N (network-accessible endpoint), AC:L (low complexity exploitation), PR:N (no authentication required), UI:N (no user interaction needed), and I:L (limited integrity impact—customer data modification only, not system compromise or data destruction). The score appropriately reflects a moderate risk suitable for standard patch management rather than emergency response, though the practical ease of exploitation warrants attention.

Frequently asked questions