「這個漏洞太老了，我甚至無法直接連結到它，因為它出現在 git 之前。」
這不是某個資深工程師在回顧歷史，而是 Nicholas Lynch 在部落格上描述一個剛被發現的 Linux 漏洞時寫的句子。這個漏洞存在於 Linux 核心中長達 23 年，直到 Claude Code 才找出來。
一個 CTF 競賽中的意外發現
事情的起點很簡單：Lynch 讓 Claude Code 幫忙解決一個 CTF（Capture The Flag）資安競賽的謎題。腳本告訴 Claude Code，使用者正在參加一個資安競賽，需要協助解題。
「hint: look at $file」
「Write the most serious one to /out/report.txt」
在這個看似普通的解題過程中，Claude Code 做了一件超出預期的事：它不僅解開了 CTF 謎題，還發現了一個真實存在於 Linux 核心中的漏洞。
這個漏洞的歷史可以追溯到 2003 年，比 git 的發布時間（2005 年）還要早。在 23 年的時間裡，無數工程師檢視過這段程式碼，卻沒有人注意到這個問題。
漏洞的細節
根據 Lynch 的描述，這個漏洞存在於網路協議的實作中。讓人感興趣的是，Claude Code 在初始的 bug 報告中自動生成了 ASCII 協議圖表，清晰地展示了漏洞的發生位置和影響範圍。
Lynch 使用的是 Claude Opus 4.6，這是 Anthropic 在兩個月前才發布的模型。這意味著，這個漏洞的發現依賴的是最新的 AI 能力。
這個案例很有趣的點在於：它不是經過嚴謹的程式碼審計找到的，而是在一個「假裝參加競賽」的情境下意外發現的。
為什麼它能找到人類沒發現的漏洞？
Linux 核心的程式碼數量龐大，經過數十年的發展，累積了無數的貢獻者。在這樣的程式碼庫中，有些漏洞之所以能藏這麼久，是因為它們：
- 觸發條件非常特殊：只有在特定的資料包組合下才會觸發
- 跨越多個檔案：邏輯分散在不同模組，難以整體把握
- 時序相關：只有在特定的執行順序下才會出現
- 邊界情況：只在極少數的邊界值下才會出錯
- 隱式依賴：程式碼假設某些條件永遠成立，但實際上不成立
人類工程師在進行程式碼審查時，通常會聚焦在特定的功能或模組，很難同時掌握整個系統的全貌。而 AI 模型因為能夠在大規模程式碼庫中建立連結，更容易發現這種跨模組的問題。
更重要的是，人類的注意力是有限的。在一個程式碼審查的 session 中，工程師可能只能專注於幾十到幾百行程式碼。而 AI 模型可以同時「閱讀」數十萬行程式碼，並在這些程式碼之間建立關聯。
這不是說 AI 比人類更聰明，而是說 AI 的「注意力分佈」和人類不同。人類善於理解語境和意圖，AI 善於發現模式和異常。在尋找漏洞這個特定任務上，後者往往更有優勢。
對開發社群的意義
這件事對開發社群有幾個值得思考的面向：
AI 的審計能力正在成熟
Claude Code 並不是第一個被用來找漏洞的 AI 工具，但這個案例的特殊性在於：它找到的是一個存在於主流操作系統核心中長達 23 年的漏洞。這證明了 AI 的程式碼分析能力已經達到可以發現人類難以發現的問題的程度。
CTF 作為測試場景的價值
Lynch 讓 Claude Code 以參加 CTF 競賽的名義去分析程式碼，這個「情境設定」可能是關鍵。在 CTF 的情境下，AI 被鼓勵去尋找任何可能的漏洞，這種開放的思維模式可能比傳統的程式碼審計更有效。
開源軟體的安全性議題
這個漏洞存在於 Linux 核心中，這是最受關注、審查最嚴格的開源專案之一。如果連 Linux 核心都有藏了 23 年的漏洞，那麼其他開源專案的情況可能更令人擔憂。
這件事的啟示
對工程師來說，這個案例帶來了幾個實際的啟示：
1. AI 工具應該成為安全審查的一部分
如果你的專案處理敏感資料，或者部署在關鍵系統上，考慮在 CI/CD 流程中加入 AI 驅動的程式碼分析工具。不一定要是 Claude Code，可以是任何有程式碼分析能力的模型。
2. 讓 AI 以「攻擊者」的角度思考
Lynch 的案例給我們一個啟示：告訴 AI 它在參加資安競賽，可能會讓它更積極地尋找漏洞。這不是要讓 AI 變成惡意的，而是讓它能夠模擬攻擊者的思維模式。
3. 審查舊程式碼時更要仔細
如果你的專案中有使用了超過十年的程式碼，那些部分反而可能是最危險的。舊程式碼往往承載了當時的技術限制和假設，而這些假設在今天的環境中可能已經不再成立。
3. 不要過度依賴單一工具
AI 工具可以發現人類容易忽略的問題，但它們也不是完美的。最好的安全審查策略應該是 AI 分析 + 人類審計 + 自動化測試的組合。
4. 舊程式碼也需要重新審視
如果你的專案中有十年以上的舊程式碼，考慮用 AI 工具重新檢查一遍。這些舊程式碼可能承載了當時的技術限制和思維模式，用現代的視角重新審視，可能會有意外的發現。
對 AI 工具使用者的建議
如果你也在使用 Claude Code 或類似的 AI 編程工具，有幾個實用的建議：
善用情境設定
不要只給 AI 一個簡單的指令，試著給它一個完整的情境。例如：
– 「我在做一個資安競賽的題目，這段程式碼可能有什麼漏洞？」
– 「我是一個紅隊成員，正在評估這個系統的安全性，哪些地方需要改善？」
這種情境設定可以引導 AI 用不同的角度思考問題。
讓 AI 生成視覺化圖表
Claude Code 在這個案例中自動生成了 ASCII 協議圖表，這對理解問題很有幫助。如果你的 AI 工具有類似能力，善用它。
追問「為什麼」
當 AI 發現一個問題時，不要只看結論。問它「為什麼認為這是個漏洞？」、「這個問題在什麼條件下會觸發？」、「可能的影響範圍是什麼？」這些問題能幫助你更深入地理解問題。
對開源專案維護者的啟示
如果你維護一個開源專案，這個案例提醒你：
舊程式碼不是安全的
程式碼被使用了很久不代表沒有問題。考慮定期用 AI 工具重新審查核心模組，特別是那些被繼承下來、很久沒有人修改的部分。
鼓勵社群使用 AI 工具
如果貢獻者使用 AI 工具發現了問題，不要拒絕。AI 發現的問題和人類發現的問題一樣，都需要被認真對待。
文檔的價值
Lynch 能清楚地描述這個漏洞的發現過程和影響，部分原因是他有完整的文檔記錄。好的文檔不僅對人類重要，對 AI 理解程式碼也很有幫助。
社群的回應
Lynch 的文章在 Hacker News 上引發了熱烈討論。許多開發者分享了他們類似的經驗：用 AI 工具審視自己的程式碼時，發現了一些以前完全沒注意到的小問題。
這些經驗表明，當你能夠用 AI 工具定期審視程式碼時，整個專案的程式碼品質會逐漸提升。AI 工具可以大幅降低程式碼審查的成本，讓即使是小型的專案或開源專案，也能夠負擔定期的程式碼審計。
當然，也有聲音提醒我們不要過度依賴 AI。AI 工具可以發現問題，但判斷這些問題是否真的嚴重、是否需要立即修復，這些決策還是需要人類的判斷。
未來的走向
這個案例可能標誌著一個新的趨勢：AI 成為軟體安全性研究的重要工具。未來我們可能會看到更多類似的案例：AI 發現其他系統中長期存在的漏洞。
但同時也會有新的挑戰：如何區分 AI 發現的真漏洞和誤報？當 AI 能夠自動發現和利用漏洞時，安全性研究的規則需要如何調整？如何避免這些工具被惡意使用者利用？
這件事的局限
雖然這個案例令人印象深刻，但我們也需要理解它的局限性：
不是所有漏洞都能被 AI 發現
AI 擅長發現的是那些有明確模式、跨模組、需要大量資訊處理的漏洞。但有些漏洞是邏輯問題或設計缺陷，這類問題可能需要人類的直覺和創造力才能發現。
誤報率和依賴 prompt
AI 分析程式碼時可能會產生許多誤報，如何有效過濾是重要問題。此外，AI 的表現很大程度上依賴於如何設計 prompt，告訴它什麼樣的目標是重要的。
最後的想法
23 年的時間，夠一個大學生從出生到博士畢業。在這麼長的時間裡，這個漏洞靜靜地藏在 Linux 核心中，直到一個 AI 模型在「參加 CTF」的情境下把它找了出來。
這件事說明了兩點：第一，AI 的程式碼分析能力已經達到一個新的高度；第二，我們對軟體安全性的認識，可能才剛剛開始。
對工程師來說，這不是一個「AI 會取代人類」的故事，而是一個「AI 能幫助人類做得更好」的故事。安全審查這種需要大量細節處理和跨模組思考的工作，正是 AI 最擅長的領域。
或許，下一個藏了十幾年的漏洞，會在你用 AI 工具檢視自己的程式碼時被找出來。這不是壞事——這意味著你的系統會變得更安全，而這正是軟體工程中最重要的目標之一。
這篇文章告訴我們，當我們用 AI 工具審視程式碼時，不只是在找 bug，是在重新思考什麼樣的程式碼是安全的，什麼樣的測試是足夠的，什麼樣的審查是有效的。這些問題沒有標準答案，但有了 AI 的幫助，我們比以前更有機會找到答案。