Introduction
A single null return value in a WordPress plugin's permission logic is all it takes to hand over 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 that collapses the entire authorization model by treating unauthenticated users identically to site administrators.
Hippoo is a mobile store management application for WooCommerce, developed by Hamed Mayahian and available on both 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. While the install base is modest, every affected site is an e-commerce store potentially processing customer payment information and personal data, making each compromised instance 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. The vulnerability involves four interacting components that 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 fundamentally opposite security states: authenticated administrators and unauthenticated (logged out) visitors. When called for an administrator, the function 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 possesses the required role based access. When it receives null from get_user_permissions(), it unconditionally interprets that as full administrator access. 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 intended to block unauthenticated users from accessing the cloned REST routes. However, because it relies on the same flawed has_role_access() logic, it also fails to block unauthenticated visitors, since their null permission set is interpreted as administrator level access.
The interaction of these four components means the plugin's authorization framework cannot distinguish between its most privileged user (administrator) and its least privileged (anonymous visitor), and defaults to granting maximum access to both.
Code Reference Table
| File | Line | Function | Role in Vulnerability |
|---|---|---|---|
| permissions.php | 46 | get_user_permissions() | Returns null for both admins and unauthenticated visitors |
| permissions.php | 180 | has_role_access() | Interprets null as full administrator access |
| permissions.php | 622 | override_extension_permission_callback() | Assigns __return_true to all cloned REST routes |
| permissions.php | 673 | block_unauthorized_access() | Pre-dispatch guard that fails due to same null interpretation |
| permissions.php | 696 | (additional permission logic) | Part of the flawed authorization chain |
| web_api.php | 36 | re_register_external_routes() | Clones core REST routes under /wc-hippoo/v1/ext/ |
| web_api_auth.php | 79 | (authentication logic) | Part of the authentication flow being bypassed |
Attack Flow
The exploitation of CVE-2026-10580 is straightforward and requires minimal technical sophistication:
-
Identify a target: The attacker identifies a WordPress site running the Hippoo Mobile App for WooCommerce plugin (version 1.9.4 or earlier). The presence of the plugin can be inferred from the existence of the
/wc-hippoo/v1/ext/REST route namespace. -
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 typically user ID 1. -
Permission checks fail open: The request hits
block_unauthorized_access(), which callshas_role_access(), which callsget_user_permissions(). Because the attacker is unauthenticated,get_user_permissions()returnsnull.has_role_access()interprets null as full admin access and returnstrue. The pre-dispatch guard passes. The__return_truepermission callback on the cloned route also passes. -
Password is changed: The WordPress core REST API handler processes the request and changes the target user's password to the attacker specified value.
-
Full admin access: The attacker logs in with the new password and has full administrative control of the WordPress site.
The attack surface extends 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 available under /wc-hippoo/v1/ext/, including creating new administrator accounts, modifying site content, exporting user data, altering WooCommerce store configurations, or 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 within get_user_permissions() and has_role_access().
The patch introduces 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 exclusively means "authenticated administrator with full access," false means "unauthenticated or unauthorized, deny," and any other value (an array) carries role specific permission settings. This eliminates the type conflation that allowed override_extension_permission_callback() to assign __return_true as the permission callback for cloned REST routes, and prevents block_unauthorized_access() from silently passing unauthenticated requests through.
The plugin's changelog for 1.9.5 notes "Critical security fixes." An additional 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 deny all requests matching this path prefix. - Monitor WordPress user accounts for unexpected password changes or the creation of new administrator accounts, which are indicators of potential exploitation.
Wordfence has indicated that firewall rules have been provided to Wordfence Premium, Care, and Response subscribers, though the specific availability date for this CVE's rule is not documented in the sources reviewed.
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 requires 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 irony is significant: while the vendor was marketing a secure authentication product, the core Hippoo Mobile App plugin contained a fundamental authorization design flaw that completely bypassed all authentication.
The changelog shows a progression of security relevant entries:
| Version | Changelog Entry |
|---|---|
| 1.9.6 | Critical security bug fix |
| 1.9.5 | Critical security fixes |
| 1.9.4 | Hardened function against non array input |
| 1.9.0 | Compatibility mode for WooCommerce API response type mismatches |
The version 1.9.4 entry ("Hardened function against non array input") may represent a prior partial attempt to address input validation issues in the permissions system, though it did not address the fundamental null sentinel conflation. The rapid succession of two critical security releases (1.9.5 and 1.9.6) following the CVE disclosure indicates the vendor is responsive to security reports but also underscores that the plugin's authorization architecture had significant underlying weaknesses.
No information was found about a formal security development lifecycle, dedicated security team, or prior third party security audits of the Hippoo plugin codebase. The WordPress plugin repository profile "hippooo" does not list other published plugins, suggesting this is the vendor's primary WordPress offering.
References
- NVD: CVE-2026-10580
- Wordfence Threat Intel: Hippoo Mobile App for WooCommerce <= 1.9.4 Unauthenticated Authentication Bypass
- Wordfence Vulnerability ID 73835cfc-4c10-40d5-8df2-903d907326d4
- WordPress Plugin Changeset 3557733 (Patch)
- Hippoo v1.9.5 permissions.php (Patched)
- Hippoo v1.9.4 permissions.php (Vulnerable)
- Hippoo v1.8.5 permissions.php (Source Reference)
- Hippoo v1.8.5 web_api.php (Route Registration)
- Hippoo v1.8.5 web_api_auth.php (Auth Logic)
- WordPress Plugin Directory: Hippoo Mobile App for WooCommerce
- CISA Known Exploited Vulnerabilities Catalog
- VulnCheck: Quantifying 2026 Routinely Targeted Vulnerabilities



