BTCPay Server Hot Wallets Drained on Outdated Instances

Attackers drained Bitcoin and Litecoin hot wallets on BTCPay Server instances running version 2.4.1 or older, and the project urges updating to 2.4.7.
Table of Contents
    Add a header to begin generating the table of contents

    Attackers drained Bitcoin and Litecoin hot wallets on outdated BTCPay Server instances, and the project’s maintainer is urging all users to install the latest release, version 2.4.7. Reports of theft began on the evening of November 1 (UTC), and total losses have not been published.

    BTCPay Server Operators Told to Shut Down After Theft Reports

    After the first reports, operators were told to shut their servers down pending an investigation. The project also asked VPS hosting providers to take affected instances offline as a precaution. Incident response then identified an attack vector against BTCPay Server version 2.4.1, released July 23, and older builds.

    Founder Nicolas Dorier said the attacks did not target public servers. The investigation focused on how the attacker managed to log in as an administrator on versions older than 2.4.2, which shipped on August 7. The project later confirmed that vulnerabilities in pre-2.4.2 versions were used.

    Merchants Lost Funds From Hot Wallets

    BTCPay Server is self-hosted payment software that merchants use to accept cryptocurrency. Hot wallets hold keys on a connected server, so an attacker with administrator access can move funds directly. Merchants lost Bitcoin and Litecoin from those wallets, and incident reports were still arriving when the maintainer published guidance on Monday.

    A Separate Critical Flaw Led to Emergency Release 2.4.7

    The theft wave came days after an unrelated disclosure. On October 29 the project disclosed a separate critical vulnerability that was found through Anthropic’s Frontier OSS scanner, which prompted the emergency release of version 2.4.7. There are no credible reports of wallet drains on 2.4.7.

    October 29 Flaw Disclosure Preceded the Thefts by Three Days

    The sequence matters for understanding exposure. Servers that stayed on versions before 2.4.2 missed fixes shipped across roughly twelve weeks, and the October 29 notice put a spotlight on the project just before the thefts began. The reporting does not say the October disclosure caused the attacks, and the project’s finding concerns flaws in the older builds.

    Update to BTCPay Server 2.4.7 and Report Losses to the Project

    The maintainer’s instructions are specific. Users should update to 2.4.7 through Server Settings, then Maintenance, then Update, or run btcpay-update.sh on Docker deployments. Anyone on 2.4.1 or older should take the instance offline immediately. Affected users are asked to email security@btcpayserver.org and to report losses to local authorities.

    Hosting Providers Asked to Cut Off Vulnerable Servers

    Asking hosting providers to disconnect instances is an unusual step for an open-source project, since it has no control over servers that merchants run themselves. The request shows how little visibility the maintainers have into deployed versions and how quickly stolen funds can leave a hot wallet.

    BTCPay Server’s Self-Hosted Model Leaves Patching to Merchants

    The case illustrates the exposure of self-hosted financial software that depends on operators to keep it current. Unlike a hosted payment processor, a self-hosted instance has no central party that can push a patch or revoke access, so the burden of timing falls on individual merchants, many of whom run small shops without dedicated security staff.

    Wallet theft is also hard to reverse. Cryptocurrency transfers cannot be recalled, which explains why the project moved to tell operators to power down servers before the full cause was known. The total amount stolen remains unreported, and the number of affected instances is not given.

    BTCPay Server Has Not Published Losses or Instance Counts

    No figure for stolen funds has been released, and the project has not said how many instances were drained. The statement that the attacks did not target public servers suggests the thefts hit instances the attacker could reach through an administrator login, rather than a mass compromise of every exposed deployment.

    Related Posts