文章总结： 本文复盘了Innora.ai团队利用AI辅助在10天内挖掘并公开39个跨语言、跨场景CVE的实践案例。这些漏洞覆盖音频库、企业中间件、车端协议栈、CAD解析器及Web框架等，揭示了同构变体扫描、信任边界误判与解析器攻击面三大核心工程命题。文章指出AI在漏洞挖掘中的真实定位是扩大搜索半径的放大器而非替代者。防守方应立即落实五项举措：从单点修复转向同构变体扫描、将内部缓存与队列视为输入边界、将各类解析器纳入资产清单、在测试中增加边界异常样本，以及对安全工具自身开展Fuzz测试。 综合评分： 92 文章分类： 漏洞分析,AI安全,车联网安全,安全建设,代码审计

---

【安全圈】十天 39 个公开 CVE

安全圈

2026年5月2日 20:09 江苏

在小说阅读器读本章

去阅读

关键词

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 漏洞挖掘成为工程的第一年。

后面还有更多年。

END

阅读推荐

【安全圈】热门 WordPress 重定向插件暗藏休眠后门多年

【安全圈】开源电子病历软件 OpenEMR 发现 38 个漏洞

【安全圈】有缺陷的 VECT 2.0 勒索软件对大文件充当数据擦除器

【安全圈】Linux 内核潜伏 9 年漏洞披露：732 字节脚本攻破 Ubuntu 等发行版，提权至 root 最高权限

【安全圈】cPanel被曝惊天高危漏洞，千万级服务器面临“裸奔”，官方紧急发布补丁！

安全圈

←扫码关注我们

网罗圈内热点 专注网络安全

实时资讯一手掌握！

好看你就分享 有用就点个赞

支持「安全圈」就点个三连吧！

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈 《【安全圈】十天 39 个公开 CVE》