Operators of BTCPay Server running version 2.4.1 or earlier are being told to upgrade now, after the self-hosted payment processor confirmed that attackers are actively stealing Bitcoin and Litecoin from hot wallets on affected instances.
BTCPay Server said its investigation found that the attacks "targeted servers running BTCPay Server 2.4.1 (released on 23 July 2026) or earlier," as reported by The Hacker News. Version 2.4.1 was roughly three months old at the time of disclosure — a reminder that recency alone is not a safety signal when an attack campaign is already under way.
What is known — and what is not
The advisory describes active exploitation in the wild, not a proof-of-concept or a theoretical weakness. That distinction matters operationally: it makes "we'll fold it into the next maintenance window" an invalid strategy for anyone still running an affected build.
Equally important is what has not been published. As of filing, no CVE identifier, no root-cause breakdown, no total figure for funds stolen, and no count of compromised instances have been released. Operators should treat the affected-version line — 2.4.1 and earlier — as the boundary of where attackers have been observed operating, which is not the same thing as a guarantee that newer releases are safe. A definitive statement on newer versions, and a patch identifier to verify against BTCPay's GitHub, are still outstanding and would warrant a follow-up once confirmed.
Why self-hosting raises the stakes
BTCPay's core selling point is that there is no third-party intermediary sitting between a merchant and its money. The flip side is that there is also no vendor pushing a fix to your server. Independence from a payment processor means independence from its remediation: every upgrade decision, including ones deferred because a plugin hasn't been validated against the new release, rests entirely with the deployer.
The hot-wallet design amplifies the cost of getting that wrong. When signing keys live on the same machine as the payment flow, a compromised host converts directly into a theft vector with no cooling-off period.
Operator checklist
For self-hosters, the response sequence should look roughly like this:
- Confirm your version against the advisory and upgrade to the current release as an emergency change, not a scheduled patch.
- Sweep hot-wallet balances to hardware or offline storage until the instance is verified clean.
- Rotate wallet secrets, API tokens, and admin passwords — assume anything stored on the affected host is exposed.
- Review withdrawal, transaction, SSH, and web access logs for activity predating the patch.
- Check admin-panel exposure and look for credential reuse across other systems.
- Preserve logs and records in their current state for incident reporting before any rebuild.
Broader implications
The incident is a clean illustration of a recurring tension in open-source infrastructure: security responsibility shifts entirely to the party doing the deployment, but not every deployer has the capacity to act like a security team. Payment software sharpens the trade-off, because the failure mode is direct financial loss rather than downtime.
It also feeds an ongoing debate about funding and resourcing for widely adopted projects maintained by small teams — particularly those handling custody-sensitive code paths.
For Hong Kong developers and merchants running their own payment infrastructure, the episode is a general reminder that self-hosted custody hygiene is a technical obligation first and a commercial one second: the same controls that keep keys out of an attacker's reach are the foundation of any security posture expected of businesses operating in the city's virtual-asset space. The specific obligation, where one applies, depends on each operator's own licensing position — this article makes no claim about individual regulatory duties.
The practical takeaway is simple: if you are running BTCPay Server 2.4.1 or earlier, treat the upgrade and the wallet sweep as one incident response, not two tickets.
正在運行 BTCPay Server 2.4.1 或更早版本的營運者，現在就應升級 —— 這款自託管支付處理器已證實，攻擊者正在受影響的實例上主動盜取比特幣與萊特幣熱錢包資金。
BTCPay Server 表示，調查發現這些攻擊「針對運行 BTCPay Server 2.4.1（於 2026 年 7 月 23 日發布）或更早版本的伺服器」，據 The Hacker News 報導。披露之時，2.4.1 版本僅推出約三個月 —— 這提醒我們，當攻擊行動已經展開時，版本夠新本身並不等於安全。
已知什麼 —— 以及未知什麼
該通告描述的是已在野外遭積極利用的漏洞，而非概念驗證或理論上的弱點。這個區別在操作層面很重要：對於仍在運行受影響版本的人來說，「留待下個維護時段一併處理」已不再是可行策略。
同樣重要的是目前「未」公佈的內容。截稿前，尚未有 CVE 編號、根本原因分析、被盜資金總額，以及受影響實例數字。營運者應把受影響版本界線 —— 2.4.1 及更早版本 —— 視為攻擊者已被觀察到活動的範圍，這不等同於保證較新版本安全。關於較新版本的明確聲明，以及可向 BTCPay GitHub 核實的修補程式編號，仍然有待確認；一旦落實，便值得跟進報導。
為何自託管會放大風險
BTCPay 的核心賣點，是商家與其資金之間沒有第三方中介。代價是：也沒有廠商主動向你的伺服器推送修復。脫離支付處理器的獨立性，同時意味著脫離其修復能力：每一次升級決定 —— 包括因外掛尚未通過新版驗證而推遲的那些 —— 全部由部署者自行承擔。
熱錢包設計會放大犯錯的代價。當簽署金鑰與支付流程存放在同一台主機上，主機一旦被攻陷，就會直接轉化為盜竊途徑，中間毫無緩衝期。
營運者檢查清單
對自託管者而言，應變次序大致如下：
- 確認版本，對照通告並即時升級至最新版本，作緊急變更處理，而非預定的修補程式。
- 轉移熱錢包餘額至硬件或離線儲存，直至實例確認乾淨。
- 輪換錢包秘密、API token 及管理員密碼 —— 假設受影響主機上的任何資料均已外洩。
- 檢視提領、交易、SSH 及網絡存取日誌，查找修補程式套用之前的活動。
- 檢查管理面板是否對外暴露，並查看是否有憑證在其他系統重用。
- 在重建前原封保留日誌與記錄，以供事故通報之用。
更廣泛的影響
是次事故清晰體現了開源基礎設施中一再出現的張力：安全責任完全轉移到部署一方，但並非每位部署者都有能力像安全團隊般運作。支付軟件使這個取捨更為尖銳，因為失效模式是直接的財務損失，而非服務中斷。
這也延續了一場圍繞廣泛採用、由小團隊維護的專案 —— 尤其是涉及託管敏感程式碼路徑者 —— 在資金與資源方面的爭論。
對香港自建支付基礎設施的開發者與商戶而言，此事是對自我託管保管衞生的通用提醒：這首先是一項技術責任，其次才是商業責任 —— 同一套讓金鑰不落入攻擊者手中的控制措施，正是本港虛擬資產領域對企業所預期的安全基準。至於具體責任是否適用，取決於各營運者自身的發牌狀況；本文不就個別監管責任作出任何聲明。
實際的結論很簡單：如果你正運行 BTCPay Server 2.4.1 或更早版本，請把升級與熱錢包資金轉移視為同一次事故應變，而非兩張工單。