AI 正在盯上你的 C 程式碼，而且不需要咖啡

AI News · 2026-04-04

原文連結： AI is coming for your C code and it does not need coffee

摘要

• Enable Security 直接點名：AI agents 已經能在大型 C 程式碼庫裡自動找出零日漏洞，這不再是幾年後的問題，而是現在。
• 文章引用 Thomas Ptacek 與 Anthropic Frontier Red Team 的案例，包含 Claude 在 Firefox、Linux kernel 與其他大型專案中挖出高嚴重度漏洞的實例。
• 對 VoIP / WebRTC 這類 RTC 專案來說，風險特別高，因為它們多半是 C/C++、狀態機複雜、協定層交互多，而且歷史包袱重。
• 真正的瓶頸正在從「找漏洞」轉向「處理漏洞」：triage、驗證、修補與發布速度，會比單純的 fuzzing 更決定防線強度。
• 文章也提醒，短期內不該迷信「全面改寫成記憶體安全語言」是萬靈丹；對成熟大型專案來說，這本身可能引入新的風險。
• 對人類研究者而言，優勢會愈來愈集中在協定理解、系統脈絡與實戰判斷，而不是純粹的模式搜尋。

· · ·

[!info] 提醒 這篇文章先前曾以較短版本發在 RTCSec Newsletter, March 2026。如果還沒訂閱，也可以去看原始整理。

重點摘要

AI agents 現在已經能自動在大型 C 程式碼庫中找出零日漏洞。對許多資安研究者來說，這不是未來式，而是已經發生的現在式。

Thomas Ptacek 前幾天寫了 “Vulnerability Research Is Cooked”，而這篇文章幾乎等於把他的論點延伸到 RTC（Real-Time Communications）世界：如果 AI 已經能把漏洞研究做到這種程度，那麼 VoIP、WebRTC 與媒體伺服器這一整類基礎設施，都會被直接捲進去。

Enable Security 的判斷很直接：這不是「五年後再看」的題目，而是現在就得面對的現實。

這個主張，以及為何值得相信

Ptacek 的核心論點很簡單：AI coding agents 的漏洞挖掘能力，已經把資安研究的經濟學改寫了，而且是永久性的，不是短暫熱潮。

他引用 Anthropic Frontier Red Team 的 Nicholas Carlini。Carlini 在 Unprompted Con 上展示的方法甚至有點過於樸素：把 Claude 放進一台虛擬機、給它完整權限、把它當成在打 CTF 一樣下指令。要處理大型程式碼庫，也只是加上每個原始檔的提示，再讓它整個專案一路跑下去。沒有複雜的 fuzzing harness，沒有花幾個月寫工具鏈，沒有精密的 scaffolding。

結果呢？超過 500 個高嚴重度漏洞；與 Mozilla 合作時，Claude 在兩週內找出 22 個 Firefox 漏洞；還有一個 Linux kernel 的 heap buffer overflow，藏在 NFS v4 daemon 裡，居然從 2003 年一路沒被發現。那個漏洞還不是單純的一發即中，而是需要兩個互相配合的對抗性 client，這種多方狀態互動本來就極難靠傳統 fuzzing 找到。模型還是找到了。

這一點對 Enable Security 來說並不陌生。他們自己也在做實驗，而且在實際會碰到的程式碼庫上，看到了類似結果。

為什麼 RTC 程式碼庫特別脆弱

大多數 VoIP / WebRTC 基礎設施幾乎都建在 C 和 C++ 上：Kamailio、Asterisk、pjsip、rtpengine、coturn、FreeSWITCH。這些都是歷史悠久、狀態機複雜、跨協定處理繁多，而且 memory management 充滿細節的成熟專案。偏偏這些特性，正是 LLM 擅長做 pattern matching 的地方。

想想看，一個典型 RTC media server 需要同時處理 ICE、DTLS、SRTP、RTP，還要把它們 multiplex 到同一個 port 上；session 的建立與結束還可能互相競爭；signaling layer 與 media layer 之間的互動又非常複雜。這些地方，正是 subtle bugs 最愛藏身的角落。

現在又多了一個非常有耐心、永遠不會累、也不會因為看太多檔案而厭煩的工具。這對這類專案來說，幾乎是災難級的組合。

文章也指出，部分證據已經是公開而明確的。Enable Security 在 2026 年 3 月的 newsletter 裡提到，三個 Firefox WebRTC CVE 是由包含 Carlini 的團隊、使用 Claude from Anthropic 所找出。Anthropic 也表示，他們與 Mozilla 的合作讓 Claude 在兩週內發現 22 個 Firefox 漏洞。他們另外還提到 AISLE 這個 AI-native security startup，已經能靠自動分析器找到真實的 Firefox WebRTC 與 OpenSIPS 漏洞。

相較之下，March 2026 的 pjproject advisories、Chrome 146 的四個 WebRTC bug，以及 coturn 的 reversed password check，雖然都和趨勢相符，但就公開紀錄來看，還不能直接說是 AI 協助找到的。這個區分很重要。

時間線問題

Carlini 的 talk 裡有個細節值得特別注意：這類 AI 漏洞研究能力大約每四個月就翻倍一次。現在能穩定做到這件事的，只有最新模型。再過一年，你筆電上跑的模型大概也會有類似能力。

所以這不是那種「先觀察看看」的情況。Carlini 還提到，他手上現在有幾百個 Linux kernel crash 還沒時間驗證。這句話很值得停一下。瓶頸已經從「找到漏洞」轉成「處理漏洞」。那些本來就已經被 security triage 壓得喘不過氣的專案，接下來 12 個月會面對更多有效、可重現、而且高嚴重度的回報。準備好了嗎？文章的答案很明白：多半還沒有。

RTC 專案維護者能做什麼？

那麼，專案到底能做什麼？

老實說，沒有神奇解法，但有幾件事比以前更重要了。

triage 能力已經是瓶頸。 現在變便宜的是 discovery；真正昂貴的是接到一個有效 bug report 後，還要理解、重現、修補並釋出。願意投資這條鏈的人——像是清楚的 security contact、合理的 disclosure policy、能快速處理 incoming report 的 maintainer——會比別人有利得多。

更快的 release cycle 也很重要。 一個要三個月才進 tagged release 的修補，不會幫到正在使用你軟體的人。如果問題嚴重，就得更快發版。

自動 fuzzing 與 CI security check 仍然有價值。 它們可以先把顯而易見的問題攔在門外，避免 maintainers 同時要處理 low-hanging fruit 和真正嚴重的漏洞。但也要注意，現在只 fuzz 一個 parser 已經不夠了。AI 找到的 bug 往往牽涉整條 flow：跨 protocol layer 的狀態轉換、用 request data 組 response、session setup 與 teardown 的交互。真正有趣的 bug，現在常常就藏在這些地方，而不是單一 parser 裡。

那記憶體安全語言重寫呢？

文章也明講：對 Kamailio 或 Asterisk 這種大型、成熟、歷史悠久的專案，不會主張直接全面改寫成記憶體安全語言。因為 rewrite 本身就會引入新 bug；而且並不是所有漏洞都是 memory 相關。協定邏輯錯誤、authentication bypass、設定問題，換語言也不會自動消失。

對這種規模與複雜度的專案來說，重寫是一個以年為單位的工程，而且有自己的安全風險。比較合理的長期方向，也許是讓新專案採用記憶體安全語言；但這對今天正在維運的人，幫助有限。

人類研究者還剩下什麼優勢？

這裡的答案其實有點刺耳。

AI 已經在常見的 C 漏洞類型上超過多數人類：buffer overflow、use-after-free、integer overflow 這些，很多人現在根本跟不上。對大多數資安研究者來說，競爭是沒有先打招呼就來了。

但 RTC 的 domain knowledge 暫時還是有價值的。你要知道哪個協定交互在真實部署裡最危險；要知道 media server 裡的 DTLS fingerprint bypass，和別處的同類 bug 代表的 threat model 根本不同；要知道一個 finding 在攻擊者手上到底能造成什麼，而不是只是看起來很嚇人。這種判斷力，仍然需要對系統有很深的實戰理解。

Carlini 的原話是：「現在的模型已經比我更會做漏洞研究，而一年後，它們可能會比所有人都更強。」這句話雖然是針對漏洞研究，但恐怕不只如此。AI 什麼時候會超越大多數高階人類專家，恐怕只是時間問題，不是會不會的問題。RTC 的 domain knowledge 優勢現在還存在，但它正在快速縮小，而且可能比很多人預期得更快。

Enable Security 也在調整自己的方法：價值正在轉向需要深度 RTC domain knowledge 的攻擊面，也就是 protocol-level issues、configuration problems，以及那些需要真正理解 VoIP 和 WebRTC 部署在對抗條件下如何運作的 component interactions。這個優勢今天還有價值。如果要找的是 VoIP penetration test，這種 domain expertise 仍然很重要。他們也提到，自己其實早就開始把 AI 納入資安工作流程，只是仍受限於 confidentiality，不能把什麼都丟給模型。不過那道界線，正在慢慢消失。

結論很直接：RTC 社群真正該問的，不是這件事會不會來，而是你的專案是否已經準備好面對一個「找漏洞」變得又便宜又大量」的世界。老實說，多數專案都還沒準備好。這件事值得認真對待。

· · ·

不是未來警報，是 triage 地獄提前開張

這篇文章最值得被放大的，不是「AI 會不會取代資安研究員」，而是整個安全工作流的重心已經換位。

以前的稀缺資源是「找得到漏洞的人」；現在越來越稀缺的是「能把大量有效漏洞消化完的人」。這代表最值錢的能力，不再只是會 fuzz、會挖、會寫 exploit，而是能把 AI 丟出來的結果快速分類、驗證、修補、回補到工程流程裡。

對真的在做大型基礎設施的人來說，這不是遠方的科幻情境，而是今年就會感受到的壓力。誰先把 triage、release 與安全治理做成工業化流程，誰就能少掉很多晚上被高嚴重度報告追著跑的痛苦。