CVE-2026-103517 in Airwallex Online Payments Gateway Plugin
Summary
by MITRE • 10/08/2026
The Airwallex Online Payments Gateway WordPress plugin before 1.36.0 does not verify that an incoming payment notification genuinely comes from the payment provider when no webhook secret has been configured, allowing unauthenticated attackers to forge one and mark orders as paid without paying.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in Airwallex Online Payments Gateway WordPress plugin versions prior to 1.36.0 represents a critical failure in authentication logic for incoming payment notifications. This flaw specifically affects the webhook handling mechanism, which is designed to receive asynchronous updates from external payment processors regarding transaction status changes. In secure implementations of such systems, it is standard practice to verify that an incoming request originates from the legitimate service provider by validating cryptographic signatures or shared secrets configured during integration setup. However, in this specific plugin version, the code path responsible for processing these notifications fails to enforce verification when no webhook secret has been explicitly defined by the site administrator. This oversight creates a significant security gap where the system assumes that any incoming notification is valid if it lacks a required authentication token, effectively bypassing integrity checks entirely.
From an operational perspective, this technical flaw allows unauthenticated attackers to forge payment notifications and submit them directly to the WordPress application endpoint designated for webhook processing. By crafting malicious HTTP requests that mimic legitimate status updates from Airwallex, an attacker can trick the e-commerce system into believing a transaction has been successfully completed. Consequently, the plugin marks associated orders as paid without any actual funds being transferred or verified by the payment gateway. This leads to direct financial loss through order fulfillment for goods or services provided against non-existent payments, as well as potential inventory depletion and reputational damage due to fraudulent activity appearing legitimate within the system logs.
This vulnerability aligns with CWE-345, which describes Insufficient Verification of Data Authenticity, a common issue in systems that rely on external callbacks without robust integrity checks. Furthermore, it relates to CWE-287 regarding Improper Authentication, as the application fails to verify the identity of the sender for critical state-changing events. In terms of adversary tactics, this exploitation method corresponds to ATT&CK technique T1530, Data from Cloud Object Storage or Services, specifically involving data exfiltration or manipulation via trusted integrations, although in this case it is more accurately mapped to T1496 Resource Hijacking if used for denial of service through resource exhaustion, but primarily fits within the broader category of exploiting trust relationships between services. The lack of mandatory secret configuration means that even users who do not intend to use advanced security features are left vulnerable because the default behavior does not enforce a baseline level of authentication integrity.
To mitigate this risk, administrators must upgrade immediately to version 1.36.0 or later where the validation logic has been corrected to require proper verification regardless of configuration states. For those unable to update instantly, implementing a reverse proxy rule that filters webhook endpoints based on known IP ranges from Airwallex can provide an additional layer of defense by restricting access at the network level. Additionally, enforcing strict input validation and ensuring that all external callbacks are signed with HMAC-SHA256 using a securely generated secret key is essential for long-term security posture. Organizations should also audit their webhook configurations to ensure that no endpoints rely on implicit trust assumptions, thereby preventing similar vulnerabilities in other integrated services where authentication might be inadvertently disabled or misconfigured.