關(guān)鍵詞

AI漏洞挖掘

寫在前面

2026 年 4 月 22 日到 5 月 1 日，10 天。

CVE 公開數(shù)據(jù)庫里多了39 條致謝 Innora.ai 的記錄。

CVE-2026-37555、CVE-2026-6857、CVE-2026-40858、CVE-2026-42482??一個一個查 CVE Services API，全是 PUBLISHED。

把這 39 條記錄攤開看，比"AI 找到了一個高危洞"更值得圈內(nèi)關(guān)注的是：

它們不在同一種產(chǎn)品里，不靠同一個 fuzzing 模板，不掛在同一種語言上。

類別

項目

數(shù)量

典型風險

1

基礎音頻庫

libsndfile 1.2.2

1

IMA-ADPCM 整數(shù)溢出（不完整修復變體）

2

企業(yè)中間件

Apache Camel / Red Hat Camel

2

camel-infinispan 不安全反序列化 (CWE-502)

3

安全工具

hashcat v7.1.2

3

規(guī)則/Kerberos/PKZIP 解析中的棧與堆溢出

4

車端嵌入式

Open-SAE-J1939 / isotp-c / uds-c / socketcand / cannelloni / OpenAMP / OVMS3 / AGL / Vanetza

18

CAN/UDS/ISO-TP/J1939/V2X/ELF loader 邊界失控

5

PHP 框架

MixPHP 2.x

6

TCP unserialize / Redis-File handler / SQL 拼接

6

Web 管理面

V2Board 1.7.4

3

XSS / token 暴露 / orderBy 列名注入

7

CAD/CAE 解析

Open CASCADE Technology V8_0_0_rc5

6

STL/OBJ/VRML/IGES/STEP 越界讀、遞歸

另有6 個待核驗編號：CVE-2026-37562、37566、37567、37568、37569、37572。

CVE Services API 當前對它們返回 404，本文不計入"已公開"，也不展開技術(shù)歸因。

數(shù)字之外，更值得讀者多看幾眼的是分布。

C/C++ 邊界錯誤、Java 反序列化、PHP 不可信數(shù)據(jù)流、Web 模板未轉(zhuǎn)義、3D 文件解析——任何一種語言、一類輸入、一種部署形態(tài)，都不是這套流程的天花板。

跨語言、跨形態(tài)、跨場景。這件事單靠人或單靠工具都做不出來。

它必須是把研究員的判斷、模型的歸納、動態(tài)的驗證、披露的紀律擰在一起的產(chǎn)物。

一、不是炫技，是三個工程命題

39 個 PUBLISHED CVE 攤開看，有三條線特別清晰。

命題一：同構(gòu)變體掃描

一個補丁修了 AIFF 路徑，但 WAV 路徑和 close 路徑?jīng)]修。

一個邊界檢查出現(xiàn)在 A 文件，沒出現(xiàn)在 B 文件。

一個長度字段被校驗，另一個同源字段被信任。

漏洞研究里，最貴的不是發(fā)現(xiàn)第一個 bug。

最貴的是發(fā)現(xiàn)它的家族。

命題二：信任邊界檢視

Infinispan 緩存里的一段數(shù)據(jù)，為什么能進 ObjectInputStream？

bind 在 127.0.0.1 的 TCP 服務，為什么可以 unserialize 后 call_user_func？

abstract Unix socket 上的 supervision 調(diào)用，為什么在憑證被置 NULL 之后還繼續(xù)轉(zhuǎn)發(fā)命令？

很多漏洞不在算法里。

它們在一句默認假設里：這里應該是可信的。

命題三：解析器作為攻擊面

WAV、PKZIP、Kerberos、STL、OBJ、VRML、IGES、STEP、PCAP、CAN 數(shù)據(jù)流，全是解析器的戰(zhàn)場。

解析器做的事很普通：讀字段、算長度、搬內(nèi)存、遞歸展開、轉(zhuǎn)換結(jié)構(gòu)。

也正因為太普通，它們常常被低估。

攻擊面不是從"危險函數(shù)"開始的。

是從"外部輸入被解釋為內(nèi)部結(jié)構(gòu)"的那一刻開始的。

二、案例一：libsndfile，補丁旁邊的漏洞

CVE-2026-37555

技術(shù)上，這是一個 32 位整數(shù)乘法溢出?？雌饋頉]有任何"性感"的地方。

但它最適合解釋：為什么 AI 在漏洞研究里有結(jié)構(gòu)性價值。

CVE 官方描述里寫得很清楚：早年的 CVE-2022-33065 修復了 IMA-ADPCM 編解碼中的 AIFF 路徑——src/ima_adpcm.c 的第 241 行給乘法套上了(sf_count_t) 強制轉(zhuǎn)換。

第 235 行的 WAV 路徑，沒改。

第 167 行的 close 路徑，也沒改。

只要samplesperblock × blocks 在 32 位空間溢出，這個錯誤的乘積就會被賦值給 64 位的 sf.frames——一個被精心構(gòu)造的 WAV 文件，足以讓后續(xù)基于錯誤幀數(shù)的內(nèi)存分配崩塌。

這種 bug 不靠靈感?？?b>結(jié)構(gòu)化追問：

·WAV 分支有沒有同樣的乘法？

·關(guān)閉路徑有沒有讀這同一個長度？

·讀取階段和釋放階段是否共享同一個不可信值？

·一處用了更寬的類型，另一處是不是還停留在 32 位？

模型擅長的事，恰好就是這種機械級的同構(gòu)搜索。它把一個已修復點拆成模式：變量來源、算術(shù)表達式、類型寬度、邊界檢查、相鄰格式分支、錯誤路徑、清理路徑——然后掃整個倉庫。

研究員該做什么？做收斂。把候選清單壓成"這里和已修補路徑結(jié)構(gòu)一致，但缺少同等約束"，再用 ASAN 跑出可重復的崩潰。

好的 AI 漏洞挖掘，不是輸出"這里可能有洞"。

它應該輸出："這里和補丁同構(gòu)，但缺少補丁的約束。"

這才是工程化。

三、案例二：Apache Camel，緩存不是信任邊界的終點

CVE-2026-6857 / CVE-2026-40858

Apache 官方公告寫得很坦率：camel-infinispan 組件中，基于 ProtoStream 的遠程聚合倉庫，用 `java.io.ObjectInputStream` 反序列化從 Infinispan 緩存里讀到的對象，且沒有配置任何 `ObjectInputFilter`。

CWE-502，老牌反序列化坑位。

值得講的不是"反序列化危險"——這個結(jié)論已經(jīng)講了十幾年。

值得講的是：在現(xiàn)代企業(yè)系統(tǒng)里，反序列化入口越來越不像入口。

它不是 HTTP body。

不是 RPC 參數(shù)。

不是用戶上傳文件。

它可能是一條緩存記錄。一段消息隊列內(nèi)容。一個連接器在內(nèi)部傳遞的對象表示。

當數(shù)據(jù)進入 Infinispan，它看起來已經(jīng)"進了系統(tǒng)內(nèi)部"。但從攻擊面建模的角度看，只要攻擊者能寫入這個緩存，這里就是輸入邊界。

ObjectInputStream 不會因為調(diào)用?？雌饋韮?nèi)部就自動變安全。

ObjectInputFilter 也不會因為組件名里帶個 ProtoStream 就可以省掉。

這類漏洞對 CTO 真正重要的地方在：企業(yè)里最難盤清楚的，不是"公網(wǎng)接口有幾個"，而是"內(nèi)部可信假設有多少層"。

服務網(wǎng)格、緩存、隊列、連接器、插件、低代碼擴展，把數(shù)據(jù)搬來搬去。每一層都可能把上一層的"已驗證"誤讀成自己的"可信任"。

AI 在這里能做的，不是簡單 grep ObjectInputStream。

grep 只能告訴你哪里用了危險 API。

工程化的做法是順著數(shù)據(jù)流追：誰能寫入？經(jīng)過哪些格式轉(zhuǎn)換？有沒有過濾器？有沒有類型白名單？異常路徑是否會降級到通用反序列化？調(diào)用點是否跨越安全域？

不是看函數(shù)名危險不危險。是看一段數(shù)據(jù)從哪里來、被誰相信、最終被哪個解釋器執(zhí)行。

四、案例三：OCCT，工業(yè) CAD 文件就是攻擊面

CVE-2026-42476 ~ CVE-2026-42481

Open CASCADE Technology (OCCT) 是工業(yè) 3D 內(nèi)核，被廣泛集成進 CAD、CAE、仿真和供應鏈協(xié)同系統(tǒng)。

這一組 6 個 CVE，覆蓋了 STL、OBJ、VRML（三個）、IGES + STEP（B-spline）五大文件格式。

CVE 公告里幾個原文細節(jié)足以說明問題：

·RWStl_Reader::ReadAscii 和RWObj_Reader::read 在調(diào)用Standard_ReadLineBuffer::ReadLine() 之后，沒有對返回 buffer 的長度做校驗，就直接調(diào)用strncasecmp 或按字節(jié)讀取（CVE-2026-42476/42477）。

·VrmlData_Scene::ReadLine 在處理轉(zhuǎn)義字符時用了ptr[++anOffset]，走出了固定大小棧緩沖區(qū)的邊界（CVE-2026-42480）。

·VrmlData_IndexedLineSet::TShape 把外部文件的coordIndex 直接當成數(shù)組下標用，沒有對照坐標數(shù)組的實際長度（CVE-2026-42479）。

·VrmlData_IndexedFaceSet::TShape 在 shape 構(gòu)造期間解引用了未校驗的指針（CVE-2026-42478）。

·IGES B-spline 曲線評估和 STEP B-spline 構(gòu)造里，存在越界讀+無限遞歸（CVE-2026-42481）。

工程結(jié)論很直接：只要一個系統(tǒng)支持導入文件，它就在接受攻擊者提供的結(jié)構(gòu)化輸入。

3D / CAD / 工程格式解析器常常被當成"業(yè)務能力"，不是"安全邊界"。但它們出現(xiàn)在桌面軟件、云端轉(zhuǎn)換服務、縮略圖預覽、供應鏈協(xié)同平臺、工業(yè)仿真平臺——任何一個集成了 OCCT 內(nèi)核的產(chǎn)品，都在執(zhí)行這條解析鏈。

解析器漏洞挖掘的核心不是撞運氣。

是把"輸入字段如何變成內(nèi)存行為"這條鏈路壓出來：

·長度字段有沒有和實際 buffer 綁定？

·遞歸結(jié)構(gòu)有沒有深度限制？

·字符串比較有沒有越過實際行緩沖？

·幾何參數(shù)有沒有進入數(shù)組索引？

·錯誤恢復路徑會不會繼續(xù)消費未校驗數(shù)據(jù)？

這些問題沒法用一個 prompt 一次答完。

它們是多輪交叉、數(shù)據(jù)流追蹤、動態(tài)驗證疊在一起的工程問題。

五、車端 18 個 CVE：協(xié)議棧才是真正的攻擊面

如果說 libsndfile 和 OCCT 是低調(diào)的工程提醒，車端這 18 個 CVE 才是這批結(jié)果里最有傳播價值的一組。

目標覆蓋 9 個項目：

Open-SAE-J1939、isotp-c、uds-c、socketcand、cannelloni、OpenAMP、OVMS3、AGL、Vanetza。

涉及的協(xié)議層：

CAN、CAN FD、UDS、ISO-TP、J1939、V2X、嵌入式 ELF loader、車載應用框架。

CVE 描述里給出的細節(jié)非常具體，沒有任何渲染：

Open-SAE-J1939（CVE-2026-37534 / 37537 / 42467）

傳輸協(xié)議處理器中：uint8_t index = data[0] - 1。

當 CAN 幀首字節(jié)為 0，index 下溢成 255。

后續(xù)寫入tp_dt->data[255*7 + i - 1]——抵達偏移 1791，遠超 MAX_TP_DT_SIZE，越界寫。

uds-c / agl-service-can-low-level（CVE-2026-37536 / 37530 / 42485）

send_diagnostic_request 用6 字節(jié)棧緩沖區(qū)接收7 字節(jié)，再疊加1 + pid_length 偏移。payload_length 是uint8_t，沒有上界校驗。

棧被 1-4 字節(jié)的攻擊者可控數(shù)據(jù)覆蓋。

OVMS3 3.3.005（CVE-2026-37541 / 42468 / 42469）

開源車輛監(jiān)控系統(tǒng)：

canformat_gvret.cpp 的 GVRET length、canformat_pcap.cpp 的phdr.len、canformat_canswitch.cpp 的 CANswitch DLC——三個長度字段全部未校驗。

AGL afb-daemon（CVE-2026-37525 / 37526）

抽象 Unix socket @urn:AGL:afs:supervision:socket 上：

on_supervision_call 調(diào)用afb_context_change_cred(&xreq->context, NULL) 把憑證置 NULL，然后繼續(xù) xapi->itf->call(xapi->closure, xreq) 轉(zhuǎn)發(fā)命令。

8 個 supervision 命令（Exit、Do、Sclose、Config、Trace、Debug、Token、slist）沒有任何認證就能被本地任意進程調(diào)用。

AGL widget（CVE-2026-37531）

Zip Slip + TOCTOU 雙重缺陷：

is_valid_filename 阻止了絕對路徑，沒有阻止 dot notation 目錄穿越。

zread 用openat(workdirfd, ...) 提取文件，存在 check 與 use 的雙重競態(tài)。

Vanetza V2X v26.02（CVE-2026-37554）

GeoNetworking 報文管線里，OpenSSL ECC 點驗證拋出的異常（無效壓縮點、點不在曲線上），Router::indicate() 調(diào)用鏈沒有捕獲。

未處理的std::runtime_error 直接崩 daemon。

這些不是"AI 玄學"。它們是樸素到刺眼的工程檢查：

·長度字段是否受控？

·整數(shù)會不會下溢？

·固定棧緩沖區(qū)是否匹配協(xié)議長度？

·異常會不會跨過邊界無人處理？

·協(xié)議幀字段會不會直接變成內(nèi)存偏移？

車端代碼有它的特點：長期服務于資源受限環(huán)境，C/C++ 歷史包袱重，協(xié)議狀態(tài)機復雜，測試樣本經(jīng)常偏正常流量。

正常流量測不出邊界。

攻擊者只關(guān)心邊界。

車端安全長期被講成"T-Box、APP、云 API"。

這 18 個 CVE 是一次提醒：真正的攻擊面，在協(xié)議棧本身。

在 CAN 幀解析的那一行 data[0] - 1。

在 UDS 診斷請求的那個 6 字節(jié)棧緩沖區(qū)。

在 abstract Unix socket 上的 change_cred(NULL)。

OEM、Tier-1、車載安全團隊，需要把這些位置加進自己的代碼審查清單。不是某個白皮書清單，是真正的源碼行號清單。

六、hashcat：安全工具自己也要被審計

CVE-2026-42482 / 42483 / 42484

hashcat v7.1.2，全球安全行業(yè)最常用的密碼恢復工具。

三個 CVE 全部命中它自己處理外部輸入的解析路徑：

·mangle_to_hex_lower() 和mangle_to_hex_upper() 在src/rp_cpu.c 里有一個棧溢出：邊界檢查沒考慮 hex 轉(zhuǎn)換的 2 倍膨脹。規(guī)則文件配合 -j / -k 選項，加上 128 字符以上的密碼候選，就能觸發(fā)。

·Kerberos 哈希解析里，account_info_len 由不可信的分隔符位置算出，沒有上界校驗就 memcpy——堆溢出。

·PKZIP 哈希解析的 hex_to_binary 里，攻擊者控制的 hex 數(shù)據(jù)被解碼進固定大小 buffer，沒有長度檢查。影響 modules 17200、17210、17220、17225、17230。

這一組的反諷在于：安全工具本身也在處理不可信輸入。

規(guī)則文件、hash 文本、壓縮包派生數(shù)據(jù)、Kerberos 結(jié)構(gòu)、密碼候選——它們都來自外部樣本或批量任務。

"這是安全人員用的工具"不構(gòu)成安全邊界。

恰恰相反，hashcat 這類工具常常運行在高權(quán)限機器、自動化流水線、SOC 取證環(huán)境、CTF 集群里。把外部樣本喂進去，是它的本職工作。

它們應該被當作高價值解析器審計——而且要假定輸入永遠是惡意的。

七、MixPHP / V2Board：老問題的新位置

MixPHP 2.x（CVE-2026-37552 / 42471 / 42472 / 42473 / 42474 / 42475）

公開描述給的位置非常具體：

·Server.php:87 里，sync-invoke TCP 服務從 socket 拿數(shù)據(jù)，直接喂給 `Opis\Closure\unserialize()`，再call_user_func() 執(zhí)行結(jié)果。bind 在 127.0.0.1 上，沒有任何認證或簽名。能訪問本機端口的進程，等于 RCE。

·Connection.php:76 上，sync-invoke 客戶端對服務器響應也調(diào) unserialize()——連到一個惡意服務器就能反向 RCE。

·Redis handler 和 File handler 都在 unserialize 來自存儲后端的數(shù)據(jù)。

·BuildHelper.php 的data / joinOn 函數(shù)里，SQL 拼接通過 data / on 數(shù)組直接走進去。

V2Board 1.7.4（CVE-2026-37503 / 37504 / 37505）：

·dashboard.blade.php 用 Blade未轉(zhuǎn)義輸出渲染custom_html——管理員可以通過 saveThemeConfig 注入任意 JS。

·UniProxyController.php 把server_token走 GET query string—— /api/v1/server/UniProxy/user?token=SECRET 這種 URL 會被 access log、Referer、CDN 日志、瀏覽器歷史一起記錄。

·UserController.php 的sort 參數(shù)直接進User::orderBy($sort, $sortType) ——列名走 ORDER BY 注入。

這些漏洞看起來"傳統(tǒng)"。

但傳統(tǒng)不等于低價值。

很多線上事故不是因為團隊不知道 SQLi、XSS、反序列化危險。

是危險點換了位置：

·token 不在 body，跑到了 query string；

·SQL 注入不在 where 值，出現(xiàn)在 orderBy 列名；

·RCE 不在公網(wǎng) HTTP，躲進本地 TCP sync invoke；

·模板不是沒渲染，而是少了轉(zhuǎn)義。

安全工程不能只記住漏洞類別。

要記住漏洞類別在現(xiàn)代框架里的新形態(tài)。

八、AI 漏洞挖掘的真實定位

安全行業(yè)對 AI 的討論，常常滑向兩個極端。

一個極端是神化：AI 會自動找完所有漏洞。

另一個極端是否定：AI 只是更貴的 grep。

這兩種判斷都離工程現(xiàn)場太遠。

從這 39 個 PUBLISHED CVE 看，更接近真實的判斷是：

AI 正在成為漏洞研究流水線里的放大器。

它適合做大范圍相似代碼歸納。

適合對補丁做變體展開。

適合圍繞信任邊界追數(shù)據(jù)流。

適合在解析器里生成結(jié)構(gòu)化風險假設。

適合把候選點按可驗證性排序。

但它不替代研究員。

漏洞確認、影響判斷、最小復現(xiàn)、安全邊界定義、披露節(jié)奏、與供應商的溝通——都需要人的判斷。

AI 負責擴大搜索半徑。研究員負責收斂事實。

這才是可持續(xù)的模式。

也是這 39 個公開 CVE 共同呈現(xiàn)的工作方式。

九、防守方應該立刻做的五件事

CTO 不一定關(guān)心每一個 CVE 的技術(shù)細節(jié)。安全負責人不一定要讀每一份 ASAN 輸出。

但這批結(jié)果指向的組織級問題值得抄一份給團隊。

1. 補丁管理升級：從單點修復到同構(gòu)變體掃描

修一個 CVE 時，不要只修報告中那一行。把同樣的算術(shù)、同樣的復制、同樣的反序列化、同樣的解析模式，在整個代碼庫里再掃一遍。

libsndfile 的 AIFF/WAV 故事會一遍遍重演。

2. 信任邊界重畫：把"內(nèi)部數(shù)據(jù)"也當輸入

緩存、隊列、本地 socket、插件、后臺任務——任何攻擊者能寫入的地方都是輸入邊界。

Camel 的 Infinispan 和 MixPHP 的 sync-invoke 是同一種結(jié)構(gòu)。

3. 資產(chǎn)盤點擴面：解析器加進清單

文件導入、預覽、轉(zhuǎn)換、協(xié)議解碼、日志解析、壓縮包處理、3D/CAD 模型處理——一個都不能漏。

OCCT 這條線適用于任何一個支持文件上傳的產(chǎn)品。

4. 安全測試加邊界樣本

正常樣本測不出邊界漏洞。

0、255、超長行、深遞歸、長度不一致、異常路徑、關(guān)閉路徑、未初始化字段——這些是攻擊者唯一關(guān)心的輸入。

把它們寫進 CI。

5. 安全工具自己也跑 fuzz

如果你的 SOC 用 hashcat、Wireshark、binwalk、yara 處理外部樣本——它們在你的環(huán)境里就是高權(quán)限解析器。

給它們配 ASAN 跑一輪。

十、AI 紅隊真正的拐點

AI 安全研究的拐點，不是模型第一次說出"這里可能有漏洞"。

是一個團隊能夠持續(xù)地把"可能"變成"證據(jù)"，再把"證據(jù)"變成"負責任的公開記錄"。

39 個 PUBLISHED CVE 不是終點。

它們是一個信號：

AI 漏洞挖掘真正有價值的地方，正在從"會說"轉(zhuǎn)向"會查"，從"會猜"轉(zhuǎn)向"會證"，從"演示能力"轉(zhuǎn)向"工程能力"。

這件事對攻擊者有意義。

對防守者更有意義。

因為同樣的方法，反過來就是企業(yè)自查的劇本：

·沿著補丁找變體；

·沿著緩存找反序列化；

·沿著文件導入找解析器；

·沿著車端協(xié)議找長度字段；

·沿著日志和 URL 找泄漏的 token；

·沿著 orderBy、handler、callback 找框架邊界。

漏洞不會因為系統(tǒng)復雜而消失。

它們只會藏進復雜系統(tǒng)的縫隙里。

AI 漏洞挖掘工程化的真正意義，是把這些縫隙系統(tǒng)地照出來。

附錄 A：39 個公開 CVE 完整清單

libsndfile（1）

CVE-2026-37555

Apache Camel / Red Hat Camel（2）

CVE-2026-6857, CVE-2026-40858

hashcat（3）

CVE-2026-42482, CVE-2026-42483, CVE-2026-42484

車端嵌入式（18）

·Open-SAE-J1939：CVE-2026-37534, CVE-2026-37537, CVE-2026-42467

·isotp-c：CVE-2026-37535

·uds-c：CVE-2026-37536

·socketcand：CVE-2026-37538

·cannelloni：CVE-2026-37539

·OpenAMP：CVE-2026-37540

·OVMS3：CVE-2026-37541, CVE-2026-42468, CVE-2026-42469

·AGL：CVE-2026-37525, CVE-2026-37526, CVE-2026-37530, CVE-2026-37531, CVE-2026-37532, CVE-2026-42485

·Vanetza V2X：CVE-2026-37554

MixPHP（6）

CVE-2026-37552, CVE-2026-42471, CVE-2026-42472, CVE-2026-42473, CVE-2026-42474, CVE-2026-42475

V2Board（3）

CVE-2026-37503, CVE-2026-37504, CVE-2026-37505

OCCT（6）

CVE-2026-42476, CVE-2026-42477, CVE-2026-42478, CVE-2026-42479, CVE-2026-42480, CVE-2026-42481

附錄 B：6 個待核驗編號

CVE-2026-37562, CVE-2026-37566, CVE-2026-37567, CVE-2026-37568, CVE-2026-37569, CVE-2026-37572

CVE Services API 當前對它們返回 404，本文不計入"已公開"，也不展開任何技術(shù)細節(jié)或歸因。

附錄 C：核驗來源

·CVE Services API：https://cveawg.mitre.org/api/cve/

·NVD：https://nvd.nist.gov/vuln/

·Apache Camel Security：https://camel.apache.org/security/

·Red Hat Bugzilla / CVE Tracker

·oss-security 郵件列表

·Ubuntu Security Tracker

事實核查截止時間：2026-05-02 (Asia/Kuala_Lumpur)。

關(guān)于 Innora.ai

Innora.ai 是一家面向 AI 安全、自動化紅隊和工程化漏洞驗證的研究團隊。

本文嚴格基于上述公開來源。不包含 PoC、payload、復現(xiàn)步驟、未公開漏洞細節(jié)，也不引用任何內(nèi)部架構(gòu)、模型路線或私有系統(tǒng)實現(xiàn)。

負責任披露是這批工作的底線。

這是 AI 漏洞挖掘成為工程的第一年。

后面還有更多年。

安全圈

網(wǎng)羅圈內(nèi)熱點 專注網(wǎng)絡安全

實時資訊一手掌握！

好看你就分享 有用就點個贊

支持「安全圈」就點個三連吧！