[RSCH] 6 分鐘閱讀OraCore 編輯部

Project Glasswing 揭露 Mythos 會串漏洞

Cloudflare 測試 Mythos Preview 後發現,它能在專門的 harness 裡把小漏洞串成可用 exploit,但前提是流程要切得很細。

分享 LinkedIn
Project Glasswing 揭露 Mythos 會串漏洞

Cloudflare 測試 Mythos Preview 後發現,它能在專門的 harness 裡把小漏洞串成可用 exploit,但前提是流程要切得很細。

Cloudflare 把 Cloudflare 的內部程式庫拿來測。它把 AnthropicMythos Preview 丟進超過 50 個 repo。結果很直接。這模型不只會找 bug,還會把幾個小問題串成可跑的 exploit。

說白了,這不是一般的掃描器。它比較像會寫 PoC 的研究助理。可是,這能力只在很窄的流程裡才穩。流程一亂,它就開始亂槍打鳥。

SignalCloudflare 觀察到什麼為什麼重要
測試 repo超過 50 個樣本夠廣,不是單點運氣
覆蓋率單一 agent 約 0.1%單線工作吃不下大 repo
模型行為能串 primitive 成 exploit從找洞走到做證據
語言差異C / C++ 假陽性更多記憶體不安全程式碼更吵

Mythos Preview 不是只會掃洞

訂閱 AI 趨勢週報

每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。

不會寄垃圾信,隨時可取消。

Cloudflare 的重點很清楚。Mythos Preview 不是只會列出可疑點。它能往下推,試著把漏洞變成可驗證的攻擊路徑。這差很多。因為資安工作本來就分兩段。先找洞,再證明能用。

Project Glasswing 揭露 Mythos 會串漏洞

文章裡提到,模型可以把 use-after-free 這類問題,往 arbitrary read/write 推進。接著再試著碰到 control-flow hijacking。講白了,它不是只說「這裡怪怪的」,而是會動手做證明。

它還會寫 code、編譯、跑測試,再看失敗訊息修正。這個循環很像真人研究員在做事。差別只在於,它可以同時跑很多次。這也是它比傳統靜態掃描器更麻煩的地方。

  • 它能把低嚴重度 bug 串成高嚴重度路徑。
  • 它能產出 PoC,不只是文字描述。
  • 它更像研究員,不像純掃描工具。
  • 它會根據失敗結果反覆修正。

但別誤會。這不代表它每次都對。它只是比早期模型更會往下推。從懷疑走到證據,距離短很多。

拒絕機制有,但不是安全邊界

Cloudflare 也碰到一個很尷尬的點。模型有時會拒絕正常的資安研究請求。就算程式碼沒變,它還是可能翻臉。這種行為很像你問同一題,換個說法就得到不同答案。

文中有個例子很直白。模型一開始拒絕做某個專案的漏洞研究。後來只因為環境出現一個無關變更,它又答應了。另一個案例裡,它先找到嚴重 memory bug,接著又拒絕寫示範 exploit。這種不穩定,對資安流程很要命。

“Semantically equivalent tasks can produce opposite outcomes depending on how and when they’re presented to the model.”

這句話很重要。意思很簡單。光靠模型自己的拒絕規則,不夠當政策層。它比較像訊號,不像防線。你不能指望它自己把風險處理好。

所以 Cloudflare 才會一直把研究用途和一般釋出分開看。能找洞、能串洞的模型,外面一定要多一層控制。

真正麻煩的是雜訊,不是輸出量

資安團隊早就知道,找洞不難,難的是判斷哪個洞真的重要。AI 會把這個問題放大。它很會講得像真的,但很多結果根本撐不到人工複查。

Project Glasswing 揭露 Mythos 會串漏洞

Cloudflare 說,這種雜訊在 memory-unsafe 語言裡更明顯。C 和 C++ 本來就比較容易出記憶體錯誤。Rust 則把很多類型的錯誤直接擋在編譯期。兩邊疊在一起,triage 壓力會很煩。

另一個問題是,模型很愛講保留字。像是 possibly、potentially、could in theory。這種語氣適合探索,不適合排隊修 bug。因為你的 queue 會被一堆看似合理的猜測塞滿。

  • C 和 C++ 的假陽性更多。
  • 含糊的 finding 會增加人工複查成本。
  • 有 PoC 的發現,處理速度通常更快。
  • 模型若太愛保守措辭,triage 會很痛苦。

所以重點不是模型吐了多少結果。重點是它有沒有把證據整理好。這才是能不能進工作流的差別。

單一 coding agent 的形狀不對

Cloudflare 最實際的結論,其實也最沒戲劇性。一般 coding agent 的設計,適合一個任務一路做到底。可是漏洞研究不是這樣。它是大量小問題、平行跑、反覆驗證。

文章提到,一個 agent 面對十萬行等級的 repo,實用覆蓋可能只有 0.1%。這不是模型太爛。是工作型態不合。Context window 一滿,前面的推理就被壓縮掉,前功幾乎白費。

Cloudflare 的解法是 harness。這其實就是一個包在模型外面的流程。它會縮小範圍、拆分任務、讓不同 agent 交叉檢查,再把結果送去驗證。這比單純丟一句「幫我找 bug」有效太多。

  • 窄問題,比大而空的 prompt 更準。
  • 第二個 agent 能先擋掉噪音。
  • 平行任務,比單線長跑更適合大 repo。
  • 把「有 bug 嗎」和「能不能打」拆開,推理品質會好很多。

這也是 Project Glasswing 最有價值的地方。模型很重要,但 workflow 更重要。沒有 wrapper,再強的模型也會亂掉。

這件事對資安團隊的意思

Cloudflare 並沒有說 Mythos Preview 可以取代真人研究員。它說的是,模型已經能做掉一段很重的中間工作。也就是從可疑點,到可驗證證據的那段路。這會改變團隊怎麼分工。

如果你把這篇當成產品測評,就看太小了。真正的變化在流程。單一 chat prompt 不夠了。現在要的是 pipeline。裡面要有範圍控制、PoC 驗證、拒絕機制、去重和人工複核。

我自己的看法很直接。接下來做 AI 輔助資安的團隊,不該再問模型會不會找 bug。該問的是,它能接管研究流程的哪一段,而且錯誤率還能接受。

講白了,Project Glasswing 給的答案很現實。不要只看模型強不強。先把外層流程搭好。讓它的答案可以被測、可以被擋、也可以被重跑。這樣才真的能上線。

接下來該怎麼看這類模型

如果你在做資安、平台工程,或 LLM 工具整合,我會建議先看 harness,不要先看 demo。Demo 很會騙人。Harness 才會告訴你,這模型在真實 repo 裡到底能不能活。

下一步很可能不是更大的單一 agent,而是更多小 agent。每個 agent 做一小段。有人找線索,有人驗證,有人專門打回票。這種分工,比一個萬能助手更像真的工作流。

你如果問我一句話總結,我會說:Mythos Preview 證明了模型可以串漏洞,但真正決定成果的,是你怎麼包它。這才是 Cloudflare 這篇最值錢的地方。