CVE-2026-105218 in gopay
Summary
by MITRE • 10/04/2026
gopay before 1.5.119 disables TLS certificate verification in defaultClient() in pkg/xhttp/client.go, allowing man-in-the-middle attackers to impersonate payment provider APIs. Attackers can present any certificate to read merchant credentials, signatures and transaction data, and modify payment, refund and order query responses.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in gopay versions prior to 1.5.119 represents a critical failure in transport layer security configuration within the library's default HTTP client implementation. Specifically, the flaw resides in the pkg/xhttp/client.go module where the TLS certificate verification mechanism is explicitly disabled during initialization of the defaultClient function. This misconfiguration effectively strips away the fundamental trust model that underpins HTTPS communications, allowing any party capable of intercepting network traffic to establish a fraudulent connection with the application without detection by standard cryptographic validation processes.
From a technical perspective, this defect constitutes an improper certificate validation error where the client accepts any X.509 certificate presented by the remote server regardless of its validity, expiration status, or chain of trust. By bypassing these checks, the software fails to authenticate the identity of the payment provider APIs it communicates with. This creates a direct pathway for man-in-the-middle attacks wherein an adversary can position themselves between the merchant application and the legitimate payment gateway infrastructure. The attacker can then intercept, decrypt, read, modify, or inject data into the communication stream without triggering any security alerts within the client-side logic.
The operational impact of this vulnerability is severe given its context within a financial transaction processing system. Attackers leveraging this flaw can impersonate payment provider APIs to steal sensitive merchant credentials and cryptographic signatures that are transmitted during authentication phases. Furthermore, they possess the ability to alter critical transaction data including payment confirmations, refund statuses, and order query responses. This capability allows for sophisticated fraud schemes such as confirming fraudulent transactions while suppressing legitimate ones, altering refund amounts, or manipulating inventory levels based on falsified order status updates. The integrity of financial records is compromised, leading to potential direct monetary loss and significant reputational damage for the merchant relying on this library.
This vulnerability aligns with CWE-295 Improper Certificate Validation as it involves failing to properly validate a certificate during authentication or key exchange processes. In terms of offensive security frameworks, it facilitates MITM attacks categorized under ATT&CK technique T1078 Valid Accounts and potentially T1046 Network Service Discovery if used for broader reconnaissance, though the primary vector is interception via T1557 Adversary-in-the-Middle. The ability to modify responses also touches upon data integrity violations central to many financial fraud tactics.
To mitigate this risk, organizations must immediately upgrade gopay to version 1.5.119 or later where the defaultClient function has been corrected to enforce strict TLS certificate verification by default. If upgrading is not immediately feasible, developers should implement a custom HTTP client configuration that explicitly enables certificate validation and utilizes a trusted Certificate Authority pool rather than relying on the library's insecure defaults. Additionally, implementing mutual TLS authentication can provide an additional layer of security ensuring both parties verify each other's identities before exchanging sensitive financial data. Regular audits of third-party dependencies for similar misconfigurations are recommended to prevent recurrence in related modules.