NFTDELTA 論文閱讀分析：很多 NFT 合約真正會先出事的，不是功能寫不出來，而是權限檢查看起來有做、實際上卻留著能被繞過的縫

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Detecting Permission Control Vulnerabilities in NFT Contracts through Multi-View Learning
• 作者：Hailu Kuang 等
• 年份：2026
• 來源：arXiv:2604.15118
• 論文連結：https://arxiv.org/abs/2604.15118
• DOI：10.48550/arXiv.2604.15118
• 主題：NFT Security、Smart Contract Audit、Permission Control、Static Analysis、Multi-View Learning、Web3 AppSec

很多人看 NFT 合約安全，第一直覺還是 reentrancy、price oracle、flash loan 這些大洞。但這篇 NFTDELTA 真正提醒的，是另一種更常被低估、卻非常適合在 production 裡慢慢釀成事故的問題：權限控制不是「有寫 onlyOwner 就算做完」，而是整條 permission check、呼叫路徑、授權語義與狀態變化能不能真的鎖住不該拿到權限的人。

換句話說，這篇 paper 想抓的不是那種一眼就知道爆掉的合約，而是那些表面上看起來有 auth、有 validation、有流程，但細節一歪就能被繞過的 NFT contract。這種洞在實務上很麻煩，因為它們往往不是「功能壞掉」，而是「功能正常跑、只是被錯的人跑到了」。

這篇在處理什麼核心問題？

作者關心的是 permission control vulnerabilities。在 NFT 生態裡，這類問題很關鍵，因為 mint、transfer、approval、metadata 管理、admin 操作、跨合約互動，本質上都跟「誰可以做什麼」有關。一旦權限邊界設錯，後果通常不是單純 bug，而是：

• 未授權的人能改狀態
• 本來只該 admin 做的事被一般呼叫者碰到
• 授權驗證看似存在，但其實可以被特定執行路徑繞過
• 資產管理與控制權分離失敗，最後變成直接經濟損失

這類洞之所以難抓，在於它們不只存在於單一語句，而常常藏在控制流程結構與執行路徑語意裡。你只看 code token、只看某個 AST pattern，或只看一段局部 CFG，常常都只看到半張圖。

NFTDELTA 的主線：不要只看一種程式表示法，要同時看 path 與 structure

這篇論文的核心想法其實很直白：權限控制漏洞本來就同時是 sequence 問題，也是 graph 問題。

作者把 function control flow graph（CFG）拆成兩種 view：

• sequence view：把執行路徑當成序列，去看 permission check 在流程裡怎麼出現、怎麼被接續、怎麼被繞開
• graph view：把控制流結構保留下來，去看條件、分支、路徑回接與整體拓樸關係

然後再把這兩種 view 融合成 unified code representation，最後做漏洞辨識。這個設計很合理，因為很多 auth bug 真正難的地方，不是某個關鍵字沒寫，而是：

• 檢查寫了，但寫在錯的位置
• 檢查存在，但只有部分路徑會經過
• 條件看似嚴格，實際上 validation 太弱
• 流程彼此交錯後，權限管理變得鬆散

所以我會把這篇的價值濃縮成一句話：權限控制弱點不是純粹的 token pattern 問題，而是控制流語義問題；而控制流語義如果只從單一視角看，通常會漏。

作者定義了三類 permission control 漏洞

論文把要抓的缺陷分成三個類別，這點很重要，因為它避免把所有 auth 問題都壓成同一種模糊風險：

• Bypass Auth Reentrancy
• Weak Auth Validation
• Loose Permission Management

這三類其實剛好對應三種實務失敗：

• Bypass Auth Reentrancy：不是只有重入而已，而是重入讓原本應該成立的權限前提被穿過去
• Weak Auth Validation：驗證存在，但強度不夠，導致不該通過的請求還是能過
• Loose Permission Management：權限設計本身太鬆，角色、能力、狀態遷移之間的邊界沒釘死

我很喜歡這種拆法，因為它比單純說「access control 有洞」更貼近稽核現場。真正有用的安全分析，不只是告訴你哪裡怪，而是讓你知道這個怪，到底比較像檢查被繞過、檢查太弱，還是治理模型本身就太鬆。

結果最值得記的不是模型名字，而是漏洞分布本身

論文在 795 個熱門 NFT collections 上做評估，最後找到 241 個確認的 permission control vulnerabilities。這個數字本身就夠有感，因為它表示這不是只在少數奇怪樣本上才看得到的問題，而是熱門 NFT 生態裡就已經存在的結構性風險。

更值得看的是分布：

• 214 個是 Bypass Auth Reentrancy
• 15 個是 Weak Auth Validation
• 12 個是 Loose Permission Management

這組比例透露一件事：真正大量出現的，不一定是那種很抽象的 permission governance 問題，而是控制流互動下的 auth bypass。 也就是說，很多團隊不是完全不知道要做權限，而是在流程交互、外部呼叫、狀態切換這些地方，讓權限檢查失去原本該有的完整性。

精度數字為什麼值得注意？

作者報告人工驗證後的平均 precision 97.92%，以及 F1-score 81.09%。我覺得這兩個數字一起看比較有意思。

• 高 precision 代表它不是那種把 audit team 淹死的亂報器
• F1 81.09% 則表示它不是只追求保守命中，整體偵測能力也還有實戰價值

對合約安全工具來說，precision 特別重要。因為 smart contract audit 本來就高成本，若工具滿地都是 false positive，再漂亮的學術 recall 也很難進 production。NFTDELTA 至少從這個結果看，走的是比較務實的路：寧可把 permission control 問題當成可落地的 triage 工具來做，而不是只做一個 benchmark 上好看的 detector。

這篇對 AppSec / Web3 團隊最大的啟發是什麼？

我覺得這篇 paper 最值得帶回實務的一句話，是：授權不是欄位檢查，而是控制流設計。

很多團隊在 code review 時，對 auth 的心智模型還停在：

• 有沒有 `require(…)`
• 有沒有 owner / role 判斷
• 有沒有 access modifier
• 有沒有白名單

但 NFTDELTA 其實在告訴你，這樣看太平了。真正該問的是：

• 檢查是不是覆蓋了所有能到達敏感行為的路徑？
• 外部互動或 reentrancy 會不會讓原本的 auth 前提失效？
• 權限角色與功能邊界是不是定義得過鬆？
• 驗證條件是不是存在，但不足以代表真正授權？

這種思路其實也不只適用於 NFT contract。把鏡頭拉遠一點，它對一般 AppSec 一樣成立：很多授權問題不是「沒做驗證」，而是「把驗證做成看起來存在、實際上不能完整約束執行路徑的樣子」。

我的看法：這篇真正補的是「權限控制語義」這塊常被低估的自動化缺口

最近很多 AI / 安全研究在追 code generation、agentic exploit、漏洞修補、自動 triage；相較之下，像 NFTDELTA 這種偏 classic static analysis + representation learning 的工作，看起來沒那麼炫。但我反而覺得它很有價值，因為它處理的是一個很務實的缺口：怎麼把「權限控制語義」這種不太好規則化、又不能只靠關鍵字比對的問題，做成可擴展的偵測流程。

如果這條線能持續往前推，未來最有意思的發展不是只有多抓幾個 NFT 漏洞，而是把這種 multi-view control-flow understanding 擴到更廣的 smart contract / AppSec 場景，例如：

• RBAC / ABAC 邊界檢查
• workflow-based authorization
• upgradeable contract 的治理權限
• 跨合約呼叫中的 capability leakage

說穿了，這篇真正有意思的地方不是「NFT 又有洞」，而是它提醒我們：授權邏輯如果只靠人眼在長流程裡硬追，很容易漏；而要把這件事自動化，模型就得同時理解路徑與結構。

總結

NFTDELTA 值得記住，不是因為它又替 Web3 補了一篇漏洞偵測論文，而是因為它把一個常被簡化的問題重新講清楚：權限控制弱點的本質，不只是少一個檢查，而是控制流裡哪些人能沿著哪些路徑碰到哪些能力。

當研究把 sequence view 與 graph view 合起來看，並在 795 個熱門 NFT collections 中挖出 241 個已確認漏洞、且人工驗證 precision 來到 97.92% 時，這篇的訊號其實很明確：很多合約真正危險的，不是完全沒做權限，而是做得像有、實際上卻還能被繞。

對 sectools.tw 讀者來說，這篇最值得帶走的不是某個模型名稱，而是這個防守觀念：只看有沒有 auth check，遠遠不夠；真正該看的，是 auth check 有沒有對整條敏感控制流形成完整約束。