BTCPay 修補 API 金鑰越權與閃電重複出款風險，最新正式版 2.4.5 尚未包含

發生什麼：兩項修補 10 月 19 日併入主線

開源比特幣收款伺服器 BTCPay Server 在 2026-10-19（UTC）把兩個修補併入 master 分支。第一個是 #7684，由 Kukks 提交、當天 13:56 合併，標題是「Enforce API key permission scope」；第二個是 #7679，由 shin4141 在 10-18 提交、10-19 07:07 合併，處理閃電出款的狀態判斷。Bitcoin Optech 在 10-23 的第 428 期週報把兩者列入「重要程式碼變更」，分別描述為權限提升（privilege escalation）修補，以及可能導致閃電重複出款的錯誤修補。

這兩項都是程式碼合併，不等於商家已經能透過官方正式版取得。依 PR 頁面，兩者合併目標都是 master。

API 金鑰：限單一商店的金鑰，原本可能用到全站權限

BTCPay 的 Greenfield API 用金鑰授權，每把金鑰可被限制在特定權限與特定商店。#7684 的說明寫道，修補後「限於單一商店的金鑰，不能再因為擁有者是伺服器管理員，就使用全站或帳號層級的權限」；被授權替其他使用者建立金鑰的受限金鑰，也不能再建立比自己更大的金鑰。PR 同時說明，既有未設範圍的管理員金鑰維持原本行為。

從變更內容看，修補在授權判斷中只對「商店類」權限保留跨範圍檢查，並在替使用者建立金鑰前逐項比對要求的權限是否已被授予，另新增 58 行測試。實際風險取決於部署方式：受影響的是由伺服器管理員帳號發出、但只想授權單一商店的金鑰，例如交給外掛、會計系統或外包開發者的金鑰。

閃電出款：查不到結果，不再當成失敗

#7679 處理的是另一種營運風險。依 PR 說明，舊版在閃電出款已存有付款證明（付款雜湊）時，若之後查詢節點「沒有結果」，可能把出款取消並清除該證明，即使付款其實並未確認失敗；Optech 的描述是，付款可能已成功，營運者卻能對同一筆再出一次款。修補後，這種情況會保持「進行中」並保留雜湊，供之後再查；確認失敗、確認完成、查詢例外與沒有付款證明的出款，維持原本處理方式。

作者在 PR 中也列出限制：永遠查不到的付款會一直停在進行中，沒有自動到期或查詢次數上限，並可能持續占用 pull payment 的額度；介面上的「標記為等待付款」會清除證明，可能讓自動出款再付一次，因此營運者使用前須先與閃電節點對帳。作者說明本次以單元測試與模擬 HTTP 情境（含 Phoenixd 1.7.5 客戶端）驗證，未跑完整 BTCPay／PostgreSQL 與真實節點整合，也沒有實際付款；PR 並註明開發時有 OpenAI Codex 協助。

正式版狀態：2.4.5 仍是最新，未見安全公告

本站於 2026-10-24 00:30（台北時間）讀取 GitHub 發布頁與 master 分支 Changelog，最新正式版仍是 2026-10-06 發布的 2.4.5，Changelog 也未出現 #7684 或 #7679 條目；同時查詢 BTCPay 儲存庫的公開 GitHub 安全公告清單，結果為空。2.4.5 本身已含多項權限範圍修正，例如預設阻擋對私有網段的對外請求以防 SSRF、出款動作限縮在目前商店等，但不包含本文兩項修補。

因此，目前想取得這兩項修補，只能等下一個正式版，或自行從 master 建置；後者對多數商家並不實際，也會帶入尚未發版的其他變更。

同一天的協議面修正：BOLT11 發票只能有一個付款雜湊

同樣在 10-19，閃電規格 BOLTs #1357 合併。依 Optech 整理，BOLT11 改為要求讀取端拒絕不是「恰好一個付款雜湊（p）與一個付款密鑰（s）欄位」的發票。提案者 Roasbeef 在 PR 中說明，起因是一個熱門 Telegram P2P 機器人遭利用：有的函式庫取第一個付款雜湊、有的取最後一個，系統內兩者並存時，可被騙成以為出款沒付出去而重複付款；Optech 指出受害者是 LNP2PBot。這與 BTCPay #7679 不是同一個漏洞，但都落在「出款系統如何判定一筆已付」這一層。