Automated Threat Modeling

Hippoo Mobile App for WooCommerce CVE-2026-10580: Quick Look at a Null Sentinel Logic Flaw Leading to Unauthenticated Admin Takeover

CVE-2026-10580 is a CVSS 9.8 authentication bypass in the Hippoo Mobile App for WooCommerce plugin that lets unauthenticated attackers reset any user's password with a single REST API request. This post covers the patch analysis and mitigation guidance.

CVE Analysis

10 min read

ZeroPath CVE Analysis
ZeroPath CVE Analysis

2026-06-05

Hippoo Mobile App for WooCommerce CVE-2026-10580: Quick Look at a Null Sentinel Logic Flaw Leading to Unauthenticated Admin Takeover
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

One null return value in a WordPress plugin's permission logic is enough to hand full administrator access to any anonymous visitor on the internet. CVE-2026-10580, disclosed on June 5, 2026, is a CVSS 9.8 authentication bypass in the Hippoo Mobile App for WooCommerce plugin. It collapses the authorization model by treating unauthenticated users the same as site administrators.

Hippoo is a mobile store management application for WooCommerce, developed by Hamed Mayahian and available on iOS and Android. The WordPress plugin has over 1,000 active installations and targets WooCommerce store operators with features like order fulfillment, inventory management, barcode scanning, and multi-shop management. The install base is modest, but every affected site is an e-commerce store that may process customer payment information and personal data, so each compromised instance is a high-value target.

Technical Information

The Null Sentinel Conflation

The root cause of CVE-2026-10580 is a logic conflation in the HippooPermissions class within permissions.php. Four interacting components together produce a complete authorization collapse.

1. get_user_permissions() (line 46 of permissions.php)

This function determines the permission set for the current user. In versions up to 1.9.4, it returns the same null sentinel value for two opposite security states: authenticated administrators and unauthenticated (logged out) visitors. When called for an administrator, it returns null rather than a structured permission object. When called for a user with no authentication session, it also returns null. Two opposite security states, one return value.

2. has_role_access() (line 180 of permissions.php)

This function checks whether a user has the required role-based access. When it receives null from get_user_permissions(), it interprets that as full administrator access. That is the critical error: a null return should signal a failure to determine permissions, not grant maximum permissions.

3. override_extension_permission_callback() (line 622 of permissions.php)

Based on the result from has_role_access(), this function assigns __return_true (the WordPress PHP function that always returns true) as the permission callback for every WordPress and WooCommerce REST route cloned under the /wc-hippoo/v1/ext/ namespace by HippooControllerWithAuth::re_register_external_routes() (defined in web_api.php at line 36). Every cloned REST endpoint becomes completely open.

4. block_unauthorized_access() (line 673 of permissions.php)

This pre-dispatch guard is meant to block unauthenticated users from the cloned REST routes. But it relies on the same flawed has_role_access() logic, so it also fails to block unauthenticated visitors, whose null permission set is read as administrator-level access.

Together, these four components mean the plugin's authorization framework cannot tell its most privileged user (administrator) from its least privileged (anonymous visitor), and it grants maximum access to both.

Code Reference Table

FileLineFunctionRole in Vulnerability
permissions.php46get_user_permissions()Returns null for both admins and unauthenticated visitors
permissions.php180has_role_access()Interprets null as full administrator access
permissions.php622override_extension_permission_callback()Assigns __return_true to all cloned REST routes
permissions.php673block_unauthorized_access()Pre-dispatch guard that fails due to same null interpretation
permissions.php696(additional permission logic)Part of the flawed authorization chain
web_api.php36re_register_external_routes()Clones core REST routes under /wc-hippoo/v1/ext/
web_api_auth.php79(authentication logic)Part of the authentication flow being bypassed

Attack Flow

Exploiting CVE-2026-10580 is simple and needs little technical skill:

  1. Identify a target: The attacker finds a WordPress site running the Hippoo Mobile App for WooCommerce plugin (version 1.9.4 or earlier). The plugin's presence can be inferred from the /wc-hippoo/v1/ext/ REST route namespace.

  2. Send a single POST request: The attacker sends an unauthenticated HTTP POST request to /wc-hippoo/v1/ext/wp/v2/users/<id> with a JSON body of {"password":"<new_password>"}, where <id> is the numeric ID of the target user. The site administrator is usually user ID 1.

  3. Permission checks fail open: The request hits block_unauthorized_access(), which calls has_role_access(), which calls get_user_permissions(). Because the attacker is unauthenticated, get_user_permissions() returns null. has_role_access() reads null as full admin access and returns true. The pre-dispatch guard passes. The __return_true permission callback on the cloned route also passes.

  4. Password is changed: The WordPress core REST API handler processes the request and changes the target user's password to the attacker-specified value.

  5. Full admin access: The attacker logs in with the new password and has full administrative control of the WordPress site.

The attack surface goes well beyond password resets. Because every core WordPress and WooCommerce REST endpoint is cloned with a __return_true permission callback, an attacker can invoke any REST endpoint under /wc-hippoo/v1/ext/. That includes creating new administrator accounts, modifying site content, exporting user data, altering WooCommerce store configurations, and installing plugins and themes.

Patch Information

The vulnerability was patched in version 1.9.5 of the Hippoo Mobile App for WooCommerce plugin, released on June 2, 2026 via WordPress plugin changeset 3557733. The fix targets the core permission logic in app/permissions.php, specifically get_user_permissions() and has_role_access().

The patch makes three surgical changes to eliminate the null sentinel conflation.

1. Explicit unauthenticated user rejection in get_user_permissions()

The old guard clause only checked whether the WordPress user object existed. The patched version adds an is_user_logged_in() check and changes the return value from null to false:

// BEFORE (v1.9.4) if (empty($user) || !$user->exists()) { return null; // ← treated as admin downstream! } // AFTER (v1.9.5) if (empty($user) || !$user->exists() || !is_user_logged_in()) { return false; // ← now correctly denied }

This is the most critical change. By returning false instead of null, unauthenticated requests are no longer indistinguishable from administrator sessions.

2. Default fallback changed from "full access" to "no access"

When a logged-in user's roles did not match any entry in the hippoo_permissions_settings option, the old code fell through to return null; // Full access. The patch changes this to return false; // No access, enforcing a deny-by-default posture:

// BEFORE (v1.9.4) return null; // Full access // AFTER (v1.9.5) return false; // No access

3. New false handling in has_role_access()

The has_role_access() method, called by both block_unauthorized_access() and override_extension_permission_callback(), now explicitly handles the new false state:

// AFTER (v1.9.5) if ($perms === null) { return true; // admin } if ($perms === false) { return false; // ← NEW: explicit denial }

With this three-part fix, the permission state space is cleanly partitioned: null means only "authenticated administrator with full access," false means "unauthenticated or unauthorized, deny," and any other value (an array) carries role-specific permission settings. This removes the type conflation that let override_extension_permission_callback() assign __return_true as the permission callback for cloned REST routes, and it stops block_unauthorized_access() from silently passing unauthenticated requests through.

The plugin's changelog for 1.9.5 notes "Critical security fixes." A further version 1.9.6 was released with "Critical security bug fix." Users should update to at least version 1.9.5, though 1.9.6 is the current latest.

Compensating Controls

When an immediate plugin update is not feasible:

  • Disable the Hippoo plugin entirely until the update can be applied. This removes the vulnerable /wc-hippoo/v1/ext/ namespace.
  • Block access to /wc-hippoo/v1/ext/ using a WAF rule or server-level access control (nginx/Apache rewrite rules) that denies all requests matching this path prefix.
  • Monitor WordPress user accounts for unexpected password changes or new administrator accounts, which are indicators of possible exploitation.

Wordfence has indicated that firewall rules have been provided to Wordfence Premium, Care, and Response subscribers, though the sources reviewed do not document the specific availability date for this CVE's rule.

Affected Systems and Versions

  • Plugin: Hippoo Mobile App for WooCommerce
  • Affected versions: All versions up to and including 1.9.4
  • Patched version: 1.9.5 (with additional fix in 1.9.6)
  • Platform: WordPress 5.3 and higher (tested up to WordPress 6.9.4)
  • Active installations: 1,000+ per the WordPress plugin directory
  • CWE: CWE-285 (Improper Authorization)
  • CVSS 3.1: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Any WordPress site running the Hippoo Mobile App for WooCommerce plugin at version 1.9.4 or earlier is vulnerable. The vulnerability needs no special configuration; the default plugin installation exposes the flawed REST route namespace.

Vendor Security History

The Hippoo plugin's security track record is limited but notable. In June 2025, the vendor released a companion plugin called "Hippoo Auth," a JWT-based authentication system for WooCommerce supporting social login and traditional email/password authentication, marketed as providing "secure, stateless authentication ensuring every API request is verified to protect user data." The contrast is striking: while the vendor marketed a secure authentication product, the core Hippoo Mobile App plugin carried an authorization design flaw that bypassed all authentication.

The changelog shows a run of security-relevant entries:

VersionChangelog Entry
1.9.6Critical security bug fix
1.9.5Critical security fixes
1.9.4Hardened function against non array input
1.9.0Compatibility mode for WooCommerce API response type mismatches

The 1.9.4 entry ("Hardened function against non array input") may be a prior partial attempt to address input validation in the permissions system, though it did not address the underlying null sentinel conflation. The two critical security releases in quick succession (1.9.5 and 1.9.6) after the CVE disclosure show the vendor responds to security reports, but they also show the plugin's authorization architecture had significant underlying weaknesses.

The sources reviewed found no information about a formal security development lifecycle, a dedicated security team, or prior third-party security audits of the Hippoo codebase. The WordPress plugin repository profile "hippooo" does not list other published plugins, which suggests this is the vendor's primary WordPress offering.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Gerrit
  • CVS
  • Jira
  • Linear
  • Slack
  • Security Compass
Explore integrations
Security magnifying glass visualization