CVE-2026-103382 in Casso Flow Plugin
Summary
by MITRE • 10/28/2026
The Casso Flow WordPress plugin before 4.2.0 does not properly authenticate incoming bank-transfer payment notifications, as the token used to verify them is empty on a default installation, allowing unauthenticated attackers to forge a notification and mark any pending WooCommerce order as paid, regardless of its payment method.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Casso Flow WordPress plugin versions prior to 4.2.0 represents a critical failure in authentication logic that directly impacts the integrity of e-commerce transactions processed through WooCommerce. The core technical flaw lies in how the plugin handles incoming bank-transfer payment notifications from external gateways. Specifically, the mechanism designed to verify the authenticity and integrity of these webhook payloads relies on a security token. In default installations of the affected software versions, this verification token is left empty or null by design rather than being dynamically generated or securely configured during setup. This configuration oversight means that any subsequent validation check performed against this token effectively bypasses authentication requirements because an empty string often evaluates as valid in poorly implemented conditional logic checks within the plugin's codebase.
From a technical perspective, this flaw allows unauthenticated actors to forge payment notifications without possessing any secret keys or credentials. An attacker can construct a malicious HTTP POST request mimicking a legitimate bank-transfer success notification and send it directly to the WordPress site hosting the vulnerable plugin. Because the server-side validation logic does not enforce strict non-empty token verification, the forged payload is accepted as genuine. Consequently, the system updates the status of any pending WooCommerce order associated with that transaction ID to paid, even if no actual funds were transferred or if the payment method was never intended for bank transfer processing. This constitutes a classic example of broken access control where authentication mechanisms are rendered ineffective due to improper configuration defaults and insufficient input validation.
The operational impact of this vulnerability is severe for online merchants relying on WooCommerce for revenue generation. By successfully exploiting this flaw, an attacker can artificially mark orders as paid without fulfilling the financial obligation. This leads directly to inventory depletion as goods may be shipped or services delivered based on false payment confirmations. Furthermore, it creates significant accounting discrepancies and potential legal liabilities if customers receive products they did not pay for while merchants bear the loss of both product value and shipping costs. The ability to manipulate order status remotely also opens avenues for further exploitation within the broader WordPress ecosystem, potentially allowing attackers to escalate privileges or disrupt business operations by flooding systems with fake completed transactions that require manual reconciliation.
This vulnerability aligns closely with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of users making requests, and CWE-345 Insufficient Verification of Data Authenticity, since it does not ensure data originates from a trusted source. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior maps to T1190 Exploit Public-Facing Application, where attackers leverage vulnerabilities in internet-facing software to gain initial access or manipulate system state. The lack of proper token validation also reflects weaknesses associated with CWE-347 Improper Verification of Cryptographic Signature if the empty token was intended for signature verification but failed due to implementation errors.
Mitigation strategies must focus on immediate remediation and long-term security hardening. Administrators should upgrade the Casso Flow plugin to version 4.2.0 or later, where this authentication logic has been corrected to enforce strict validation of non-empty tokens. Until an update is applied, temporary mitigations include restricting access to the specific webhook endpoints via IP whitelisting if possible, although this may not be feasible for all payment gateways that use dynamic IPs. Additionally, implementing a Web Application Firewall with rules capable of detecting anomalous POST requests lacking expected authentication headers can provide a layer of defense. It is also critical to ensure that future plugin configurations require explicit token generation during installation rather than relying on insecure defaults, and developers should adopt secure coding practices that mandate non-empty secret validation for all webhook integrations involving financial transactions.