CVE-2026-89411 in Paymattic Plugin
Summary
by MITRE • 09/28/2026
The Paymattic WordPress plugin from 4.6.20 before 4.6.26 does not verify that a confirmed Stripe payment belongs to the order it is applied to, allowing unauthenticated users to mark an arbitrary pending order as paid by confirming a smaller payment of their own against it.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Paymattic WordPress plugin versions prior to 4.6.26 represents a critical failure in transaction integrity and authentication verification within the e-commerce workflow. This flaw, classified under CWE-352 as Cross-Site Request Forgery or more accurately here as CWE-862 Missing Authorization for Critical Business Logic, allows an unauthenticated attacker to manipulate order statuses without possessing valid credentials or legitimate payment instruments associated with the target orders. The core technical issue lies in the plugin's handling of Stripe webhook events and subsequent state transitions. When a payment is confirmed via Stripe, the application logic fails to rigorously validate that the specific transaction identifier corresponds exclusively to the pending order being updated. Instead, it appears to rely on insufficient checks or potentially predictable identifiers that allow an attacker to decouple the payment confirmation from its intended context.
From an operational perspective, this vulnerability enables a severe business impact scenario where malicious actors can arbitrarily mark any pending order as paid without actually fulfilling the financial obligation for those specific goods or services. By initiating their own small payments through Stripe and manipulating the request parameters sent back to the WordPress application, attackers can trick the system into believing that these minor transactions are confirmations for high-value orders belonging to other customers. This effectively bypasses the payment gateway's authentication mechanisms because the attacker is using a valid but unrelated transaction ID or exploiting a logic flaw where the order ID and payment ID association is not strictly enforced server-side before updating the database state.
The exploitation of this vulnerability allows an unauthenticated user to compromise the integrity of the entire sales pipeline. Once an arbitrary pending order is marked as paid, the system typically proceeds with fulfillment processes such as inventory deduction, shipping label generation, or digital asset delivery. This results in direct financial loss for the merchant who ships goods or provides services without receiving payment, while also causing significant reputational damage and customer service complications when legitimate customers discover their orders have been incorrectly processed or cancelled due to conflicting status updates. Furthermore, this flaw can be leveraged as a stepping stone for further attacks, such as inventory depletion or triggering automated workflows that depend on accurate order statuses.
Mitigation strategies must focus on implementing strict server-side validation of the relationship between payment identifiers and order records. Developers should ensure that every webhook event from Stripe is verified against the specific order ID it claims to affect, using cryptographic signatures provided by Stripe to prevent tampering with request payloads. Additionally, enforcing unique transaction-to-order mappings in the database schema can help prevent multiple orders from being linked to a single payment confirmation inadvertently. Upgrading to Paymattic version 4.6.26 or later is essential as it addresses this logic flaw by reinforcing these authorization checks. Until an upgrade is performed, administrators should monitor webhook logs for anomalies and consider implementing additional manual verification steps for high-value transactions to detect any unauthorized status changes promptly. This incident underscores the importance of treating payment gateway integrations with rigorous security controls that assume all external inputs are potentially malicious until proven otherwise through comprehensive validation protocols aligned with OWASP guidelines for business logic vulnerabilities.