CVE-2026-6072: Oliver POS WooCommerce Auth Bypass Flaw

CVE-2026-6072 Overview

CVE-2026-6072 is an authorization bypass vulnerability in the Oliver POS – A WooCommerce Point of Sale (POS) plugin for WordPress, affecting all versions up to and including 2.4.2.6. The plugin's oliver_pos_rest_authentication() permission callback uses a loose PHP comparison (==) to validate the OliverAuth header against the stored oliver_pos_authorization_token option. On fresh installations where the connection flow has not been completed, the option returns false, and PHP type juggling causes '0' == false to evaluate to true. An unauthenticated attacker can send OliverAuth: 0 to access the entire /wp-json/pos-bridge/* REST API namespace.

Critical Impact

Unauthenticated attackers can read administrator details, modify user email addresses, and delete non-admin users, enabling full site takeover through admin email reset.

Affected Products

• Oliver POS – A WooCommerce Point of Sale (POS) plugin for WordPress
• All versions up to and including 2.4.2.6
• WordPress sites with the plugin installed but not yet connected

Discovery Timeline

• 2026-05-20 - CVE-2026-6072 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-6072

Vulnerability Analysis

The vulnerability is classified under [CWE-639: Authorization Bypass Through User-Controlled Key]. The Oliver POS plugin exposes a REST API namespace at /wp-json/pos-bridge/* and protects every endpoint with a single permission callback named oliver_pos_rest_authentication(). This callback retrieves the stored token via get_option('oliver_pos_authorization_token') and compares it to the attacker-controlled OliverAuth request header.

The comparison uses PHP's loose equality operator (==) instead of strict equality (===). PHP type juggling rules cause unexpected matches between values of different types during loose comparisons. When the plugin is freshly installed and the admin has not completed the connection flow, get_option() returns false, which collides with several attacker-supplied string values during loose comparison.

Root Cause

The root cause is the combination of two flaws. First, the plugin does not validate that the authorization token has been initialized before performing the comparison. Second, the use of == allows PHP to coerce types so that '0' == false evaluates to true. A strict comparison using === would have prevented the bypass, as would explicit handling of the uninitialized option state.

Attack Vector

An unauthenticated remote attacker sends an HTTP request to any /wp-json/pos-bridge/* endpoint with the header OliverAuth: 0. The permission callback returns true, granting full access to POS API endpoints. The attacker can then enumerate users including administrators, update an administrator's email address, trigger a password reset to the attacker-controlled email, and complete account takeover. The attacker can also delete non-admin user accounts. See the Wordfence Vulnerability Report and the vulnerable callback source for technical details.

Detection Methods for CVE-2026-6072

Indicators of Compromise

• HTTP requests to /wp-json/pos-bridge/* endpoints containing the header OliverAuth: 0 or other values that loosely match false.
• Unexpected administrator email address changes followed by password reset requests.
• Deletion of non-admin user accounts without corresponding administrator activity in WordPress audit logs.
• New requests targeting POS API user-management routes from IP addresses with no prior session history.

Detection Strategies

• Inspect web server access logs for requests to /wp-json/pos-bridge/ paths originating from unauthenticated sessions.
• Monitor WordPress user-meta and wp_users table changes, correlating email updates with REST API request sources.
• Alert on HTTP requests containing the OliverAuth header where the value is 0, empty, or a known PHP type-juggling string.

Monitoring Recommendations

• Enable verbose logging of REST API authentication events in WordPress.
• Forward webserver and WordPress logs to a centralized log platform for correlation across user-modification and authentication events.
• Track the value of the oliver_pos_authorization_token option to identify installations that remain unconfigured and therefore vulnerable.

How to Mitigate CVE-2026-6072

Immediate Actions Required

• Update the Oliver POS plugin to a version newer than 2.4.2.6 once the vendor releases a patched release.
• If no patched version is available, deactivate and remove the plugin from any WordPress site where the POS connection flow has not been completed.
• Audit administrator accounts for unauthorized email address changes and reset credentials where tampering is suspected.
• Review the user table for missing non-admin accounts and restore from backup if deletions are detected.

Patch Information

As of the NVD publication date of 2026-05-20, the advisory references the plugin source at version 2.4.2.6 as vulnerable. Site administrators should monitor the WordPress plugin repository for Oliver POS and the Wordfence Vulnerability Report for the fixed release.

Workarounds

• Block all external requests to /wp-json/pos-bridge/* at the web application firewall or reverse proxy until the plugin is patched.
• Use a WAF rule that rejects requests carrying an OliverAuth header value of 0, empty string, or null.
• Force completion of the Oliver POS connection flow so that oliver_pos_authorization_token is set to a non-falsy value, eliminating the type-juggling collision.
• Restrict REST API access to authenticated users at the WordPress configuration level where business requirements permit.

# Example ModSecurity rule to block the bypass header
SecRule REQUEST_URI "@beginsWith /wp-json/pos-bridge/" \
    "id:1006072,phase:1,deny,status:403,\
    chain,msg:'CVE-2026-6072 Oliver POS auth bypass attempt'"
    SecRule REQUEST_HEADERS:OliverAuth "@rx ^(0|false|)$" "t:none"