Ledger 修補以太坊 App 漏洞：或致簽署內容與螢幕顯示不一致

持有 Ledger、並用作管理 Ether 或 ERC20 代幣的用戶，建議立即打開 Ledger Live 檢查裝置內以太坊（Ethereum）App 版本。若版本低於 1.22.2，代表未包含一項關鍵安全修補。該修補針對的問題，正正動搖硬件錢包最核心的安全承諾：裝置螢幕所顯示的內容，理應就是你即將簽署的交易。 這宗事件在 2026 年 8 月 24 日因保安公司 TestMachine 發表分析而公開；修補在此之前已存在。兩者之間牽涉「誰先發現、Ledger 何時推出修補」的披露爭議，但對用戶而言更重要的是兩點：你裝置上的版本號是否已更新，以及你過去曾否授出過高風險的合約授權（approval）。 一、漏洞實際影響範圍：不是韌體，也不是私鑰 問題不在 Ledger 裝置韌體（firmware），私鑰保管亦未受影響。漏洞出現在你另外安裝於裝置上的 Ethereum App（用於 Ether 與 ERC20）。它負責整理交易、在螢幕上顯示交易內容並收集用戶確認。 在受影響版本中，交易「顯示—審閱—確認—簽署」的流程可能被打亂。研究指，若一個惡意網頁應用程式已獲你授權存取已連接的裝置，它可在第一筆交易仍停留在螢幕、等待你審閱時，插入第二個簽署指令。App 其後在記憶體中替換交易資料，但不會彈出新的審閱畫面；螢幕仍顯示你剛檢查過的「無害轉帳」，而你按下確認後，實際簽署的卻可能是已被替換的內容。 研究人員表示，此模式已在 Ledger Flex 上可重現。由於多款裝置共享 Ethereum App 的程式碼，Nano X、Nano S Plus、Stax 及 Apex 亦被視為可能受影響。Ledger 未披露最早含錯誤的版本；研究對比從 1.22.1（2026 年 5 月 27 日的既有標記版本）起算。 二、為何「清晰簽署」（Clear signing）是硬件錢包的安全根基 所謂 clear signing，是指在硬件錢包的獨立螢幕上，以明文完整顯示交易資料後才讓用戶確認，包括收款地址、金額；若屬合約呼叫，亦應顯示合約將執行的動作。這亦是硬件錢包存在的核心價值：即使電腦中毒、瀏覽器介面被篡改、網站是釣魚頁，只要你手上的裝置螢幕顯示的是真實簽署內容，操控就能在你按鍵前被識別。 今次漏洞正正擊中這條鏈的薄弱點：私鑰仍留在裝置內、韌體未受動，但用戶「讀到」的內容不一定等於其「同意」的內容。若螢幕顯示不再具約束力，這一點上便與在受感染電腦上使用軟件錢包的風險接近。 三、技術核心：Race condition 與 APDU 指令 研究將問題歸因於 race condition（競態條件）：當兩個幾乎同時發生的指令，誰先被處理會左右最終結果。這類錯誤危險在於程式碼在大多數情況下看似正常，只有在有人刻意設計時序時才會浮現。 硬件錢包與電腦之間常以 APDU 作為通訊指令格式；一次簽署流程會拆成多個 APDU 步驟。Ethereum App 會維持一個狀態（state）以記錄目前正在審閱的交易，但在審閱尚未完成時，該狀態可能被新指令覆寫，導致「畫面」與「實際簽署資料」脫節。 四、為何網站能與裝置直接通訊：WebHID 的角色 WebHID 是瀏覽器介面，讓網站在你明確授權後可直接與已連接的 USB 裝置通訊。沒有它，硬件錢包難以在去中心化應用（dApp）內方便使用；有了它，網站與裝置之間的距離比不少用戶想像更近。 此攻擊需具備前提：你已對某個被操控或遭入侵的網站授予 WebHID 存取權，並在該網站發起交易。它不能遠端攻擊放在抽屜裡的裝置。這令受影響人群有所收窄，但對經常使用 DEX、跨鏈橋或質押介面的用戶而言，授權 WebHID 的情景並不罕見。 五、真正高風險往往不是轉帳，而是代幣授權（Approval） 這類「簽署內容被替換」的情境，造成最大損失的往往不是把一筆轉帳換成另一筆轉帳，而是把原本小額轉帳，替換成對智能合約的代幣授權。 Approval 代表你授權某合約日後可動用指定代幣的某個數量，而毋須你每次再確認扣款。為求方便，許多應用會要求「無限額」（unlimited）授權。這類授權一經給出不會自動到期，除非你主動撤銷。 轉帳與無限額授權的差別在於：轉帳的損失上限是你確認的金額；無限額授權在最壞情況下可能令相關代幣的全部餘額在對方選擇的時間被轉走。因此，把小額轉帳替換成大範圍授權，是攻擊簽署路徑時最具回報的做法。 六、如何修補：把 Ethereum App 更新到 1.22.2（透過 Ledger Live） 版本 1.22.2 以兩道防線封堵上述路徑：其一，審閱進行中時拒絕開啟新的簽署會話；其二，若收到的確認與螢幕顯示時的狀態不一致，會拒絕接受。 更新方式為一般應用更新流程：連接裝置，在 Ledger Live 內打開已安裝應用的管理介面，將 Ethereum App 更新至 1.22.2。資產餘額不會受影響，因為私鑰源自你的 recovery phrase，並不存放在 App 內；即使移除並重新安裝 App 亦不會令資產消失。 如何確認版本：Ledger Live 的裝置管理頁面會顯示每個 App 的版本號。若顯示 1.22.2 或以上，即已包含修補；若為 1.22.1 或以下，仍然欠缺。單看 Ledger Live 本身版本並不足夠。 為何更新韌體不等於更新 Ethereum App：這是最常見的誤解之一。韌體、Ledger Live 與各個幣種 App 彼此獨立維護、獨立更新。用戶即使更新了裝置韌體，裝置內的 Ethereum App 仍可能維持舊版。 七、更新後仍要做的第二步：檢查並逐一撤銷舊授權 App 更新只能保護日後的簽署，不能自動清除過去已授出的合約授權。若你過去數月經常使用 dApp，建議檢查該地址仍然開放的 approvals。區塊鏈瀏覽器及專門介面可列出你的地址授權了哪些合約、可動用哪些代幣。對於不再使用的合約，可逐一撤銷。 撤銷本身是一筆正常交易，會產生網絡費用，因此較適合在手續費較低的時段處理。另需留意一個常被忽略的副作用：每次撤銷都會寫入交易紀錄並產生費用；如你有稅務申報或資產記錄需要，邊做邊整理會更省時，常見稅務及投資組合工具亦可自動讀取這些事件。 八、Ledger 與 TestMachine 的披露爭議（尚未獨立核實） 目前雙方對事件時間線各有說法，且不一致；以下屬各自陳述，未經獨立確認。 Ledger 行政總裁技術長（CTO）Charles Guillemet 表示，內部安全團隊 Ledger Donjon 已自行發現問題，並在公開前約兩星期推出修補；他稱 TestMachine 是在其後才透過漏洞獎勵計劃通報，並批評對方說法有製造恐慌以博取關注之嫌。 TestMachine 則稱，其名為 Azimuth 的自動化測試系統在 Ledger Flex 的測試中發現弱點，並已把結果分享給 Ledger；在其發表分析時，對方認為修補仍未可用。 可核對的時間點顯示：1.22.2 的變更記錄日期為 2026 年 8 月 12 日，源碼倉庫的簽署標記日期為 8 月 13 日；但作為已發布版本在約 8 月 24 日左右才變得可見，時間與 TestMachine 的分析同日。CryptoSlate 曾整理包含上述日期的技術時間線。 九、有沒有資金損失？目前所知 按目前雙方公開資訊，未有確認案例顯示漏洞已被實際利用；亦未有已記錄損失。研究亦指出，透過此路徑無法讀出私鑰。 但仍有重要限制：若用戶在不知情下簽署了被替換的內容，鏈上看起來與一般「自願簽署」無異；受害者可能只會在日後代幣被轉走時才察覺，並誤以為是常見釣魚所致。因此，缺乏已確認案例並不能等同「必然沒有」發生，這屬風險判斷而非可證明的事實。 十、事件帶來的啟示：硬件錢包不是一次性購買的安全狀態 把今次事件解讀為「否定硬件錢包」並不恰當：攻擊需先獲裝置存取授權並配合惡意應用，私鑰未受影響，且漏洞已被修補。更實際的結論是：硬件錢包把信任從電腦轉移到有獨立螢幕的小裝置，而該裝置由韌體、App 及配套軟件構成，且各自獨立更新。安全不是買回來就完成，而是需要持續維護，包括保持 App 更新、定期清理 approvals，對大額資產再加上額外的確認層。 用戶應採取的重點行動 1）立即檢查並更新：在 Ledger Live 的裝置管理頁面查看 Ethereum App；低於 1.22.2 必須更新，單靠韌體更新不足以補上漏洞。 2）清理舊授權：檢查地址仍開放的 token approvals，撤銷所有不再需要者。 3）做好紀錄：撤銷授權與資產重新分配都會產生費用並寫入交易紀錄，建議同步整理，避免日後補記。 （資料截至 2026 年 8 月 25 日。本文不構成投資建議。價格及費用結構可變，購買或使用服務前請向供應商核實條款。）