Description

The Handily plugin for WordPress is vulnerable to unauthorized payment settings modification due to missing authorization checks in all versions up to, and including, 1.0.3. This makes it possible for unauthenticated attackers to modify Stripe payment configuration settings, including publishable keys, secret keys, email addresses, success URLs, and cancel URLs via the payment settings parameters. This could allow attackers to redirect payments to their own Stripe accounts.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-22T08:16:35.987Z",
  "pubdate": "2026-09-22T08:16:35.987Z",
  "executiveSummary": "The Handily plugin for WordPress, in all versions up to and including 1.0.3, is susceptible to an unauthorized settings modification vulnerability.\nThis security flaw stems from a failure to implement proper authorization checks within the plugin's administrative settings handlers.\nThe vulnerability allows unauthenticated remote attackers to modify critical Stripe payment configuration parameters, including API keys (publishable and secret), notification email addresses, and redirect URLs (success/cancel).\nBy manipulating these configurations, an attacker can intercept financial transactions by redirecting payment flows to attacker-controlled Stripe accounts, effectively performing a financial theft or business logic compromise.\nThe risk is critical, as it requires no prior authentication or administrative privileges to execute. The exploit is performed via network-accessible requests that bypass access control lists, making it an attractive target for automated exploitation tools.\nSuccessful exploitation compromises the integrity and confidentiality of the payment processing workflow, posing a severe risk to the site operator's financial security and user trust.",
  "technicalDetails": "The vulnerability is rooted in an Improper Authorization flaw located within the administrative settings processing logic of the Handily plugin. The component responsible for updating payment gateway settings fails to validate the current user's session or role permissions before executing database update operations on the plugin's configuration options.\nThe affected plugin versions (up to and including 1.0.3) lack the necessary 'current_user_can()' checks or nonce validation that are standard for WordPress administrative actions. Consequently, any unauthenticated HTTP request sent to the specific endpoint responsible for updating the plugin's payment settings will be processed as legitimate by the application logic.\nThe attack flow proceeds as follows: 1) The attacker identifies the plugin's settings update endpoint or the administrative interface action responsible for persisting Stripe configurations. 2) The attacker crafts an HTTP POST request containing malicious parameters for the payment configuration. These parameters include the 'stripe_publishable_key', 'stripe_secret_key', 'success_url', 'cancel_url', and associated 'email_address' fields. 3) The application server receives this request and, due to the missing access control checks, proceeds to execute the function responsible for sanitizing and storing these settings in the wp_options table. 4) The application updates the persistent configuration with the attacker's supplied values, overwriting the legitimate merchant's credentials.\nPost-exploitation impact is severe. By replacing the legitimate Stripe Secret Key and Publishable Key, the attacker forces all subsequent transactions initiated through the Handily plugin to be routed to the attacker’s Stripe account. Because the attacker can also modify the 'success_url' and 'cancel_url', they can effectively facilitate phishing or further credential harvesting by redirecting users to external malicious domains after a transaction is processed. Furthermore, changing the contact email address allows the attacker to intercept order notifications and transaction receipts, effectively masking the malicious activity from the site administrator. This attack requires no interaction from a privileged user, as the vulnerability exists at the network level and is reachable by any unauthenticated entity capable of reaching the web server."
}