Act nowDisclosed

Advisory · CVE-2026-105218

gopay's HTTP client skips TLS verification for payment APIs

gopay disables TLS certificate verification in its default HTTP client, letting man-in-the-middle attackers impersonate payment provider APIs to read merchant credentials and rewrite payment responses.

Advisory published October 4, 2026Independent summary
Vendor
go-pay
Product
gopay
Identifier / CWE
CVE-2026-105218
CWE-295
Action timing
Immediate
ELI5

Explain it like I’m five

gopay's built-in web client never checks the ID of the payment company's server before talking to it. An attacker on the network can pretend to be the payment company, read your shop's secret keys and customer payment data, and even rewrite the answers about whether a payment succeeded.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Verification disabled

    gopay before 1.5.119 disables TLS certificate verification in defaultClient() in pkg/xhttp/client.go.

  2. 02Attacker impersonates provider

    A man-in-the-middle attacker presents any certificate while impersonating a payment provider API.

  3. 03Credentials read

    The attacker reads merchant credentials, signatures, and transaction data in transit.

  4. 04Responses rewritten

    The attacker can modify payment, refund, and order query responses returned to the merchant.

What happened

gopay before 1.5.119 disables TLS certificate verification in defaultClient() in pkg/xhttp/client.go. Man-in-the-middle attackers can impersonate payment provider APIs: by presenting any certificate they can read merchant credentials, signatures, and transaction data, and modify payment, refund, and order query responses. It is rated critical at CVSS 9.1 under CVSS v4.0 (7.4 under v3.1) and tracked as CWE-295.

What to do

  1. Upgrade gopay to 1.5.119 or later.
  2. Rotate merchant API credentials, signing keys, and any secrets used with affected gopay versions.
  3. Reconcile payment, refund, and order records against provider-side statements for the exposure window, watching for response tampering.
  4. Confirm TLS verification is enforced after the upgrade.

Management note

A payment SDK that does not verify who it is talking to undermines the entire payment flow: credentials leak and, worse, the answers to “did this payment succeed” become attacker-controlled. This calls for more than a dependency bump; reconcile the money. Any refund or order status returned through an affected client should be re-verified against the provider’s own records.