2026 年 8 月 28 日,Avici 出現卡餘額資金被未經授權提走的事件。鏈上追蹤初期估算損失約由 60 萬美元至逾 100 萬美元不等;其後報道指,Avici 的發卡合作夥伴 Rain 發現舊版 Solana 卡合約存在漏洞,受影響合約已經升級。由於不同數字可能代表攻擊不同階段或不同資金流,早期估算不應直接視為最終損失。
49
50
53
目前較重要的分野,是 Avici 一般的自託管錢包,與用來承載信用卡餘額的獨立合約並不相同。現有報道指,事件主要涉及後者;用戶用來持有其他 Solana 或 EVM 資產的普通錢包,未必受到影響。
50
53
Avici 如何將加密貨幣連接到 Visa 消費?
Avici 採用的是「抵押式信用卡」模式,而不是傳統銀行戶口。按照其文件說明,流程大致如下:
- 用戶把 USDC 存入貸款託管智能合約。
- 這筆存款會在卡上產生相應的美元信用額度。
- 用戶消費時,信用額度會相應扣減。
- 之後 Avici 會按延遲結算安排,通常隔一至兩日、偶爾一星期,把已消費部分的 USDC 從卡合約中清算出來。
35
Avici 文件亦指,抵押合約部署在 EVM 網絡,但可以透過自動跨鏈接收源自 Solana 的存款;卡錢包與智能錢包是分開的,而 Visa 只有在證明確實發生卡片消費後,才可以提取資金。
33
這種設計的吸引力在於,用戶可以用加密資產消費,而不必把整個錢包交給交易所或銀行。不過,「自託管」不等於整條付款流程都簡單、獨立或沒有信任假設。資金一旦進入專門的卡餘額系統,便會涉及智能合約、跨鏈、發卡商、交易授權及結算等多個環節。
事件經過:由不明提取到指向舊版合約漏洞
初期:卡餘額被提走,原因未明
8 月 28 日,Avici 承認卡餘額提款出現問題;同時,鏈上觀察者發現資金流向疑似由攻擊者控制的地址。當時有報道估算約 60 萬至 65.3 萬美元被提走,亦有追蹤指疑似攻擊者錢包後來經手逾 100 萬美元。
49
51
54
58
在這個階段,公開資料未能確定根本原因究竟是:
- 卡合約或抵押合約本身有漏洞;
- 中繼、Passkey、帳戶抽象化或管理員註冊機制被濫用;
- 用戶因釣魚而簽署惡意交易;或
- 前端、後端、跨鏈橋、發卡合作夥伴等其他組件出現問題。
後續:Rain 指向舊版 Solana 卡合約
較後的更新指,Rain 發現 Avici 及少數其他項目使用的舊版 Solana 卡合約存在漏洞,相關合約其後已在各個項目升級;截至該次更新,未再發現新的未授權活動。Avici 表示,受影響的是用來存放充值後卡餘額的獨立 Solana 合約,而用戶自託管的 Solana 及 EVM 錢包則與卡餘額分隔。
50
62
另一項後續說法則指,事件涉及 1,685 名用戶,核對後損失為 500,859.22 美元,Avici 承諾全數退款。
53 這個數字比事發初期的鏈上估算更具體,但讀者仍應分清:前者是攻擊進行期間的即時估算,後者是其後報道的核算結果,兩者不能直接相加。
為甚麼 Avici 仿冒釣魚網站仍然值得警惕?
合約漏洞的說法,並不會消除另一條獨立的釣魚風險線。8 月 28 日的報道指,有人建立冒充 Avici 的假網站,以空投或平台功能作誘餌,誘使用戶連接錢包並授權惡意交易;相關報道把逾 60 萬美元損失歸因於 Avici 仿冒網站,並指當時沒有公開證據顯示 Avici 內部系統遭入侵。
2
4
這兩種情況並非必然互相排斥。卡餘額合約可能同時存在漏洞,而另一批用戶亦可能因連接仿冒網站及簽署惡意交易而失款。在缺乏完整事故報告、受影響地址清單、合約及交易指令對照,以及時間線之前,不能假定所有與 Avici 有關的資金流失都源自同一個原因。
仍有甚麼未交代?
現有公開資料仍未完整回答以下問題:
- 具體受影響的合約版本及部署地址;
- 漏洞利用所涉及的指令或交易次序;
- 攻擊者是否取得未授權管理員權限,或利用其他授權路徑;
- 完整受影響帳戶及餘額名單;
- 系統如何偵測異常,以及由發現到升級合約用了多久;
- 退款流程、涵蓋範圍及時間表;
- 用戶是否需要更換 Passkey、登入工作階段、委派權限或錢包憑證。
Rain 對舊版卡合約漏洞的說法,為卡餘額事件提供了重要解釋,但不應延伸成「所有 Avici 相關錢包被盜都由同一漏洞造成」。要釐清整件事,仍需要一份可供外界核查的詳細事後報告。
受影響用戶現在應該做甚麼?
1. 暫停使用可疑連結及受影響卡合約
不要透過私訊、廣告、社交平台留言或所謂空投公告提供的連結,連接 Avici 或卡相關合約。若必須查閱最新安排,應使用自行儲存的官方網址,或透過獨立核實過的官方支援渠道。
2. 分清「授權問題」與「密鑰已外洩」
如果你曾輸入恢復短語、暴露私鑰、安裝不可信錢包擴充功能,或簽署不明交易,應考慮使用乾淨裝置或可信錢包環境,把剩餘資產轉到全新錢包。若種子短語或簽署密鑰已經外洩,撤銷授權並不能修復問題。
3. 逐個網絡檢查權限
對 EVM 錢包:
- 檢查代幣 allowance;
- 撤銷不熟悉或無限額的 spender 授權;
- 如錢包支援帳戶抽象化,亦要檢查可疑的工作階段密鑰或委派權限。
對 Solana 錢包:
- 檢查近期已簽署交易;
- 查看已連接的應用程式、不熟悉的 delegate 及有效工作階段;
- 不要以為一般 EVM 的「撤銷代幣授權」工具,就能找出 Solana 上所有相關授權。
4. 保留證據
保存錢包地址、交易簽名、可疑網址、截圖、時間,以及引導你連接或簽署的訊息、廣告或貼文。這些資料有助 Avici 的認證支援團隊、錢包供應商或調查人員分辨事件究竟涉及釣魚,還是合約層面的異常。
5. 提防後續「退款」騙案
不要為陌生帳戶傳來的「驗證」、「退款」或「追回資金」交易簽名。已知受害者往往會成為冒充客服或追回專家的下一輪目標。
Avici 對「自託管」安全性的啟示
自託管改變的是風險模式,而不是令風險消失。用戶可以避免把資產的單方面控制權交給中心化託管人,但仍可能受到錢包軟件、智能合約、跨鏈橋、中繼器、Passkey、委派權限、前端、發卡商及結算流程影響。
2026 年的 Coldcard 失竊事件正好展示另一種風險:報道指,約 594 BTC 在約 25 分鐘內從約 500 個錢包被轉走,原因與 Coldcard 硬件錢包生成密鑰時的韌性問題有關;問題出在錢包裝置及韌體,而不是 Bitcoin 底層密碼學本身。
30
Coldcard 代表硬件及密鑰生成風險;Avici 則凸顯合約、授權、操作介面及合作夥伴基礎設施的風險。至於 Core Lightning,現有資料不足以證明其漏洞與 Avici 事件存在技術或運作上的關聯。
實際教訓不是「自託管一定不安全」,也不是「中心化託管必然更安全」,而是要看完整交易路徑。使用加密卡前,用戶應先弄清楚:哪些資產仍留在普通錢包、哪些資產會轉入卡片或託管合約、誰可以授權提款、合約升級由誰控制,以及合作夥伴或合約出問題時有甚麼補救安排。自託管支付產品的安全性,最終取決於整條鏈上及鏈下系統中最薄弱的一環。