CVE Database

The Salon Booking System WordPress plugin before 10.31.11 does not prevent users holding its custom salon staff role from assigning arbitrary capabilities to other accounts when editing a customer, allowing them to escalate any account to administrator and take over the site.

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.

IBM i 7.3, 7.4, 7.5, and 7.6 is vulnerable to an authenticated attacker elevating their privilege. A bad actor could exploit this vulnerability to perform operations with QSECOFR/Root authority on the system.

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.

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.

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.

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.

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.

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.

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.

util-linux is a random collection of Linux utilities. In util-linux 2.39.1 through 2.41.4 and 2.42 through 2.42.1, the SUID `mount` utility reads the attacker-controlled `LIBMOUNT_FORCE_MOUNT2` environment variable with `getenv()`, allowing a local low-privileged user to force the non-atomic legacy bind-mount path. With an `/etc/fstab` bind mount authorized by `user` or `users` and protected by `nosuid`, `noexec`, or `nodev`, an attacker can race the window between the initial bind mount and the remount that applies those security flags and execute a SUID program from the temporarily unprotected mount, potentially gaining root privileges. This issue is fixed in 2.41.5 and 2.42.2.

Gitea Runner passes workflow-controlled container options into Docker job container configuration while privileged mode is disabled. Host namespace settings, expanded capabilities, and security profile overrides can remain effective despite Privileged being forced false. A workflow author able to run jobs on an affected Docker-backed runner can use these options to access host namespaces and execute commands as root on the runner host, bypassing the intended container isolation.