Description

The zipMoney(Zip Co) Payments Plugin for WooCommerce WordPress plugin before 2.4.0 does not perform any authorisation checks on one of its front-end request handlers, and does not restrict which option name a caller may supply, allowing unauthenticated users to delete arbitrary WordPress options. This can be used to destroy site and access control configuration, deactivate every installed zipMoney(Zip Co) Payments Plugin for WooCommerce WordPress plugin before 2.4.0, and take the site offline.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-09-10T07:17:03.143Z",
  "pubdate": "2026-09-10T07:17:03.143Z",
  "executiveSummary": "The zipMoney (Zip Co) Payments Plugin for WooCommerce is affected by an unauthenticated arbitrary option deletion vulnerability. This security flaw stems from a lack of proper authorization checks and input validation within a front-end request handler. By exploiting this vulnerability, an unauthenticated remote attacker can supply arbitrary WordPress option names to be removed from the database.\nThe impact of this vulnerability is critical, as it allows for the destruction of site-critical configurations, the disabling of security features, and the total disruption of site availability. An attacker can essentially reset site settings, potentially leading to unauthorized access, privilege escalation, or a complete denial-of-service (DoS) by corrupting the WordPress options table. No authentication or elevated privileges are required to initiate the attack, making it trivial for any remote actor to exploit if the vulnerable plugin version is installed. Users are strongly advised to update to version 2.4.0 or higher immediately to address this security oversight.",
  "technicalDetails": "The vulnerability resides in the request handling logic of the zipMoney (Zip Co) Payments Plugin for WooCommerce prior to version 2.4.0. The plugin exposes a front-end request handler that fails to perform necessary security validation, specifically concerning authorization and request context verification.\nThe root cause is an insecure implementation of an administrative or configuration-related action that is incorrectly accessible via the front-end without session validation or capability checks. The handler does not sanitize or restrict the input parameters supplied by the user, specifically the identifier for the WordPress option intended for deletion. Because the WordPress 'options' table stores sensitive configuration data—including site URLs, user registration settings, plugin status, and security keys—the ability to invoke an 'update_option' or 'delete_option' equivalent function without restriction creates a high-impact attack vector.\nThe attack flow follows a straightforward pattern: 1) An attacker identifies the exposed endpoint within the plugin's front-end request handling mechanism. 2) The attacker crafts an HTTP request (typically a POST or GET request depending on the handler implementation) targeting this endpoint. 3) The attacker injects the name of a sensitive WordPress option into the request payload. 4) The server-side code executes the deletion operation using the attacker-supplied parameter, bypassing the intended authorization flow that should normally restrict such actions to administrators.\nBy targeting specific option keys, an attacker can manipulate the environment significantly. For instance, removing 'siteurl' or 'home' can effectively take the site offline. Removing options associated with other plugins can deactivate security modules or payment gateways. Furthermore, by deleting options related to administrative accounts or site configuration, an attacker can destabilize the site's control panel or facilitate further exploitation. The vulnerability exists because the handler acts as a proxy for database operations without verifying the 'current_user_can' capability, which is the standard WordPress security requirement for performing administrative tasks. The lack of an nonce (number used once) check further enables Cross-Site Request Forgery (CSRF) style attacks, though the primary concern remains the direct, unauthenticated access to the database manipulation routine. The scope of the vulnerability includes all versions of the plugin prior to 2.4.0."
}