【安全圈】十天 39 個公開 CVE

關鍵詞

AI漏洞挖掘

寫在前面

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

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

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

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

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

類別

項目

數量

典型風險

1

基礎音頻庫

libsndfile 1.2.2

1

IMA-ADPCM 整數溢出（不完整修復變體）

2

企業中間件

Apache Camel / Red Hat Camel

2

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

3

安全工具

hashcat v7.1.2

3

規則/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，本文不計入"已公開"，也不展開技術歸因。

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

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

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

它必須是把研究員的判斷、模型的歸納、動態的驗證、披露的紀律擰在一起的產物。

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

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

命題一：同構變體掃描

一個補丁修了 AIFF 路徑，但 WAV 路徑和 close 路徑沒修。

一個邊界檢查出現在 A 文件，沒出現在 B 文件。

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

漏洞研究里，最貴的不是發現第一個 bug。

最貴的是發現它的家族。

命題二：信任邊界檢視

Infinispan 緩存里的一段數據，為什么能進 ObjectInputStream？

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

abstract Unix socket 上的 supervision 調用，為什么在憑證被置 NULL 之后還繼續轉發命令？

很多漏洞不在算法里。

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

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

WAV、PKZIP、Kerberos、STL、OBJ、VRML、IGES、STEP、PCAP、CAN 數據流，全是解析器的戰場。

解析器做的事很普通：讀字段、算長度、搬內存、遞歸展開、轉換結構。

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

攻擊面不是從"危險函數"開始的。

是從"外部輸入被解釋為內部結構"的那一刻開始的。

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

CVE-2026-37555

技術上，這是一個 32 位整數乘法溢出。看起來沒有任何"性感"的地方。

但它最適合解釋：為什么 AI 在漏洞研究里有結構性價值。

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

第 235 行的 WAV 路徑，沒改。

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

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

這種 bug 不靠靈感。靠結構化追問：

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

·關閉路徑有沒有讀這同一個長度？

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

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

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

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

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

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

這才是工程化。

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

CVE-2026-6857 / CVE-2026-40858

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

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

值得講的不是"反序列化危險"——這個結論已經講了十幾年。

值得講的是：在現代企業系統里，反序列化入口越來越不像入口。

它不是 HTTP body。

不是 RPC 參數。

不是用戶上傳文件。

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

當數據進入 Infinispan，它看起來已經"進了系統內部"。但從攻擊面建模的角度看，只要攻擊者能寫入這個緩存，這里就是輸入邊界。

ObjectInputStream 不會因為調用棧看起來內部就自動變安全。

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

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

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

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

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

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

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

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

CVE-2026-42476 ~ CVE-2026-42481

Open CASCADE Technology (OCCT) 是工業 3D 內核，被廣泛集成進 CAD、CAE、仿真和供應鏈協同系統。

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

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

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

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

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

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

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

工程結論很直接：只要一個系統支持導入文件，它就在接受攻擊者提供的結構化輸入。

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

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

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

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

·遞歸結構有沒有深度限制？

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

·幾何參數有沒有進入數組索引？

·錯誤恢復路徑會不會繼續消費未校驗數據？

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

它們是多輪交叉、數據流追蹤、動態驗證疊在一起的工程問題。

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

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

目標覆蓋 9 個項目：

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

涉及的協議層：

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

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

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

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

當 CAN 幀首字節為 0，index 下溢成 255。

后續寫入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 字節棧緩沖區接收7 字節，再疊加1 + pid_length 偏移。payload_length 是uint8_t，沒有上界校驗。

棧被 1-4 字節的攻擊者可控數據覆蓋。

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

開源車輛監控系統：

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 調用afb_context_change_cred(&xreq->context, NULL) 把憑證置 NULL，然后繼續 xapi->itf->call(xapi->closure, xreq) 轉發命令。

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

AGL widget（CVE-2026-37531）

Zip Slip + TOCTOU 雙重缺陷：

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

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

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

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

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

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

·長度字段是否受控？

·整數會不會下溢？

·固定棧緩沖區是否匹配協議長度？

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

·協議幀字段會不會直接變成內存偏移？

車端代碼有它的特點：長期服務于資源受限環境，C/C++ 歷史包袱重，協議狀態機復雜，測試樣本經常偏正常流量。

正常流量測不出邊界。

攻擊者只關心邊界。

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

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

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

在 UDS 診斷請求的那個 6 字節棧緩沖區。

在 abstract Unix socket 上的 change_cred(NULL)。

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

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

CVE-2026-42482 / 42483 / 42484

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

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

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

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

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

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

規則文件、hash 文本、壓縮包派生數據、Kerberos 結構、密碼候選——它們都來自外部樣本或批量任務。

"這是安全人員用的工具"不構成安全邊界。

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

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

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

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

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

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

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

·Redis handler 和 File handler 都在 unserialize 來自存儲后端的數據。

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

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

·dashboard.blade.php 用 Blade未轉義輸出渲染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 參數直接進User::orderBy($sort, $sortType) ——列名走 ORDER BY 注入。

這些漏洞看起來"傳統"。

但傳統不等于低價值。

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

是危險點換了位置：

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

·SQL 注入不在 where 值，出現在 orderBy 列名；

·RCE 不在公網 HTTP，躲進本地 TCP sync invoke；

·模板不是沒渲染，而是少了轉義。

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

要記住漏洞類別在現代框架里的新形態。

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

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

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

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

這兩種判斷都離工程現場太遠。

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

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

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

適合對補丁做變體展開。

適合圍繞信任邊界追數據流。

適合在解析器里生成結構化風險假設。

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

但它不替代研究員。

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

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

這才是可持續的模式。

也是這 39 個公開 CVE 共同呈現的工作方式。

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

CTO 不一定關心每一個 CVE 的技術細節。安全負責人不一定要讀每一份 ASAN 輸出。

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

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

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

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

2. 信任邊界重畫：把"內部數據"也當輸入

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

Camel 的 Infinispan 和 MixPHP 的 sync-invoke 是同一種結構。

3. 資產盤點擴面：解析器加進清單

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

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

4. 安全測試加邊界樣本

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

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

把它們寫進 CI。

5. 安全工具自己也跑 fuzz

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

給它們配 ASAN 跑一輪。

十、AI 紅隊真正的拐點

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

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

39 個 PUBLISHED CVE 不是終點。

它們是一個信號：

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

這件事對攻擊者有意義。

對防守者更有意義。

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

·沿著補丁找變體；

·沿著緩存找反序列化；

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

·沿著車端協議找長度字段；

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

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

漏洞不會因為系統復雜而消失。

它們只會藏進復雜系統的縫隙里。

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

附錄 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，本文不計入"已公開"，也不展開任何技術細節或歸因。

附錄 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)。

關于 Innora.ai

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

本文嚴格基于上述公開來源。不包含 PoC、payload、復現步驟、未公開漏洞細節，也不引用任何內部架構、模型路線或私有系統實現。

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

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

后面還有更多年。

安全圈

網羅圈內熱點 專注網絡安全

實時資訊一手掌握！

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

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