gopay CVE-2026-105218

The exploitable condition is default behavior, not a special configuration: any application using gopay before 1.5.119 that relies on the built-in client (NewClient()/defaultClient() in pkg/xhttp/client.go), which ships with tls.Config{InsecureSkipVerify:true}, accepts any certificate on connections to payment provider APIs. The decisive LIMITING factor is that the attacker must occupy an on-path/man-in-the-middle position between the application and the provider (e.g., shared/rogue network, ARP or DNS spoofing, compromised proxy or upstream hop) to intercept and forge the TLS session - this is why CVSS encodes AC:H and AT:P and why the flaw is not directly internet-exploitable. Per the vendor README, legitimate payment domains use trusted certificates, so the risk is confined to environments where interception is achievable; applications that explicitly injected their own secure client are unaffected.

Signals conflict in an instructive way: the headline CVSS 4.0 base score is 9.1 (Critical) driven by high confidentiality and integrity impact (VC:H/VI:H), yet the same vector encodes AC:H and AT:P, meaning successful exploitation is NOT trivially remote - it requires the attacker to already hold a man-in-the-middle/on-path position between the gopay-using application and the payment provider's API. That dependency meaningfully lowers real-world likelihood versus a typical AV:N/AC:L flaw. No EPSS score, CISA KEV entry, or public exploit was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the risk is therefore potential rather than demonstrated. However, the flaw is default behavior (InsecureSkipVerify:true in defaultClient()), confirmed by the vendor commit and README, so every unpatched deployment is exposed the moment an attacker achieves network interception. Net: this is a genuine priority for any production system processing payments over gopay - the impact (credential theft plus silent tampering of payment/refund/order responses) is severe - but it is gated by the MITM precondition rather than being a mass-scannable internet-facing bug. Missing data note: EPSS/KEV/POC status absent from input and should be re-checked before final prioritization.

An attacker who controls a network segment on the path between a merchant's gopay-based backend and a payment provider (e.g., rogue Wi-Fi, ARP/DNS spoofing, compromised upstream router, or a malicious proxy) terminates the outbound TLS connection with a self-signed or forged certificate. Because gopay's default client skips certificate verification, the forged certificate is accepted silently, letting the attacker read merchant credentials and signatures and rewrite payment, refund, and order-query responses. No public exploit is identified at time of analysis, but exploitation requires only off-the-shelf MITM tooling once network position is obtained.