CVE-2026-91019 in Event Booking Manager Plugin
Summary
by MITRE • 09/17/2026
The Event Booking Manager for WooCommerce WordPress plugin before 5.6.0 does not restrict who can view its stored payment gateway configuration, allowing users with Contributor-level access and above to read the site's PayPal and Stripe credentials, including their secret keys.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of the Event Booking Manager for WooCommerce WordPress plugin prior to version 5.6.0 represents a critical failure in access control mechanisms regarding sensitive configuration data. Specifically, the plugin fails to enforce proper authorization checks when rendering administrative interface elements that display payment gateway settings. This architectural flaw allows any user account with Contributor-level permissions or higher on the WordPress installation to view and potentially extract stored credentials for integrated payment processors such as PayPal and Stripe. In standard WordPress role hierarchies, a Contributor is typically intended to have limited capabilities focused primarily on content creation without administrative privileges, yet this vulnerability inadvertently grants them access to high-privilege configuration data that should be restricted strictly to Administrators or users with explicit management roles.
From a technical perspective, the root cause lies in the insufficient validation of user capabilities before outputting sensitive environment variables into the admin dashboard interface. The plugin retrieves and displays payment gateway API keys, including secret keys which are designed for server-to-server authentication and must remain confidential, without verifying that the requesting user possesses the necessary administrative rights to view such information. This oversight violates fundamental principles of secure software design where data access is strictly governed by role-based access control policies. By exposing these credentials through a web interface accessible to lower-privileged users, the application creates an avenue for credential theft that bypasses traditional security boundaries established within the WordPress ecosystem.
The operational impact of this vulnerability is severe due to the nature of the exposed data. Secret keys for payment gateways like Stripe and PayPal are equivalent in sensitivity to passwords because they authorize financial transactions and access to merchant accounts. If a malicious actor with Contributor-level access obtains these credentials, they can potentially initiate unauthorized refunds, manipulate transaction records, or use the API endpoints associated with those keys to perform fraudulent activities against the business owner's payment account. Furthermore, possession of Stripe secret keys could allow an attacker to create new products, modify pricing structures, or extract customer billing information if additional vulnerabilities exist in how that data is handled by the gateway APIs. This compromises not only the confidentiality but also the integrity and availability of the e-commerce operations supported by the plugin.
This issue aligns with CWE-284 Improper Access Control, as it involves a failure to restrict access to resources based on user roles or privileges. Additionally, from an offensive security perspective such as the MITRE ATT&CK framework, this vulnerability facilitates Credential Access techniques where attackers leverage existing low-level accounts to harvest sensitive information for further exploitation. The exposure of API keys also relates closely to CWE-798 Use of Hard-coded Credentials if those credentials were improperly stored or managed within the plugin codebase rather than securely in WordPress options tables with proper encryption and access restrictions, although the primary flaw here is the lack of runtime authorization checks during data retrieval for display purposes.
Mitigation strategies must prioritize immediate patching to version 5.6.0 or later where these access control mechanisms have been corrected. In environments where upgrading is not immediately feasible, administrators should manually audit user roles and demote any users who do not require administrative privileges from Contributor level or higher if they are accessing sensitive areas of the site unnecessarily. It is also advisable to rotate all exposed payment gateway credentials immediately after patching, as there may be no way to determine exactly which accounts accessed the data during the window of vulnerability. Implementing strict role-based access control plugins and regularly auditing user permissions can further reduce the risk surface by ensuring that only authorized personnel have visibility into configuration settings containing sensitive secrets.