當 Anthropic 發布 Mythos 的公告時，起初看起來確實令人印象深刻，甚至有些令人擔憂。但仔細閱讀後，公開的證據不如標題效應那樣清晰。經常被引用的「不到 2 萬美元」的數字，並不意味著 Mythos 以這個價格輕鬆找到了一個毀滅性的漏洞；在 Anthropic 自己的報告中，這個預算涵蓋了一個大規模的搜尋過程，進行了約一千次結構化運行和數十項發現。這仍然值得注意，但與人們重複的戲劇化說法非常不同。Mozilla 隨後發布了一篇關於使用 Mythos 在 Firefox 150 中識別出大量 AI 發現的問題的文章，這似乎也將敘事推向了同一方向：AI 已來到漏洞研究領域。我的意思是，後一篇文章的標題是「零日漏洞的數量正在減少」。
儘管這看起來是一個大膽的說法，但這可能是真的。然而，公開的證據並不支持該說法最強的版本，除非你是 Anthropic 選定的公司之一的員工，否則很難弄清楚這些公開的說法僅僅是市場行銷，還是真正的遊戲規則改變者。
有趣的問題不是 Mythos 是否發現了漏洞。它顯然做到了。有趣的問題是發現了什麼類型的漏洞，它們有多嚴重，以及這些發現是否真的改變了防禦者和攻擊者之間的平衡。
我花費了幾個小時瀏覽 Firefox 的提交歷史、諮詢參考和連結的錯誤報告，以更深入地了解 Mozilla 的數字真正意味著什麼。這並不是對每個修補程式的全面審計，但足以形成比市場行銷週期通常允許的更為紮實的觀點。
Mozilla 報告稱，在 Firefox 150 中與 Mythos 相關的漏洞有 271 個。同時，Firefox 150 的安全諮詢報告並未將該聲明對應到一個單一、清晰的 Firefox 專用錯誤 ID 列表。它包含來自不同報告者的許多單獨的 CVE，其中至少有三項明確歸功於 Anthropic，以及幾個匯總的「記憶體安全錯誤」條目：
僅這四個條目就連結到數百個錯誤。這應該立即讓任何人對字面理解標題數字保持謹慎。一個大規模的 AI 輔助清理活動仍然可能很重要，即使每個單獨的修復並不代表一個直接可利用的高端漏洞。這裡連結的錯誤數量分別是 1、55、154 和 107，總計 317 個。但這仍然不應直接與 Mozilla 的「識別出 271 個漏洞」的說法進行比較，因為匯總的 CVE 類別也涵蓋了 Thunderbird 和 ESR 版本，而不僅僅是 Firefox 150。
這裡還有一個基本的會計問題：Mozilla 的 271 個數字、Bugzilla 的錯誤 ID、諮詢報告的 CVE 和單獨的提交不是同一單位。公開來說，你可以重建圖片的碎片，但無法獲得一個單一的、權威的、僅限 Firefox 的列表來清晰地解釋 271 這個數字。這並不意味著 Mozilla 是錯的。這意味著外部人士應該小心，不要過度解讀諮詢報告，就好像它是該聲明的完美帳本一樣。
我編寫了一個小型工具來對提交、錯誤、CVE 和觸及的子系統進行分組，並顯示一些統計數據。我還嘗試對錯誤進行評分，根據找到的關鍵字來確定優先級，以便找出哪些錯誤看起來是真正可操作的。你可以使用它來快速瀏覽提交，甚至在摘要結尾獲取我的腳本來源以供重現。
即使你忽略確切的總數，數據的形狀也很有啟發性：
這種區別很重要。「發現了一個錯誤」與「發現了一個可利用的漏洞」不是同一種說法，更不用說「發現了一個可武器化的鏈組件」了。
在瀏覽器利用方面，存在一個廣泛的光譜，介於：
如果你將這個光譜壓縮成一個單一的標題數字，你會吸引注意力，但會失去精確性。
我使用這些標籤作為大致的發布窗口，而不是 Mythos 的精確邊界。這種區別很重要。下面的統計數據廣泛描述了 Firefox 150 的開發間隔，而不是一個清晰隔離的 Mythos 衍生修復集。因此，它們對於顯示規模和補丁分佈很有用，但不應被解讀為「這些是 271 個 Mythos 漏洞」。
我們還可以注意到，許多與這些錯誤相關的提交比 Anthropic 的帖子早幾天或幾週，在 4 月 2 日有一個明顯的高峰。這並不令人意外。諮詢報告的匯總發生得很晚，一些最終被歸入發布 CVE 的修復顯然是較早編寫的，例如在 3 月 5 日。
這取決於你關心的標準。
如果你是防禦者，答案很直接：是的，廣泛來說，這些修復中的許多都很重要。記憶體安全問題、生命週期錯誤、競爭條件、不正確的所有權和序列化問題，正是防禦者希望在攻擊者接觸到它們之前就消除的模式。即使一個漏洞本身無法被利用，它仍然可以降低安全邊界，或者在與另一個問題結合時變得有用，例如一個相對或任意讀取原語。
如果你像攻擊者一樣思考，標準就更高了。一個漏洞只有在它帶來籌碼時才真正有趣：記憶體控制、類型混淆、權限邊界穿越、沙箱逃逸，或者其他實質上推動利用進程的東西。按照這個標準，許多已發布的修復看起來更像是加固和錯誤債務的減少，而不是明顯的可利用黃金。
這不是批評。加固是好的。但這與證明一個模型現在在尋找高價值瀏覽器鏈方面已經超越了頂級攻擊研究人員的說法不同。
這讓我想到漏洞的背景。對於防禦者來說，無論其可利用性如何，漏洞就是漏洞。在瀏覽器方面，存在一些攻擊面隱藏在額外的用戶互動之後，或者非常特定的設置、運行時選項等等，這些都無法可靠地武器化一個漏洞。作為攻擊者，你通常不會在這類表面上花費精力。
快速瀏覽連結的修復顯示了幾個重複的類別：
其中一些正是危險漏洞的來源。其他則可以更好地理解為由於大規模自動化審查而觸發的預防性維護。
這就是為什麼像 2014596（CVE-2026-6746）這樣的單一問題比巨大的匯總 CVE 類別更引人注目。一個具體的「使用後釋放」漏洞很容易被理解為一個潛在的可利用安全問題。一份長長的「已修復的記憶體安全錯誤」列表在方向上很重要，但在分析上要弱得多，除非你檢查單獨的錯誤。
對 Firefox 150 數據最有利的解釋是：
Mythos 看起來非常擅長大規模地暴露可疑模式。
這已經很有價值了。一個能夠在像 Firefox 這樣龐大的程式碼庫中發現清理錯誤、生命週期風險、API 濫用、不安全假設和潛在記憶體安全問題的模型，即使只有一小部分發現是直接可利用的，也是有用的。對於防禦團隊來說，這可以轉化為更快的加固、更廣泛的程式碼審查覆蓋範圍，以及減少手動分類的時間。公開來說，這是看起來得到良好支持的部分。
這可能是最重要的實際成果。安全團隊不需要一個模型能夠獨立發明完整的利用鏈才能使其具有重大價值。然而，如果你自己嘗試運行任何模型來尋找程式碼庫中的錯誤，或者甚至編寫自己的代理，你很可能確信它會警告你 Mythos 發現的大部分模式。以 Google Big Sleep 為例，它有可能比 Mythos 更有價值，而且沒有如此戲劇性的公告。
攻擊性的說法則更難支持。
從公開的證據來看，我們仍然不知道需要多少 tokens、運行次數和分析師工時，需要多少人工篩選，有多少發現是重複的或低價值的崩潰，Mythos 在同一目標上與其他強大模型相比如何，以及有多少已修復的錯誤在實際的漏洞開發環境中會產生實質性影響。
我敢肯定，Mozilla 甚至沒有花時間去證明可利用性，Mythos 也沒有為他們提供 PoC（儘管一些提交包含崩潰測試）。在不知道實際可利用的錯誤數量的情況下，很難稱之為安全革命，而不是一次成功的大規模漏洞挖掘活動。
而這種區別很重要，因為瀏覽器安全不是以錯誤修復的數量來衡量的，而是以攻擊者是否失去有意義的能力來衡量的。而這在這裡還不明顯。
對於防禦者來說，Mythos 目前看起來很有相關性。即使許多發現「僅僅」是穩定性問題、可疑的清理錯誤或潛在的記憶體安全風險，消除它們也能改善程式碼庫並減少攻擊者未來的機會。然而，我懷疑它在那些我認為更健壯的程式碼庫上是否會產生類似的結果，我渴望了解 Mythos 是否會在 Apple Safari 或 Google Chrome 上產生類似的結果。如果我必須打賭，我會說不會 :)
對於攻擊者來說，這個故事就不那麼令人信服了。Mozilla 的披露本身並沒有證明 Mythos 突然消除了通常的攻擊優勢。如果有的話，公開的證據表明，AI 目前更容易作為廣泛的加固支持，而不是作為單一、決定性的漏洞發現的證明。
這也是為什麼我會將公開的攻擊者說法與 Mozilla 的數字分開對待。例如，一個團隊公開表示，他們的 RCE 和沙箱逃逸鏈在發布後仍然有效。這本身並不是強有力的證據，但它是一個有用的提醒，即「許多修復已落地」並不等於「攻擊性問題已解決」。
這可能會改變。但這次 Firefox 的發布並不能證明它已經改變。
Firefox 150 的數據表明，這是一個對防禦性安全工作真正有用的工具，尤其是在大規模應用時，但公開記錄並不支持人們想從中做出的最強聲明。標題數字令人印象深刻，但它將不同重要性的錯誤混雜在一起，並且沒有公開地解析為清晰的會計。
在外注意安全，仔細閱讀，警惕炒作帖子，不要被他們想推銷的敘事所迷惑。
我親自嘗試判斷錯誤是否相關。當你想了解攻擊面時，這是一個很好的練習。請對我的評論持保留態度。
這個更改表明 nsSSLIOLayerHelpers 對象可能在單獨的線程上被刪除，而 nsSSLIOLayerHelpers::GlobalCleanup() 應該在主線程上運行。如果屬實，這可能導致線程親和性錯誤，因為 Preferences::RemoveObserver 也應該在主線程上運行。
從遠處看，這聽起來可能可以利用，但除非檢查 Preferences 類別的實際線程活動、競爭窗口等，否則很難說。
看來 GlobalCleanup 僅在 Firefox 關閉時調用，這種情況下，我們需要在用戶關閉瀏覽器時保持 TLS 套接字打開，這顯然無法武器化。
MediaEngineFakeVideoSource 是一個假的視頻源，在進行 webrtc 測試時可以使用，當沒有實際攝像頭連接到源提要時。補丁非常簡單：克隆視頻源時，它不會複製原始源選項，這是每個實例的過時數據。這個複製沒有用，因為視頻源選項應該在以後的分配過程中初始化。然而，如果源在以後沒有通過 Allocate 路徑的情況下使用，這可能會成為一個問題。我認為 aSource 沒有被釋放，因為 mSettings 上的複製被保留了，因此它似乎只包含先前通過正常路徑分配的選項。
我感覺如果這導致內存損壞，很容易通過模糊 MediaDevices API 來找到。
此提交在調用指針上的方法之前添加了空檢查。
我對 SpiderMonkey 的 JIT 不夠了解，無法判斷這是否可以利用。
在此提交之前，兩個加載被創建為普通的移動字段加載。在 MWasmLoadField 中，這意味著「沒有陷阱元數據」，並且指令被視為可移動；存在陷阱元數據時，它會變成一個保護程序（js/src/jit/MIR-wasm.h:2754）。這很重要，因為從對象指針加載 wasm 字段可能會在空值時發生故障，並且後端使用 maybeTrap() 將正確的 wasm 陷阱站點附加到發出的故障指令（js/src/jit/Lowering.cpp:8731，js/src/jit/CodeGenerator.cpp:10684）。
2026 - Antide Petit aka xarkes - Made with ❤️