CVE-2026-87979 in Paymob for WooCommerce Plugin
Summary
by MITRE • 09/23/2026
The Paymob for WooCommerce WordPress plugin before 4.1.14 does not verify the request signature on the card-token branch of its payment webhook, allowing unauthenticated attackers to write a card-token record to any user's account and to enumerate registered accounts.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in the Paymob for WooCommerce WordPress plugin prior to version 4.1.14 represents a critical failure in authentication verification mechanisms within the application’s payment processing infrastructure. Specifically, the flaw resides in the card-token branch of the webhook endpoint responsible for handling asynchronous payment notifications from the Paymo gateway. In secure financial integrations, webhooks must rigorously validate incoming requests to ensure they originate from trusted sources and have not been tampered with during transit. The absence of signature verification on this specific endpoint allows unauthenticated actors to interact directly with the backend logic without possessing valid credentials or API keys, effectively bypassing standard access controls designed to protect sensitive financial data operations.
From a technical perspective, the core issue is an improper authentication mechanism where the application fails to verify the cryptographic signature attached to incoming webhook payloads. This oversight permits attackers to craft arbitrary HTTP POST requests that mimic legitimate payment notifications from Paymob. By manipulating parameters within these forged requests, an attacker can force the plugin to create or update card-token records associated with any user account identified by a valid customer ID. Card tokens are sensitive data elements used for storing payment methods securely, and their unauthorized creation or modification compromises the integrity of the financial transaction pipeline. This flaw aligns closely with CWE-287, which describes Improper Authentication, as well as CWE-345 regarding Insufficient Verification of Data Authenticity, highlighting a fundamental breach in trust assumptions between the plugin and its external payment provider.
The operational impact of this vulnerability is severe, extending beyond simple data manipulation to include significant privacy violations and potential financial fraud. Because the endpoint does not restrict which user accounts can be targeted based on authentication context, attackers can enumerate valid registered customer IDs by observing successful token creation responses or error messages that differ between existing and non-existing users. This enumeration capability allows adversaries to map out the plugin’s user base efficiently. Once a target account is identified, the attacker can inject fraudulent card tokens into that user's profile. These maliciously injected tokens could potentially be used for unauthorized recurring billing if the merchant implements auto-renewal features without additional verification steps, or they may serve as a foothold for further exploitation within the e-commerce ecosystem by linking illicit payment methods to legitimate customer identities.
This vulnerability also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, specifically in the context of account manipulation and enumeration when authentication is bypassed through logic flaws rather than credential theft. The ability to write arbitrary data into user profiles constitutes a form of privilege escalation where an unauthenticated actor gains the ability to modify stateful resources belonging to authenticated users. This undermines the non-repudiation guarantees expected in financial transactions, as the system cannot reliably distinguish between legitimate customer actions and malicious injections performed via forged webhooks. The lack of input validation on the user identifier field further exacerbates the risk by allowing sequential or randomized guessing of account IDs until a valid one is found.
Mitigation strategies must prioritize immediate patching to version 4.1.14 or later, where this signature verification logic has been corrected. In environments where upgrading is not immediately feasible, administrators should implement network-level controls such as firewall rules that restrict access to the webhook endpoint exclusively to Paymob’s known IP address ranges. Additionally, implementing a secondary layer of validation at the application level, such as checking for valid session tokens or requiring re-authentication for sensitive profile modifications, can provide defense in depth. It is also critical to review logs for any signs of enumeration attempts characterized by high volumes of requests targeting different customer IDs with similar payload structures. Regular security audits focusing on webhook implementations and adherence to OWASP API Security Top 10 guidelines will help prevent similar authentication bypasses in future integrations, ensuring that financial data remains protected against untrusted external inputs.