CVE-2026-91017 in Robokassa Plugin
Summary
by MITRE • 09/17/2026
The Robokassa payment gateway for Woocommerce WordPress plugin before 1.8.9 does not verify the authenticity of incoming payment notifications when its non-default deferred-payment feature is enabled, allowing unauthenticated attackers to forge a notification and mark arbitrary WooCommerce orders as paid or on-hold without payment or a valid signature.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Robokassa payment gateway plugin for WordPress serves as an interface between online stores built on the WooCommerce platform and the Robokassa payment processing service, facilitating transaction handling within e-commerce environments. A critical security flaw exists in versions prior to 1.8.9 regarding the implementation of its deferred-payment feature. This specific functionality allows merchants to process orders where payment is not immediately captured but rather confirmed at a later stage through asynchronous notifications sent by the payment provider. The vulnerability stems from a fundamental failure in input validation and authentication mechanisms within this workflow, specifically concerning how incoming webhook or callback requests are processed by the plugin software.
The core technical flaw lies in the absence of signature verification for these incoming payment notification payloads. When the deferred-payment feature is enabled, the system relies on external signals to update order statuses such as marking them paid or placing them on hold. However, the application does not cryptographically verify that these notifications originate from the legitimate Robokassa server using a shared secret key or digital signature. This omission means that any actor with network access can craft and send HTTP requests mimicking valid payment confirmations without possessing the necessary credentials to generate authentic signatures. The software blindly trusts the content of these messages, treating them as authoritative sources for state changes within the database.
This lack of authentication enables unauthenticated attackers to perform arbitrary code execution in terms of business logic manipulation. By forging notification payloads, an attacker can remotely alter the status of any WooCommerce order associated with a user account on the target site. Specifically, they can force orders into paid or on-hold states without actual funds being transferred from the customer. This capability effectively allows for free acquisition of goods and services, leading to direct financial loss for merchants who ship products based on fraudulent payment confirmations. The attack vector is remote and does not require prior authentication credentials against the WordPress admin dashboard, significantly lowering the barrier for exploitation by malicious actors scanning for vulnerable installations.
From a classification perspective, this vulnerability aligns with CWE-347, which describes Improper Verification of Cryptographic Signature, as well as CWE-287 regarding Improper Authentication. In terms of offensive security frameworks, it maps to MITRE ATT&CK techniques involving T1505.003 for Server Message Block (SMB) or web service abuse and potentially T1496 if used in the context of resource hijacking for financial gain through fraud. The impact extends beyond immediate monetary loss; it can also damage merchant reputation, trigger chargebacks from legitimate customers whose orders were incorrectly marked as paid by attackers, and compromise the integrity of sales data analytics within the e-commerce platform.
Mitigation strategies must prioritize immediate software updates to version 1.8.9 or later where this validation logic has been corrected. Administrators should ensure that all plugins are kept up to date with security patches released by vendors. In environments where updating is not immediately feasible, temporary mitigations include disabling the deferred-payment feature if it is not strictly required for business operations. Additionally, implementing Web Application Firewall rules can help filter out malformed or suspicious webhook requests, although this is a less reliable defense than fixing the underlying code flaw. Merchants should also monitor their transaction logs closely for anomalies in order status changes that do not correspond with actual bank statements to detect potential exploitation attempts early.