CVE-2026-104799 in Mobile builder Plugin
Summary
by MITRE • 11/04/2026
The Mobile builder plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.4.2 via the `wcfmmp_profile_settings()` REST handler exposed at `POST /mobile-builder/v1/wcfm-profile-settings`. This is due to a PHP loose-comparison logic flaw in the meta key allow-list check — `strpos( $key, 'mobile_builder' ) == 0` evaluates to `true` for any key that does *not* contain the substring `'mobile_builder'` because `strpos()` returns `false` on no match and `false == 0` is `true` in PHP — combined with a `permission_callback` (`user_permissions_check`) that grants access to any authenticated user by only verifying `$user->exists()`. This makes it possible for authenticated attackers, with Subscriber-level access and above, to pass an unsanitized `data` array via the `key` and `data` parameters directly to `update_user_meta()`, overwriting arbitrary user meta on their own account — including the `wp_capabilities` meta key — to grant themselves Administrator-level privileges.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The Mobile builder plugin for WordPress contains a critical privilege escalation vulnerability affecting all versions up to and including 1.4.2. This flaw resides within the REST API endpoint exposed at POST /mobile-builder/v1/wcfm-profile-settings, specifically triggered by the wcfmmp_profile_settings() function. The vulnerability allows authenticated attackers with subscriber-level access or higher to escalate their privileges to administrator level on a WordPress site running this plugin.
The root cause of this vulnerability is a PHP loose-comparison logic error in the meta key allow-list check. The code uses strpos( $key, 'mobile_builder' ) == 0 to validate whether a given meta key should be processed. In PHP, when strpos() fails to find the substring mobile_builder within the provided key string, it returns false rather than -1 or null. Due to PHP's loose comparison rules, the boolean value false is considered equal to the integer zero in this context. Consequently, any meta key that does not contain the substring mobile_builder will evaluate as true against this condition, effectively bypassing the intended allow-list restriction and allowing arbitrary keys to be processed.
Compounding this logic flaw is a permissive permission callback function named user_permissions_check. This callback grants access to the REST endpoint by simply verifying if $user->exists(), which returns true for any authenticated user regardless of their role or capabilities within WordPress. There are no additional checks to ensure that the requesting user has sufficient privileges to modify sensitive meta keys such as wp_capabilities.
An attacker can exploit this combination of flaws by sending a crafted POST request to the vulnerable endpoint with an unsanitized data array containing arbitrary key and value pairs via the key and data parameters. By specifically targeting the wp_capabilities meta key, which stores serialized arrays defining user roles and capabilities in WordPress databases, attackers can overwrite their existing role assignments. Setting this field appropriately allows them to grant themselves administrator-level privileges without needing prior administrative access or exploiting any other system weaknesses.
This vulnerability aligns with CWE-269 Improper Privilege Management as it involves unauthorized elevation of user privileges through manipulation of authentication and authorization mechanisms. It also maps to ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials to gain higher-level access within the target environment. The exploitation path demonstrates how weak input validation combined with insufficient permission checks can lead to complete system compromise at the application level.
The operational impact of this vulnerability is severe as it allows any authenticated user to take full control of their WordPress account and potentially escalate further if other vulnerabilities exist in conjunction with admin privileges. Attackers could modify site settings, install malicious plugins, access sensitive data stored by administrators, or use the compromised account for lateral movement within larger network environments where WordPress instances are interconnected.
Mitigation strategies should prioritize immediate updates to version 1.4.3 or later of the Mobile builder plugin if available from official sources. For organizations unable to update immediately, temporary mitigations include restricting access to the /mobile-builder/v1/ REST endpoint through web application firewall rules that require additional authentication factors beyond basic WordPress login status. Implementing strict input validation on all meta keys before processing and ensuring permission callbacks verify specific role capabilities rather than mere existence of user accounts would also address this vulnerability class in future development cycles.