Tabby Checkout <= 5.8.4 - Unauthenticated Information Exposure

This research plan outlines the systematic approach for identifying and exploiting the Unauthenticated Information Exposure vulnerability in the Tabby Checkout plugin (CVE-2025-68035).

1. Vulnerability Summary

The Tabby Checkout plugin (versions <= 5.8.4) contains a flaw where sensitive information is exposed to unauthorized users. This typically occurs because a developer registered a public-facing entry point (AJAX handler or REST API route) intended for frontend functionality but failed to implement proper authorization checks or data filtering. Consequently, unauthenticated attackers can retrieve sensitive configuration settings (like API keys) or user-specific transaction data by interacting with these endpoints.

2. Attack Vector Analysis

• Target Endpoint: Likely an unauthenticated AJAX action (admin-ajax.php) or a REST API route (/wp-json/).
• Vulnerable Action (Inferred): Look for actions registered with wp_ajax_nopriv_tabby_... or REST routes under the tabby/v1 namespace.
• Payload Parameter: Likely a session identifier (session_id), order identifier (order_id), or a configuration request parameter.
• Authentication: None required (unauthenticated).
• Preconditions: The plugin must be active and potentially configured with a (valid or dummy) Tabby API key to reach the logic that returns data.

3. Code Flow (Discovery Phase)

To identify the specific sink, the agent must trace the following:

1. Registration: Search the codebase for add_action( 'wp_ajax_nopriv_ or register_rest_route(.
2. Handler: Identify the function callback for these registrations.
3. Data Source: Inside the handler, look for calls to get_option(), $wpdb->get_results(), or external API requests to Tabby that return JSON.
4. Leak Point: Look for wp_send_json(), echo json_encode(), or print_r() on variables containing API keys, secret tokens, or customer PII.

Key Files to Audit:

• tabby-checkout.php (Main entry)
• includes/class-tabby-checkout.php
• includes/class-tabby-api.php
• Any file containing rest_api_init or admin_init hooks.

4. Nonce Acquisition Strategy

If the exposure is via an AJAX handler that requires a nonce (even for nopriv users), follow this strategy:

1. Identify Localization: Search for wp_localize_script in the plugin code. Look for where a nonce is generated for unauthenticated use.
2. Trigger Script Loading: Identify if the script is loaded on the WooCommerce Checkout page or a specific product page.
3. Create Test Page:

   # Create a checkout page if it doesn't exist
   wp post create --post_type=page --post_status=publish --post_title="Checkout" --post_content='[woocommerce_checkout]'
   

4. Extract Nonce:
   • Navigate to the Checkout page using browser_navigate.
   • Use browser_eval to extract the nonce.
   • Inferred JS Variable: Look for tabby_params or tabby_checkout_vars.
   • Command: browser_eval("window.tabby_params?.nonce") or browser_eval("window.tabby_checkout_vars?.ajax_nonce").

5. Exploitation Strategy

Based on the likely nature of "Information Exposure," use the http_request tool to hit the identified endpoint.

Scenario A: REST API Exposure (Most Likely)

If a route exists like /wp-json/tabby/v1/session/(?P<id>\d+):

• Method: GET
• URL: http://localhost:8080/wp-json/tabby/v1/session/1
• Goal: Capture the response body containing Tabby API credentials or customer metadata.

Scenario B: AJAX Action Exposure

If an action exists like wp_ajax_nopriv_get_tabby_config:

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Body: action=get_tabby_config&nonce=[NONCE_OBTAINED_ABOVE]
• Header: Content-Type: application/x-www-form-urlencoded

6. Test Data Setup

1. Install WooCommerce: Tabby Checkout requires WooCommerce.
2. Configure Plugin: Set a dummy Tabby Public Key and Secret Key in the settings.

   wp option update tabby_checkout_settings '{"public_key":"pk_test_12345","secret_key":"sk_test_12345"}' --format=json
   

3. Create Sample Order: An order might be necessary if the leak involves retrieving session data by order_id.

   wp wc eval 'echo (new WC_Order())->save();'
   

7. Expected Results

• Success Criteria: An unauthenticated HTTP request returns a JSON object containing sensitive keys:
  • secret_key or secret
  • public_key or api_key
  • customer_email, customer_address, or phone_number (if order-related).
• HTTP Status: 200 OK.

8. Verification Steps

1. Compare Data: Use WP-CLI to verify the leaked data matches the database.

   wp option get tabby_checkout_settings
   

2. Confirm Lack of Auth: Ensure the same http_request works in a session without any Cookie headers.

9. Alternative Approaches

• Error-Based Exposure: If the direct endpoint is patched, check if triggering an error (e.g., sending an array when a string is expected) causes a verbose error message that leaks the database prefix or file paths.
• Client-Side Leak: Check the source code of the checkout page for wp_localize_script output. If the secret_key is accidentally included in the public_params passed to the frontend, this constitutes the vulnerability.
  • Check: browser_navigate to checkout -> browser_eval("console.log(window.tabby_params)").