CVE-2026-84906 in Eventin Plugin
Summary
by MITRE • 09/16/2026
The Eventin WordPress plugin before 4.1.24 does not verify that a completed payment corresponds to the order it is applied to, confirming only that the payment gateway reports the transaction as successful, not its amount, currency, or which order it belongs to, allowing unauthenticated visitors to mark unpaid orders of any value as paid by replaying the transaction of a single genuine low-value payment.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Eventin WordPress plugin versions prior to 4.1.24 represents a critical flaw in the financial reconciliation logic within the e-commerce workflow. This issue stems from an insufficient verification mechanism during the post-payment processing phase, where the application fails to validate that the incoming payment data strictly corresponds to the specific order being processed. Instead of performing a comprehensive check against multiple attributes such as transaction amount, currency code, and unique order identifiers, the system relies solely on the binary status returned by the external payment gateway indicating whether the transaction was successful or not. This architectural oversight creates a significant gap in integrity checks, allowing attackers to bypass legitimate financial controls through simple replay attacks.
From a technical perspective, this flaw is classified under CWE-345: Insufficient Verification of Data Authenticity and specifically aligns with CWE-829: Inclusion of Functionality from Untrusted Control Sphere when considering the reliance on external gateway responses without local validation. The absence of cryptographic binding between the order ID and the payment transaction details means that any successful payment response can be decoupled from its original context. An attacker does not need to compromise user credentials or exploit server-side code execution vulnerabilities; rather, they only require network access to intercept and replay a valid HTTP POST request containing a successful payment notification for a low-value item. By submitting this captured payload against the endpoint responsible for marking orders as paid, the system erroneously updates the status of unrelated, potentially high-value orders that have not yet been paid.
The operational impact of this vulnerability is severe from both financial and reputational standpoints. Unauthenticated visitors can manipulate order statuses without any form of authentication or authorization, effectively stealing goods or services by marking unpaid invoices as completed. This bypasses all intended revenue protection mechanisms built into the plugin’s checkout flow. Furthermore, because the attack does not leave obvious traces in application logs beyond a standard successful payment notification, it may go undetected for extended periods until financial discrepancies are noticed during reconciliation. The ability to alter order states arbitrarily also compromises data integrity and can lead to incorrect inventory management if stock levels are tied directly to order completion status rather than actual fulfillment events.
In the context of cyber attack frameworks, this vulnerability facilitates actions consistent with ATT&CK technique T1534: Internal Spearphishing or more accurately in this automated web context, it aligns with logic manipulation tactics often seen in business logic abuse where an attacker exploits trust relationships between system components. The lack of idempotency checks and strict parameter validation allows for the exploitation described above. To mitigate this risk, developers must implement robust server-side verification that validates all critical payment parameters against the corresponding order record before updating its status. This includes verifying that the transaction amount matches the expected total, confirming the currency is correct, and ensuring a one-to-one mapping between the unique order identifier and the specific gateway transaction ID. Additionally, implementing nonce-based request validation or timestamped tokens can prevent replay attacks by ensuring each payment notification is processed only once and within an acceptable time window relative to its initiation.