Vitepos – Point of Sale (POS) for WooCommerce <= 3.4.2 - Unauthenticated Information Exposure

This plan targets CVE-2026-54841, an Unauthenticated Information Exposure vulnerability in the Vitepos – Point of Sale (POS) for WooCommerce plugin (<= 3.4.2).

1. Vulnerability Summary

The Vitepos plugin fails to implement proper authorization checks on several of its REST API endpoints used for POS initialization. Specifically, endpoints intended to provide data to the POS login screen (such as the list of outlets, users, and general configuration) are registered with a permission_callback that either defaults to __return_true or is absent, allowing any unauthenticated user to query sensitive store and user data.

2. Attack Vector Analysis

• Endpoint: WordPress REST API.
• Target Routes (Inferred based on Vitepos architecture):
  • /wp-json/vitepos/v1/get-init-data (Primary target for full info exposure)
  • /wp-json/vitepos/v1/get-settings
• Method: GET (or POST in some configurations).
• Authentication: None required (Unauthenticated).
• Preconditions: The plugin must be active. No specific POS configuration is required to expose the default initialization data.

3. Code Flow

1. Route Registration: The plugin registers REST routes during the rest_api_init hook.
2. Missing Authorization: In the vulnerable version, the registration for get-init-data lacks a strict permission check (e.g., current_user_can( 'manage_woocommerce' )).
3. Data Compilation: The handler function (typically in a class like VitePos_API) fetches:
   • get_users(): Returns user details for the POS login selection.
   • get_outlets(): Returns store locations and addresses.
   • get_settings(): Returns WooCommerce and POS specific configuration.
4. Information Leak: The compiled data is returned as a JSON object to any requester.

4. Nonce Acquisition Strategy

While the vulnerability is "unauthenticated," WordPress REST API requests usually require a wp_rest nonce if a session is present. However, for a purely unauthenticated attack (no cookies), the REST API often allows access to public routes without a nonce.

If the endpoint requires a nonce even for unauthenticated users (to prevent direct scraping), we will extract it from the POS login page:

1. Shortcode Identification: Vitepos typically uses the shortcode [vitepos] or a dedicated page created at install (usually slug /pos).
2. Environment Setup: Create a page containing the POS shortcode to ensure scripts are enqueued.
3. Variable Extraction: The plugin localizes data into a JavaScript object. Based on assets/js/admin-script.js, the global object is likely vitepos_lite_obj.
4. Action: Use browser_eval to extract the nonce:
   • browser_eval("window.vitepos_lite_obj?.nonce")

5. Exploitation Strategy

We will attempt to access the initialization data via the REST API.

Step 1: Discover Active Vitepos Routes
Query the REST API index to confirm the exact route name for the current version.

• Request: GET /wp-json/vitepos/v1
• Tool: http_request

Step 2: Extract Sensitive Data
Attempt to access the get-init-data endpoint.

• Request: GET /wp-json/vitepos/v1/get-init-data
• Headers: Content-Type: application/json
• Expected Response: A JSON object containing users, settings, and outlets.

Step 3: Alternative Route (Settings)
If get-init-data is restricted, attempt the settings endpoint.

• Request: GET /wp-json/vitepos/v1/get-settings

6. Test Data Setup

To verify information exposure, we need a "victim" environment with data to leak:

1. Users: Create a few users with different roles (e.g., cashier, customer).
   • wp user create cashier_test cashier@example.com --role=author
2. Plugin Setup: Ensure Vitepos is active.
3. Page Creation: Create the POS page to verify if nonces are needed.
   • wp post create --post_type=page --post_title="POS" --post_status=publish --post_content='[vitepos]' --post_name='pos'

7. Expected Results

A successful exploit will return a 200 OK response with a JSON body containing:

• User Data: Usernames, IDs, and potentially emails of staff members.
• Store Info: Outlet names, addresses, and phone numbers.
• Config: Internal plugin settings that may reveal WooCommerce configuration details.

8. Verification Steps

After the HTTP request, verify the data matches the database:

1. Compare the leaked usernames/emails with the output of:
   • wp user list --fields=user_login,user_email
2. Check if any "secret" or internal settings leaked match the options table:
   • wp option get vitepos_lite_settings (inferred option name)

9. Alternative Approaches

If the REST API is disabled or blocked by a security plugin, check for an equivalent AJAX action:

• Action: vitepos_get_init_data or vps_get_init_data
• Request: GET /wp-admin/admin-ajax.php?action=vitepos_get_init_data
• Note: This would also require a nonce, likely found in the vitepos_lite_obj on the /pos page.