CVE Database

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 Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the copy_file function in all versions up to, and including, 4.9.3 This makes it possible for authenticated attackers, with Sales Representative-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). This is exploitable by any user holding the plugin-defined import_contacts capability, which is granted by default to the plugin's custom Sales Representative role.

The FunnelKit – Funnel Builder for WooCommerce Checkout plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.16.0.6 This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to retrieve billing PII — including full name, street address, email address, and phone number — for any WooCommerce order on the site by submitting an enumerable sequential order ID. This is only exploitable on sites where a FunnelKit thank-you page exists that renders the [wfty_order_meta] or [wfty_order_total] shortcode.

The Modula Image Gallery – Photo Grid & Video Gallery plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 3.0.11 via the 'id (post ID in /wp-json/wp/v2/modula-gallery/{id}) or none for collection route' parameter. This makes it possible for unauthenticated attackers to extract the plaintext Password Protect password and username for every published gallery from the modulaSettings REST field. The plugin's own /wp-json/modula/v2/gallery/{id}/settings endpoint correctly redacts the password for unauthenticated callers via redact_settings_for_public(), but no equivalent redaction is applied on the core /wp-json/wp/v2/modula-gallery path exposed by show_in_rest=true CPT registration.

The miniOrange OTP Login, Verification and SMS Notifications plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 5.5.8 via the `mo_by_pass_login()` function. This is due to `mo_delay_otp_process()` short-circuiting the authentication flow before password validation or the administrator intent gate (added in 5.5.6) can run, combined with the Delay OTP grace flag (`mov_last_verified_dttm`) being stored as a `user_meta` row keyed solely by target user ID with no binding to the originating session, cookie, IP address, or device. This makes it possible for unauthenticated attackers to authenticate as any WordPress user — including administrators — by submitting only a known username with the `mo_wp_login_intent=otp` parameter and any non-empty password, thereby inheriting a legitimate user's open Delay OTP grace window without ever supplying correct credentials. Exploitation requires the site to have OTP-only login (`wp_login_skip_password=1`, `wp_login_skip_password_fallback=0`) and Delay OTP Verification (`wp_login_delay_otp=1`) enabled, and the target account must currently be within its configured Delay OTP interval.

The FluentCart A New Era of eCommerce – Faster, Lighter, and Simpler plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.7.0 via the 'order_id + billing_address_id (also shipping_address_id)' parameter due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to read and exfiltrate another customer's stored billing and shipping address PII — including street address, city, state, postcode, phone number, company name, VAT number, and legal registration ID — by enumerating sequential AUTO_INCREMENT order and address ID pairs. The id-equality guard intended to restrict address reuse is bypassed because the attacker controls both halves of the compared pair, and the unauthenticated AJAX entry point imposes only a soft rate limit of 5 requests per 60 seconds rather than any authentication or ownership check.

The Complianz GDPR/CCPA Cookie Consent Banner plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Comment Content via yotu-wp Cookie-Blocker Filter in all versions up to, and including, 7.5.5 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The exploit bypasses WordPress's wp_kses comment sanitization because the payload uses only allow-listed tags and hides executable tokens inside quoted attribute values as plain text; the XSS is only realized when Complianz's own output-buffer filter performs str_replace() rewrites that break out of the attribute context, and requires the comment to be approved before it executes for visitors.

The Backuply – Backup, Restore, Migrate and Clone plugin for WordPress is vulnerable to SQL Injection via the Biographical Info field (second-order, via restore) in all versions up to, and including, 1.5.8 due to insufficient escaping on the user supplied parameter and the lack of sufficient preparation on an existing SQL query. Backuply exports the Biographical Info value verbatim inside an INSERT statement written to the backup's SQL dump (wp_usermeta). When an Administrator later restores such a backup, the crafted payload breaks out of that INSERT statement and appends attacker-controlled SQL that executes with full database privileges. This makes it possible for authenticated attackers, with subscriber-level access and above, to write arbitrary data to the database — in particular to update the default_role option in wp_options to administrator (and enable open user registration) — so that a subsequently registered account is automatically granted the Administrator role, resulting in privilege escalation and full site takeover. Because the injection executes inside an INSERT during restore with no response returned to the attacker, the primitive is used to modify database records rather than to read existing data directly.

Wheels CLI 4.0.0 through 4.1.1 insufficiently validates or escapes caller-supplied values and package contents. Deploy release/version/rollback values can execute shell commands on deploy hosts as the SSH user and on the CI runner during builds. Package removal and destroy paths can delete unintended files; package extraction can overwrite other vendor files; generator names can write outside the project or inject executable CFML into generated code. Inputs may originate from CI variables, branch names, packages or an AI agent using the CLI's MCP tools. Also relevant are unencoded display properties in generated scaffold show views since 4.1.0 and in generated admin views, permitting stored XSS, and stale process-ID handling in RustCFML server commands that can terminate an unrelated process. This is fixed in 4.1.2; existing affected generated views also require the documented edit.

Wheels 4.0.0 through 4.1.2 before 4.2.0 replaces incoming scope conditions with a primary-key condition in findByKey() and exists(key=). For exists(key=), production with error information disabled returns true for an out-of-scope key instead of throwing. Applications relying on scopes for ownership or tenant authorization can therefore load and subsequently modify or delete another user's or tenant's record when the key comes from a request. The 4.2.0 fix combines key conditions with incoming scope, query-builder or where conditions in findByKey(), exists(key=), updateByKey() and deleteByKey(). Other scope-aware finders, aggregates, updateAll() and deleteAll() are not affected.

Wheels 1.1 through 4.1.2 resolves nestedProperties() records by posted primary key without checking that they belong to the parent being saved. A user able to submit a nested form for their own parent can update and reassign another parent's hasMany or hasOne rows, or delete them when allowDelete=true. Nested belongsTo records can also be edited by posting another associated record's key. New child rows with composite primary keys not made up of foreign keys retain posted key values, allowing the request to choose their identity. This is fixed in 4.2.0.

Wheels 4.0.0 through 4.1.2 exposes password-less development tools under /wheels/* to remote clients when enablePublicComponent=true, as it is by default in development. Before 4.1.2 these tools have no local-access restriction; in 4.1.2 the restriction trusts client-supplied headers without checking the connecting peer. Remote clients can obtain application settings, environment/datasource details and routes, and start test runs. Where application tests use the primary datasource, those runs can write to the real application database. The separately protected migrator and CLI endpoints are not affected. This is fixed in 4.2.0.