newsence
來源篩選

AI Discovers All 12 OpenSSL Zero-Day Vulnerabilities While Curl Cancels Bug Bounty Program

Lesswrong

Our AI system at AISLE successfully discovered all 12 new zero-day vulnerabilities in OpenSSL's latest security release, demonstrating the power of automated cybersecurity discovery in critical infrastructure while the industry struggles with AI-generated spam.

newsence

AI 發現全部 12 個 OpenSSL 零日漏洞,同時 curl 取消漏洞賞金計畫

Lesswrong
大約 1 個月前

AI 生成摘要

我們 AISLE 的 AI 系統成功發現了 OpenSSL 最新發布的所有 12 個零日漏洞,在產業正因 AI 生成垃圾郵件而苦惱之際,展示了自動化 AI 系統在關鍵基礎設施網路安全發現上的強大實力。

這篇文是對 2025 年 10 月 的部分後續報導。

重點摘要: OpenSSL 是全球受到最嚴格審查與審計的加密函式庫之一,支撐著網際網路大部分的加密基礎。他們剛剛公佈了 12 個新的零日漏洞(指在披露時維護者尚不知曉的漏洞)。我們 利用我們的 AI 系統發現了全部 12 個漏洞。這在歷史上是極為罕見的數量,也是 AI 網路安全技術在如此規模下的首次實戰展示。與此同時,curl 剛剛取消了其漏洞賞金計畫,原因是受到大量 AI 生成的垃圾郵件轟炸,儘管我們向他們報告了 5 個真實的 CVE 漏洞。AI 同時在瓦解中位數水準(產生大量垃圾內容),並提升了天花板(在關鍵基礎設施中發現真正的零日漏洞)。

背景

我們 一直在構建一個自動化的 AI 系統,用於深層網路安全發現與修復,有時會以化名 Giant Anteater 參與漏洞賞金計畫。我們的目標是將過去屬於精英、手工式的駭客技藝轉化為可重複的工業化流程。我們這樣做是為了在強 AI 系統普及之前,加固人類文明的軟體基礎設施。平心而論,我們希望確保在這些系統上線的那一刻,我們不會被駭到體無完膚。

目前尚不存在能達到預期性能水準的可靠網路安全基準測試。因此,我們決定針對真實目標測試 AI 系統的性能。這樣做的一個明顯好處是,一個新的零日安全漏洞若要被接受並賦予 (唯一漏洞識別碼),必須通過該專案長期維護者和安全團隊極其嚴格的評判,而這些團隊在許多誘因下往往傾向於不予承認。除了發現 Bug 之外,該問題還必須符合專案的安全立場,即他們認為重要到足以發布 CVE 的程度。 在這方面是出了名的保守,許多報告的問題會被悄悄修復或完全拒絕。因此,我們的「基準測試」完全是外部的,在某些情況下甚至是智力上的對抗。

我們選擇專注於全球軟體生態系統中一些經過最嚴密審計、安全且經過重重測試的支柱。其中, 脫穎而出。行業估計全球至少 2/3 的網路流量使用 OpenSSL 加密,在其中發現一個零日漏洞足以定義一名安全研究員的職業生涯。要在其中找到真實且有價值的安全問題是非常困難的目標。

2025 年秋季:我們的首批 OpenSSL 結果

在 2025 年夏末,也就是我們開始研究 6 個月後,我們針對 測試了我們的 AI 系統,並發現了一些真實且先前未知的安全問題。在 2025 年秋季的 OpenSSL 安全版本中,總共公佈了 4 個 2025 年的 CVE(格式為 CVE-2025-*),其中 3 個是由我們(更準確地說是我們的 AI 系統)發現、負責任地披露,甚至在某些情況下由我們修復的。您可以在我們的中閱讀更多細節。

具體而言,這是兩個中等嚴重程度的問題:

  • CVE-2025-9230: 在 RFC 3211 KEK 解封操作中用於 CMS 基於密碼的加密時,存在越界讀/寫,可能導致記憶體損壞或程式碼執行。這個 Bug 自 2009 年以來就一直存在,隱藏了超過 15 年未被發現
  • CVE-2025-9231: 64 位元 ARM 上 SM2 橢圓曲線簽名的計時側信道漏洞。模運算期間執行時間的變化,理論上可以讓攻擊者透過精確的遠端觀察恢復私鑰。這是一個微妙的邏輯層漏洞,程式碼的正確性掩蓋了計時洩漏,而這種洩漏僅在特定的硬體條件下才會顯現。

我們還發現了一個低嚴重程度的 CVE:

  • CVE-2025-9232: 在解析 IPv6 主機時,HTTP 客戶端的 no_proxy 處理存在越界讀取,會觸發受控的崩潰。

獨立地,由 Gavin Leech、Lauren Gilbert 和 Ulkar Aghayeva 發起的 預測專案,將 AI 驅動的關鍵基礎設施漏洞發現視為 2025 年頂尖的 AI 突破之一,賦予其 0.9 的泛化機率,並按預期影響力排名第 3,其結論為:

Google 的 Big Sleep 代理和新創公司 AISLE 在網際網路的一些主要基礎設施中發現了數十個關鍵漏洞:Linux、cURL、OpenSSL 和 SQLite。 []

關於我們方法的背景:我們的系統處理完整閉環 = 掃描、分析、分類、漏洞利用構建(如果需要且可能)、補丁生成以及補丁驗證。人類選擇目標並擔任高階領航員,負責監督和改進系統,但不執行漏洞發現。對於高知名度的目標,我們會額外手動審查生成的修復方案和披露內容以確保品質,儘管這很少會改變任何結果。

2026 年 1 月:12 個新漏洞中的 12 個

就在今天,2026 年 1 月 27 日,OpenSSL 宣布了 12 個新的零日漏洞,其中包括一個非常罕見的高嚴重程度漏洞。在公佈的 12 個漏洞中,我們 AISLE 利用 AI 系統發現了每一個漏洞。(其中一個漏洞 CVE-2025-11187,在我們最初披露 33 天後,也由來自 Metadust 的安全研究員 Hamza 共同報告。恭喜他在這場良性競賽中代表了人類!🎉)

在 12 個新的 CVE 中,10 個被分配了 CVE-2025-* 識別碼,2 個已屬於 2026 年的 CVE-2026-*。加上我們之前在 2025 年已獲得的 4 個 CVE 中的 3 個,這意味著 AISLE,以及延伸到整個 AI 領域,負責發現了 2025 年 OpenSSL 14 個零日漏洞中的 13 個。漏洞數量和相對比例都隨著時間推移而增加,這在歷史上是非常反常的。

這 12 個漏洞涵蓋了 OpenSSL 程式碼庫的廣大範圍。以下按嚴重程度排序:

高 (HIGH) 嚴重程度 (1):

  • CVE-2025-15467: CMS AuthEnvelopedData 解析中的堆疊緩衝區溢位。此溢位發生在任何加密驗證之前,這意味著不需要有效的密鑰材料即可觸發,使其可能針對任何解析不受信任 CMS 內容的應用程式進行遠端利用。(背景資訊:OpenSSL 中高嚴重程度或以上的 CVE 歷史上平均每年不到一個。)

中 (MODERATE) 嚴重程度 (1):

  • CVE-2025-11187: 在 PKCS#12 MAC 驗證期間,PBMAC1 參數驗證中存在堆疊緩衝區溢位和空指標解引用。(由 Metadust 的 Hamza 在我們披露 33 天後共同報告。)

低 (LOW) 嚴重程度 (10):

CVE-2025-15468, CVE-2025-15469, CVE-2025-66199, CVE-2025-68160, CVE-2025-69418, CVE-2025-69419, CVE-2025-69420, CVE-2025-69421, CVE-2026-22795, CVE-2026-22796,列出主要是為了完整性。

這些漏洞橫跨 QUIC、PKCS#12、PKCS#7、CMS、TLS 1.3 和 BIO 子系統,包括堆積溢位、類型混淆、空指標解引用,以及一個加密 Bug——在 OCB 模式下會留下尾隨位元組未加密且未驗證。其中三個 Bug 甚至可以追溯到 1998-2000 年,隱藏了 25-27 年未被發現。其中一個 (CVE-2026-22796) 甚至早於 OpenSSL 本身,是從 1990 年代 Eric Young 的原始 SSL 實作 繼承而來的。然而,在過去四分之一個世紀的高強度人工和機器審查下,它依然未被發現。

即使是「低」嚴重程度的 CVE,其門檻也比顯而易見的要高。絕大多數報告的問題根本不符合安全漏洞的資格。在符合條件的問題中,大多數是作為標準 PR 修復的 Bug,而沒有賦予 CVE。要從 OpenSSL 獲得 CVE,問題必須通過其保守的安全評估,並被認為重要到需要正式追蹤。OpenSSL 中的「低」嚴重程度仍代表在經過嚴格審計的關鍵基礎設施中,存在一個真實且經過外部驗證的安全漏洞。

在 5 個案例中,AISLE 的 AI 系統直接提出了補丁,並在經過 AISLE 和 OpenSSL 的人工審查後被官方版本採納。

OpenSSL 基金會執行董事 Matt Caswell 對這些發現表示:

「保持廣泛部署的加密技術安全,需要維護者和研究人員之間的緊密協調。我們感謝 Aisle 負責任的披露以及他們在處理這些問題過程中的高品質參與。」

OpenSSL 的 CTO Tomas Mraz 對最新的安全版本評價如下:

「OpenSSL 函式庫以及整個開源專案安全最重要的來源之一就是獨立研究。此版本修復了 12 個安全問題,全部由 Aisle 向我們披露。我們感謝這些報告的高品質,以及他們在整個修復過程中與我們的建設性合作。」

分配的 CVE 仍不能代表全貌。最有價值的安全工作往往是在漏洞發布之前就將其攔截,這也是我的最終目標。在整個 2025 年,AISLE 的系統在 OpenSSL 的開發分支和拉取請求 (PR) 中識別出多個問題,並在它們進入任何發布版本之前就已修復:

  • OCSP 實作中的雙重釋放 (Double-free) ():在受影響程式碼出現在發布版本之前就被發現並修復。
  • RSA OAEP 標籤處理中的釋放後使用 (Use-after-free) 和雙重釋放 ():OAEP 標籤成員的不當複製可能導致在釋放副本時發生 UAF 和雙重釋放。
  • 使用舊版回呼時 BIO_sendmmsg/recvmmsg 的崩潰 ():傳遞給返回回呼的參數缺失,會導致使用舊版 BIO 回呼與新 mmsg 函數的應用程式崩潰。
  • openssl req 中未設置私鑰檔案權限 ():openssl req 命令並不總是為私鑰輸出檔案設置正確的權限。

這就是我們最終努力的方向 = 主動預防漏洞,而不僅僅是在部署後追溯修補。單一研究團隊發現如此密集的漏洞,且涵蓋如此廣泛的子系統和漏洞類型,這在 OpenSSL 歷史上是不尋常的,我認為這在很大程度上歸功於我們對 AI 的大量使用。

更廣泛的影響:curl

OpenSSL 並不是我們測試系統的唯一關鍵基礎設施專案。 這個無處不在的數據傳輸工具,也講述了一個非常相似的故事。

2025 年 7 月,(curl 的創始人兼主要維護者)寫了篇名為「」的文章,沮喪地描述了 AI 生成的垃圾內容如何淹沒了 curl 的漏洞賞金計畫。據他所說,大約 20% 的提交是 AI 垃圾,而 2025 年所有提交中只有 5% 是真實的漏洞。這對小型安全團隊造成的成本在長期內是不可持續的。

就在昨天,2026 年 1 月 26 日,Stenberg 宣布了「」。這個自 2019 年開始運行、為 81 個真實漏洞支付了超過 90,000 美元的計畫,基本上被大量低品質的 AI 提交給毀了。

在上述故事發生的同時,我們 (在 HackerOne 上以 「Giant Anteater」 身份運作,後來與 Daniel 進行私人通信)報告的發現轉化為 curl 中的 5 個真實 CVE:

  • CVE-2025-10966:
  • CVE-2025-11563:
  • CVE-2025-13034:
  • CVE-2025-14017:
  • CVE-2025-14819:

在 2026 年 1 月 8 日發布的 中,我們實際上負責了披露並修復的 6 個 CVE 中的 3 個。在最初的 HackerOne 報告之後,我們轉向與 curl 安全團隊進行直接的私人溝通,報告了 30 多個額外問題,其中大部分是有效的、真實的安全問題(現在有 包含某種形式的「Reported-by: Stanislav Fort」)。

2025 年 10 月,Daniel Stenberg 撰寫了「」,承認某些 AI 驅動的安全研究正在產生真正有價值的結果。他明確提到了 AI 驅動的發現:

「當我們開始處理來自 Joshua 的大量問題清單時,我們又收到了另一份針對 curl 的安全報告。這次是由來自 Aisle 的 Stanislav Fort 提交的(使用他們自己的 AI 驅動工具和程式碼分析流程)。收到安全報告對我們來說並不罕見,我們通常每週會收到 2-3 份,但在 9 月 23 日,我們收到了另一份可以確認為真實漏洞的報告。同樣,這次也使用了 AI 驅動的分析工具。」

在他對 中,在「AI 改進」一項下,Daniel Stenberg 甚至直接寫道:

「新一代 AI 驅動的高品質程式碼分析器,主要是 ZeroPath 和 Aisle Research,開始向我們湧入包含潛在缺陷的錯誤報告。作為這些報告的直接結果,到目前為止我們已經修復了數百個 Bug。」

這是一個非常清晰的例子,展示了分布的頂端如何與其中位數發生分化。大規模採用瓦解了中位數品質(「垃圾內容」毀掉了漏洞賞金 = 對於那些先驗地認為 AI 不行的人來說,這是一個非常有傳播力的故事),但同時也提升了天花板(我們發現了許多 curl 團隊認為有價值到足以修補、分配 CVE 並支付賞金的真實漏洞)。

AI 網路安全時代已正式開啟

在我看來,證據已不再是零星的。在地球上兩個最關鍵、審計最嚴密且最具安全意識的程式碼庫中,我們看到了非常清晰的信號。

OpenSSL

  • 2025 年底至 2026 年初,AISLE 的 AI 系統發現了 15 個 CVE(14 個 CVE-2025-* 中的 13 個,加上 2 個 CVE-2026-*)
  • 在單一最新版本中佔了 12 個 CVE 中的 12 個
  • 在發布前攔截了 4 個額外漏洞
  • 貢獻的補丁被官方版本採納

curl

  • 使用 AISLE 的 AI 發現並修復了 5 個 CVE
  • 在 curl 8.18.0 版本中佔了 6 個 CVE 中的 3 個
  • 根據維護者的說法,由我們和其他 AI 工具直接導致修復了「數百個 Bug」

這些是來自那些有充分理由保持懷疑的專案的外部驗證。OpenSSL 和 curl 的維護者不會把 CVE 當作參加獎發放。他們擁有保守的安全立場、有限的時間,並且(特別是 curl 的情況)對低品質的 AI 提交深感挫折。當他們接受一個漏洞、修復它、分配 CVE 並公開致謝報告者時,這就是安全研究領域最接近真相的時刻。這就是為什麼我們選擇將此作為我們的最終評估。

未來展望

我們尚不知道 OpenSSL 中真實潛在漏洞的總數,因此無法判斷我們對其整體安全性造成了多大的影響。我們也還不知道攻擊方還是防禦方更能從這些能力中獲益。時間會證明一切。如果我們持續追蹤 CVE 數量、嚴重程度和現實世界的影響,我們將看到這是否能在未來幾年轉化為生產環境中明顯減少的可利用 Bug(我相信會的)。

我們目前所知道的是:AI 現在可以在地球上最堅固、審計最嚴密的程式碼庫中發現真實的安全漏洞。 這種能力已經存在,它是有效的,並且正在迅速提高。

我個人認為這有利於防禦。如果這種模式持續下去,發現和修復漏洞的速度快於它們被利用的速度,特別是在像 OpenSSL 這樣整個生態系統都會繼承的基礎函式庫中,我們將獲得複合的安全回報。最難的部分一直是發現,一旦你知道要修復什麼,修復工作就更容易擴展(至少在經常更新的關鍵專案中是這樣)。

我們還沒達到那個目標,但軌跡是清晰的。AI 驅動的漏洞發現時代已經到來,證據表明它可以被用來讓關鍵基礎設施變得真正更加安全。因此,我對強 AI 時代的網路安全未來充滿希望和信心。