Improper Privilege Management

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.Show less

phpMyFAQ before 4.1.9 contains a missing authorization vulnerability in the deleteUser() API that allows authenticated non-superadmin users with delete_user permission to delete superadmin accounts. Attackers can send a DELETE request to /admin/api/user/delete with a superadmin's userId other than 1, removing administrative access and accountability.Show less

phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains a privilege escalation vulnerability in GroupController::saveCategoryRestrictions() that lets delegated administrators assign categories outside their own scope. Category-restricted administrators can POST to /admin/api/group/category-restrictions with out-of-scope or empty categoryIds to grant groups unrestricted category access.Show less

phpMyFAQ from 4.2.0-alpha.2 before 4.2.0-beta contains a privilege escalation vulnerability in the group permission API, whose updatePermissions and updateMembers endpoints check held rights without regard to language or category scope and write unrestricted group grants. Non-superadmin administrators holding GROUP_EDIT can grant a group a right they hold only in a narrow scope and self-join it via updateMembers, gaining unrestricted FAQ create, edit, and publish access across all languages and categories.Show less

phpMyFAQ from 4.2.0-alpha.2 before 4.2.0-beta contains a privilege escalation vulnerability in UserController::updateUserRights that drops per-right language restrictions when rights are re-granted. Administrators holding USER_EDIT can submit language-scoped rights to the update-rights API, including for themselves, to gain unrestricted FAQ create, edit, and publish access across all languages.Show less

Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 2.6.0, UpdateUser in backend/api/handlers/users.go sets PasswordHash for any target without comparing caller and target privilege. A holder of delegated users:update permission can submit a password change for the global administrator, replace the administrator password, and authenticate as that account, resulting in complete global administrator account takeover. This issue is fixed in version 2.6.0.Show less

WhaTicket Community through commit cf04795 contains an authentication bypass vulnerability that allows unauthenticated attackers to self-register as administrators via POST /auth/signup. Attackers can omit the profile field or set it to admin, gaining user management, settings, and access to all tickets, contacts, messages, and WhatsApp connections.Show less

Mailu is a mail server distributed as a set of Docker images. Prior to 8577c929b4ade04d3cd4210cf036601abd793556, a domain manager targeting an administrative account or another domain manager with greater privileges can reset passwords or obtain tokens for that account. This authorization failure allows a domain manager to take over a higher-privileged account and exercise that account's permissions. This vulnerability is addressed by commit 8577c929b4ade04d3cd4210cf036601abd793556.Show less

The WP Compress – Instant Performance & Speed Optimization plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 7.25.00 The vulnerability exists because the `start_comms` dispatcher (`wps_ic_comms::start_comms`), hooked on every front-end request, gates access only by comparing the caller-supplied `apikey` parameter against the stored plugin API key with no WordPress capability check and no nonce verification, then passes the unvalidated `group`, `setting`, and `value` parameters directly to `change_setting()`, which writes them into the `WPS_IC_SETTINGS` option without an allow-list. This makes it possible for unauthenticated attackers to write arbitrary permission keys into the plugin's settings, causing `wps_ic_users::checkAndAddCaps()` to grant any WordPress role — including Subscriber — the `manage_wpc_settings` capability and thereby achieve plugin-administrator-equivalent control over the plugin's optimization, CDN, and critical-CSS surfaces. The API key required to pass the authorization check can itself be obtained without authentication via the `wpc_send_critical_remote` nopriv AJAX action: when the external critical-CSS service returns an `apiResults` field, `initCritical()` echoes the stored plugin API key back to the caller in a `wp_send_json_success` response, completing the exploit chain entirely without a WordPress login.Show less

The Theme My Login plugin for WordPress is vulnerable to privilege escalation via account takeover in versions up to, and including, 7.2.1. This is due to the plugin not properly validating a user's identity prior to updating their password. This makes it possible for unauthenticated attackers to change arbitrary user's passwords on multi-site setups in certain configurations.Show less

The PilotPress plugin for WordPress is vulnerable to Privilege Escalation via Account Takeover in all versions up to, and including, 2.0.43. The vulnerability exists because the `update_cc_details()` AJAX handler forwards an attacker-supplied `username` parameter to ONTRAPORT via `api_call('update_cc_details', ...)` before performing the local `username_exists()` collision check, and aborts without rolling back the remote rename when a collision is detected — leaving the remote ONTRAPORT contact renamed to an existing WordPress Administrator's login. On a subsequent login attempt, `user_login()` (hooked to `wp_authenticate`) authenticates against ONTRAPORT using the renamed login and the attacker's own password, resolves the local WordPress user row via `get_user_by('login', $username)` — which now selects the real Administrator's row — and calls `wp_set_password()` against that Administrator's user ID; because the `user_level != 10` guard only suppresses PilotPress's own cookie issuance rather than returning a `WP_Error` to core, WordPress proceeds to validate the newly-synchronized password and issues a full Administrator authentication cookie to the attacker. This makes it possible for authenticated attackers with Subscriber-level access and above — specifically any PilotPress member holding a valid ONTRAPORT contact and the Customer Center nonce — to fully take over an Administrator account.Show less

The User Profile Builder – Beautiful User Registration Forms, User Profiles & User Role Editor plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 4.0.3 via the `role` parameter handled by the `wppb_add_meta_to_user_on_activation()` function. The vulnerability exists because the activation handler passes the attacker-supplied role value directly to `WP_User::set_role()` with no allow-list validation, and the 4.0.3 reserved-name check exempts pre-existing form fields from the block, allowing a legacy field with meta-name `role` to persist and bridge attacker-controlled request input into the serialized signup record stored in `wp_signups`. This makes it possible for unauthenticated attackers to gain a fully activated WordPress administrator account by submitting `role=administrator` through the public `[wppb-register]` shortcode form and subsequently clicking the confirmation activation link. Exploitation requires the site to have a legacy form field with meta-name `role` carried over from before the 4.0.3 upgrade, email confirmation enabled, and open user registration — all stable site-state conditions once established.Show less

The Nexter Extension – Security, Performance, Code Snippets & Site Toolkit plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 4.7.11 The vulnerability exists because the `/?reset-view` handler in `role_switcher_to_view_admin_as()` performs no nonce or capability check when the supplied username matches the authenticated caller, and because the plugin's only cleanup mechanism — the `profile_update` hook — does not fire when WordPress performs a bulk role change via `wp-admin/users.php?action=promote`, which calls `WP_User::set_role()` directly and leaves a stale `administrator` value in the `nxtext_view_admin_original_role` user meta. This makes it possible for authenticated attackers with Subscriber-level access or above to restore the stale stored Administrator role to their own account, effectively escalating their privileges to Administrator. Exploitation requires that the attacker's account previously held the Administrator role and used the View Admin Role Switcher feature before being demoted specifically through the bulk role-change control rather than the Edit User screen, as only the bulk path bypasses the `profile_update` hook that would otherwise have cleared the stored original role.Show less

The MailOptin – Popup, Optin Forms & Email Newsletters for Mailchimp, HubSpot, AWeber Etc. plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.2.78.6 This is due to the `subscribe_to_email_list` endpoint accepting an attacker-supplied `optin_data[form_custom_field_mappings]` parameter without any allow-list validation on destination keys, allowing the attacker-controlled mapping to override the administrator's saved mapping and pass arbitrary `wp_users` column names — including `ID` and `user_pass` — directly into `wp_insert_user()` via the `subscribe()` function. This makes it possible for unauthenticated attackers to force `wp_insert_user()` into UPDATE mode on any existing account by supplying a target user's numeric `ID`, overwrite that account's password with a pre-hashed value of their choosing, and thereby take over any WordPress user account — including administrators — leading to full site compromise. Exploitation requires that a WordPress User Registration opt-in form is published somewhere on the site, though the form's UUID is visible in page source and no authentication, nonce, or capability check is required to reach the vulnerable endpoint.Show less

The InstaWP Connect – 1-click WP Staging & Migration plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 0.1.4.1 This is due to the plugin registering its admin page via `add_management_page()` using a role name returned by `InstaWP_Setting::get_allowed_role()` as the required capability — which WordPress resolves as a real capability match for any user holding that role — combined with `generate_section_field()` rendering the master API key from the `instawp_api_options` option directly as the `value` attribute of a plain-text HTML input with no additional `manage_options` or equivalent capability check. This makes it possible for authenticated attackers with Subscriber-level access and above to read the plaintext master API key, use its SHA-256-derived secret as a bearer token accepted by the plugin's REST API `validate_api_request()`, and call `POST /wp-json/instawp-connect/v2/auto-login` to mint a 30-second single-use login URL that sets an administrator authentication cookie — fully escalating their privileges. Exploitation requires the site to be actively connected to InstaWP and an administrator to have added the attacker's role to the plugin's Sync Tab Access list (`instawp_sync_tab_roles`); notably, the settings tab suppression logic only hides the tab when `administrator` is absent from the list entirely, meaning a mixed configuration retaining administrator alongside a lower role still serves the full settings page — including the API key — to the lower-privileged user.Show less

The My Calendar – Accessible Event Manager plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 3.8.7. The public `mcs` GET parameter is reflected into post content unsanitized before WordPress core's `do_shortcode` filter runs, allowing an unauthenticated attacker to inject a nested `[my_calendar above=...]` shortcode; `mc_generate_calendar_nav()` then splits the `above` attribute on commas and dispatches each element via `call_user_func()` with no authentication, authorization, or callable allowlist check. This makes it possible for unauthenticated attackers to invoke arbitrary loaded PHP functions, enabling a call chain in which the shortcode `$params` array is passed to `edit_user()` — which PHP coerces to integer `1` as the `$user_id` argument — overwriting the credentials of the initial Administrator account (user ID 1) and granting the attacker full wp-admin access. Exploitation is trivially reachable via the plugin's auto-generated `/my-calendar/` page, which is publicly accessible by default upon plugin activation.Show less

The Customer Email Verification for WooCommerce plugin for WordPress is vulnerable to Privilege Escalation via the `alg_wc_ev_verify_email` parameter in versions up to, and including, 3.3.0. The vulnerability exists because `alg_wc_ev_generate_user_code()` generates the per-user activation secret using `wp_rand(100)` when the plugin's 'Encoding method' is set to 'hashids', producing only ~101 possible values (~7 bits of entropy); the resulting token is a reversible Hashids encoding with no cryptographic MAC, and the unauthenticated `verify()` handler — hooked to `init` at `PHP_INT_MAX` with no nonce check and no rate limiting — accepts and acts on the attacker-controlled `?alg_wc_ev_verify_email=` GET parameter directly. This makes it possible for unauthenticated attackers to gain authentication as any unverified WordPress account, including administrator-level accounts, by brute-forcing the trivially small activation code space via a forged verification URL. Exploitation requires that the 'Encoding method' setting be changed to 'hashids' (non-default), that the attacker recover or brute-force the Hashids salt (which defaults to an `md5(time())` value set at first initialization), and that the target account's email address remain unverified.Show less

In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration.Show less