Attackers Exploit Unpatched BTCPay Server Flaw to Drain Hot Wallets, $1.63M Traced
BTCPay Server, an open-source cryptocurrency payment platform, confirmed that attackers exploited a vulnerability fixed in version 2.4.2 (released August 7, 2026) to steal funds from hot wallets on instances still running 2.4.1 or earlier. Blockchain intelligence firm Bitquery traced 18.38 Bitcoin and 3405 Litecoin (~$1.63M) across 682 sweeps between October 30 and November 2 to two attacker-controlled addresses, with 87% of funds moved in a single wave on November 1. The attacker signed in as an administrator and swept the hot wallets; sweeps worth about $150,000 continued even after BTCPay Server issued a shutdown warning at 22:25 UTC. The same flaw was previously exploited in August to steal funds via the Lightning Network implementation LND, though on-chain hot wallets were reportedly unaffected at that time.
Entenda a falha
A vulnerabilidade
BTCPay Server, the open-source cryptocurrency payment platform, has a vulnerability that let attackers sign in as an administrator and sweep the funds in hot wallets. No CVE is listed and the articles do not name the component or the bug class. Instances running 2.4.1 or earlier are affected, and 2.4.2 (released August 7, 2026) fixes it. BTCPay Server said it saw no impact on servers running 2.4.2 or later. Wallets whose spending keys are held off the server, such as hardware wallets, were unaffected.
Como funciona
The articles do not describe the technical mechanism. What they report is the sequence of events: the attacker reached a vulnerable, unpatched BTCPay Server instance and signed in as an administrator. With that access they swept the hot wallet, whose keys sit on the server, to two attacker-controlled addresses. Bitquery counted 682 sweeps between October 30 and November 2. BTCPay Server said the attackers used a different method this time than in August, when the same flaw was used against LND.
Por que é vulnerável
The articles do not state the root cause or what the 2.4.2 fix changes. What they do show is that the flaw was exploited in two ways, first against LND (Lightning) in August and then against on-chain hot wallets. They also show that the exposure came from servers that never installed the August fix. Because the attacker obtained administrative access, BTCPay Server warns that updating alone cannot revoke access already gained.
Como foi descoberta
The thefts were detected through exploitation in the wild. BTCPay Server published an incident update on November 2 and told operators to shut down their instances at 22:25 UTC on November 1. Bitquery then traced 18.38 Bitcoin and 3405 Litecoin (about $1.63M) to two addresses named by the project. That figure is a floor, since it excludes other addresses, coins and Lightning funds. BTCPay Server says some activity at those addresses may predate the thefts and has published no official loss total. The same flaw had been exploited in August through LND, and 87% of the traced funds moved in one wave on November 1.
Explicação gerada por IA a partir da matéria e dos artigos, em 03/11/2026 12:18.
Detalhes técnicos
The vulnerability, patched in version 2.4.2, allowed attackers to gain administrative access to BTCPay Server instances and sweep hot wallet balances. Bitquery could not determine the exact number of compromised servers since blockchain data reflects wallets rather than systems, and its $1.63M figure excludes other addresses, coins, and Lightning funds, making it a floor estimate. BTCPay Server noted that some activity at the identified addresses may predate the reported thefts, so balances should not be treated as confirmed losses, and the project has not published an official total.
Remediação
BTCPay Server urges all operators running version 2.4.1 or earlier to rebuild on a fresh server with a new wallet and seed, even if already updated, since patching alone cannot revoke access an attacker may have already obtained. Wallets with spending keys held off-server (e.g., hardware wallets) were unaffected. Operators should preserve logs and transaction records, rotate exposed credentials, keep only operational funds on the server, and avoid restoring the compromised server image onto new infrastructure.
Linha do tempo
-
Attackers Exploit Unpatched BTCPay Server Flaw to Drain Hot Wallets, $1.63M Traced
ler a análise desta fonte ocultar
BTCPay Server, an open-source cryptocurrency payment platform, confirmed that attackers exploited a vulnerability fixed in version 2.4.2 (released August 7, 2026) to steal funds from hot wallets on instances still running 2.4.1 or earlier. Blockchain intelligence firm Bitquery traced 18.38 Bitcoin and 3405 Litecoin (~$1.63M) across 682 sweeps between October 30 and November 2 to two attacker-controlled addresses, with 87% of funds moved in a single wave on November 1. The attacker signed in as an administrator and swept the hot wallets; sweeps worth about $150,000 continued even after BTCPay Server issued a shutdown warning at 22:25 UTC. The same flaw was previously exploited in August to steal funds via the Lightning Network implementation LND, though on-chain hot wallets were reportedly unaffected at that time.
Technical Details
The vulnerability, patched in version 2.4.2, allowed attackers to gain administrative access to BTCPay Server instances and sweep hot wallet balances. Bitquery could not determine the exact number of compromised servers since blockchain data reflects wallets rather than systems, and its $1.63M figure excludes other addresses, coins, and Lightning funds, making it a floor estimate. BTCPay Server noted that some activity at the identified addresses may predate the reported thefts, so balances should not be treated as confirmed losses, and the project has not published an official total.
Remediation
BTCPay Server urges all operators running version 2.4.1 or earlier to rebuild on a fresh server with a new wallet and seed, even if already updated, since patching alone cannot revoke access an attacker may have already obtained. Wallets with spending keys held off-server (e.g., hardware wallets) were unaffected. Operators should preserve logs and transaction records, rotate exposed credentials, keep only operational funds on the server, and avoid restoring the compromised server image onto new infrastructure.