Exploitation Research Plan: CVE-2026-57347 - MotoPress Hotel Booking Information Exposure

1. Vulnerability Summary

The MotoPress Hotel Booking plugin (including the Lite version) is vulnerable to Sensitive Information Exposure via its REST API. In versions up to and including 6.0.3, the REST API endpoints for managing "Booking Blocks" (rules that restrict dates or rooms) do not implement sufficient capability checks. This allows authenticated users with low-level privileges, such as Subscribers, to access internal booking rules, room configuration data, and potentially sensitive comments associated with date blocks.

The vulnerability resides in the controllers located in includes/advanced/api/controllers/v1/, specifically within the GetBlockController class, which lacks an adequately restrictive permission_callback.

2. Attack Vector Analysis

• Endpoint: /wp-json/mphb/v1/booking_rules/blocks/(?P<block_id>[\d]+)
• HTTP Method: GET (for Information Exposure)
• Authentication: Required (Subscriber role is sufficient).
• REST Namespace: mphb/v1 (inferred from MPHB\Advanced\Api\Controllers\V1).
• REST Route: booking_rules/blocks/
• Payload: A valid block_id (integer) passed in the URL.
• Preconditions: At least one "Block" (booking rule) must exist in the system for exposure.

3. Code Flow

1. Entry Point: The REST API server receives a request for GET /wp-json/mphb/v1/booking_rules/blocks/{block_id}.
2. Controller Routing: The request is routed to MPHB\Advanced\Api\Controllers\V1\GetBlockController.
3. Capability Check (The Vulnerability): The controller (via its parent AbstractRestCommandController) uses a permission_callback that likely only checks if the user is logged in (is_user_logged_in()) or has a very low-level capability, rather than checking for manage_options or edit_posts.
4. Data Retrieval: The process_and_get_data_by_response_schema( \WP_REST_Request $request ) function is called.
5. Logic Path:
   • It retrieves the block_id via $request->get_param( 'block_id' ).
   • It calls MPHB()->getBlocksRepository()->getItem( $blockId ).
6. Sink: The block data is returned as a JSON object, exposing properties like comment, date_from, date_to, room_id, and room_type_id (defined in RestApiSchemaHelper::getBlockProperties()).

4. Nonce Acquisition Strategy

REST API requests in WordPress require a _wpnonce parameter or an X-WP-Nonce header when using cookie-based authentication. Since the attacker is a Subscriber, they can log into the WordPress dashboard and extract the global REST nonce.

1. Login: Authenticate as a Subscriber user.
2. Access Dashboard: Navigate to /wp-admin/profile.php.
3. Extract Nonce: Use browser_eval to extract the nonce from the wpApiSettings object which is standard in WordPress admin pages.
   • JS Command: browser_eval("wpApiSettings.nonce")
4. Usage: Include this nonce in the X-WP-Nonce header of the subsequent API request.

5. Exploitation Strategy

Step 1: Data Discovery (Optional but recommended)

If specific block_id values are unknown, an attacker might try to list all blocks if a plural GetBlocksController exists (standard REST pattern). If not, they can brute-force IDs (e.g., 1, 2, 3).

Step 2: Extract Sensitive Data

Request:

• URL: http://localhost:8080/wp-json/mphb/v1/booking_rules/blocks/1
• Method: GET
• Headers:
  • X-WP-Nonce: [EXTRACTED_NONCE]
  • Content-Type: application/json
  • Cookie: [SUBSCRIBER_COOKIES]

Expected Vulnerable Response:

{
  "block_id": 1,
  "comment": "Internal Note: VIP guest, do not overbook. Customer phone: +123456789",
  "date_from": "2024-12-01",
  "date_to": "2024-12-10",
  "room_id": 45,
  "room_type_id": 10,
  "has_restrictions": true
}

6. Test Data Setup

To verify the exposure, a "Block" must be created by an Admin:

1. Log in as Admin.
2. Go to Accommodation -> Booking Rules.
3. Create a New Block (Restriction).
4. Enter a sensitive comment: Secret: Room maintenance needed for guest John Doe.
5. Note the ID of the created block (can be found in the database table wp_mphb_blocks or by checking the URL in the admin UI).
6. Create a Subscriber user.

7. Expected Results

• Vulnerable: The Subscriber receives a 200 OK response with the full block object, including the comment field.
• Fixed: The Subscriber receives a 403 Forbidden or 401 Unauthorized response with a message indicating they lack permission to view this resource.

8. Verification Steps

1. WP-CLI Verification: After the exploit, verify the data matches the database.
   • wp db query "SELECT * FROM wp_mphb_blocks WHERE block_id = 1;"
2. Check Access Logs: Ensure the request was made by the Subscriber user ID.

9. Alternative Approaches

If GET access is blocked but the vulnerability title implies broader exposure, investigate:

• POST /wp-json/mphb/v1/booking_rules/blocks: Creating a block as a Subscriber.
• DELETE /wp-json/mphb/v1/booking_rules/blocks/1: Deleting blocks as a Subscriber (DeleteBlockController).
• Brute-forcing block_id values using a script to dump the entire wp_mphb_blocks table via the GET endpoint.