文章总结： OpenSSL近期修复了由AI辅助发现的高危漏洞CVE-2026-45447，标志着AI已从概念验证进入主流漏洞挖掘实践。该漏洞位于pkcs7_verify()函数，存在use-after-free风险，可能被利用于远程代码执行。事件表明AI能显著提升代码审计、输入构造和漏洞验证效率，同时加速攻防双方的分析节奏，对企业资产识别、补丁管理和AI工具应用能力提出更高要求。 综合评分： 94 文章分类： 漏洞分析,AI安全,网络安全,安全运营,红队

---

AI 辅助漏洞挖掘进入主流：OpenSSL 漏洞修复背后的新变量

JacobWang JacobWang

NowSec

2026年6月12日 08:00 陕西

在小说阅读器读本章

去阅读

最近，OpenSSL 再次发布安全更新，修复了多项漏洞。其中最值得关注的，并不只是某一个漏洞本身，而是这些漏洞背后的发现方式正在发生变化。

在这次修复中，一个高危漏洞 CVE-2026-45447 引起了安全圈关注。该漏洞位于 OpenSSL 的 PKCS7_verify() 函数中，攻击者可通过特制的 PKCS#7 或 S/MIME 签名消息触发 use-after-free 问题，可能导致进程崩溃、堆内存破坏，甚至在特定场景下造成远程代码执行。

更关键的是，这个漏洞由 Calif.io 研究员 Thai Duong 在 Claude 和 Anthropic Research 协作下发现。

这意味着，AI 已经不只是帮助开发者写代码、生成脚本、总结日志，而是开始实质性进入漏洞挖掘、代码审计和安全研究流程。

过去，AI 安全讨论更多聚焦于「AI 会不会产生风险」；现在，另一个趋势也变得越来越明显：AI 正在成为发现风险的工具。

这可能是软件安全领域一个新的分水岭。

一、为什么是 OpenSSL？

OpenSSL 不是普通开源项目。

它是全球使用范围极广的密码学和 TLS/SSL 基础库，被大量操作系统、Web 服务、中间件、邮件系统、VPN、IoT 设备、企业应用和安全产品间接或直接使用。

很多人平时不会主动安装 OpenSSL，但自己的系统里大概率存在它。Nginx、Apache、curl、Postfix、OpenVPN、各种 SDK、容器基础镜像、Linux 发行版，都可能依赖 OpenSSL 或相关密码库能力。

这也是 OpenSSL 漏洞一直备受关注的原因。

它不是一个「某业务系统的小漏洞」，而是底层基础设施的一部分。一旦某类漏洞影响范围较广，风险就会沿着系统依赖、软件包、容器镜像、固件、第三方组件一路扩散。

更重要的是，OpenSSL 已经被安全社区反复审计多年。这样一个成熟、关键、长期被关注的代码库，仍然能被 AI 辅助发现新的漏洞，这本身就说明了一个问题：

AI 辅助漏洞挖掘已经开始从实验室概念，进入真实世界的主流软件安全场景。

二、这次 OpenSSL 修复了什么？

从官方安全公告来看，OpenSSL 在 2026 年 6 月 9 日发布了一批安全更新，涉及 OpenSSL 4.0.1、3.6.3、3.5.7、3.4.6、3.0.21 等版本。

其中最受关注的是高危漏洞 CVE-2026-45447。

这个漏洞的触发点与 PKCS#7 或 S/MIME 签名消息处理有关。当 SignedData 结构中的 digestAlgorithms 字段以异常方式出现时，OpenSSL 在 PKCS7_verify() 处理过程中可能错误释放调用方拥有的 BIO 对象。后续应用如果继续使用或释放该 BIO，就可能触发 use-after-free。

从影响上看，use-after-free 属于内存安全问题。轻则导致应用崩溃，造成拒绝服务；重则可能导致堆内存破坏，并在特定应用上下文和内存分配条件下被进一步利用。

需要注意的是，并不是所有使用 OpenSSL 的服务都会直接受影响。官方公告中也明确提到，受影响的是使用 OpenSSL PKCS#7 API 处理 PKCS#7 或 S/MIME 签名消息的应用。使用 CMS API 处理相关内容的应用不受该问题影响。

这也给企业安全处置提供了一个重要提醒：OpenSSL 漏洞不能只看「有没有安装」，还要看「有没有调用到相关功能路径」。

同样是 OpenSSL 漏洞，有的影响 Web TLS 握手，有的影响证书解析，有的影响邮件 S/MIME，有的影响 CMS、PKCS#12、QUIC、OCSP 等特定能力。不同场景下的风险优先级完全不同。

三、AI 在这次事件中扮演了什么角色？

这次事件最值得讨论的，不是「AI 找到了一个漏洞」这么简单。

更准确地说，AI 正在参与漏洞挖掘流程中的多个环节：

第一，辅助理解复杂代码路径。

OpenSSL 这类项目代码历史长、模块多、兼容分支复杂。很多漏洞不在明显的危险函数里，而是隐藏在协议解析、对象生命周期、异常分支、边界条件和历史兼容逻辑中。AI 可以帮助研究人员更快梳理函数调用关系、输入结构、状态变化和潜在异常路径。

第二，辅助构造触发条件。

很多真实漏洞不是简单输入一个超长字符串就能触发，而是需要满足特定结构、特定字段组合、特定状态顺序。像 PKCS#7、S/MIME、CMS、ASN.1、QUIC 这类协议或格式，本身就有复杂的嵌套结构。AI 可以帮助研究人员理解格式约束，并推导可能触发异常路径的输入组合。

第三，辅助验证漏洞影响。

安全研究不能只停留在「看起来有问题」。真正能被接受的漏洞报告，需要说明触发方式、影响范围、可达路径、利用条件、受影响版本、修复建议。AI 可以帮助研究人员整理验证思路、生成 PoC 草案、比对补丁逻辑、分析影响边界。

第四，辅助生成修复建议。

AI 不只是发现问题，也可以帮助提出修复方向。但这一点需要谨慎对待，因为密码学库和底层基础设施的修复不能只追求「代码能跑」，还要保证兼容性、正确性、安全性和历史行为一致性。AI 生成的修复建议必须经过维护者和安全研究人员严格验证。

所以，AI 在漏洞挖掘中的价值，并不是替代安全专家，而是放大安全专家的分析能力。

四、从「人工审计」到「AI + 人工验证」

过去，漏洞挖掘主要依赖几类方式：

人工代码审计、模糊测试、静态分析、动态分析、符号执行、安全研究员经验、真实攻击暴露。

这些方法依然重要，并不会因为 AI 出现而失效。

但 AI 带来的变化在于，它可以把大量原本需要人工反复阅读、理解、归纳和假设的工作，前移到自动化分析阶段。

以前安全研究员需要在大量代码路径里寻找可疑点。现在 AI 可以先帮助筛出一批「值得看」的路径，再由研究员判断哪些是真正有价值的漏洞。

以前一个复杂协议解析逻辑可能需要很长时间理解。现在 AI 可以帮助快速建立代码语义地图。

以前静态分析工具可能报出大量误报，安全人员要花大量时间过滤。现在多模型系统和上下文分析能力，有机会把漏洞发现从「规则匹配」推进到「语义理解」。

这也是为什么近期 AISLE 等团队多次强调 AI 在 OpenSSL 漏洞发现中的作用。根据其公开说法，AISLE 的自主分析系统曾发现 2026 年 1 月 OpenSSL 协调发布中的 12 个 CVE，并在 2026 年 4 月 OpenSSL 修复中发现 7 个问题中的 5 个。

这类说法本身来自安全厂商和研究团队，需要结合官方公告和补丁记录审慎看待。但趋势已经很明确：AI 辅助漏洞挖掘正在从「演示能力」变成「真实产出」。

五、这对攻击者意味着什么？

任何安全能力都有两面性。

AI 能帮助防守方发现漏洞，也可能帮助攻击者更快理解漏洞、定位补丁差异、构造利用方式。

过去，一个攻击者想要从补丁中还原漏洞，需要具备较强的代码审计能力。现在，AI 可以帮助分析补丁前后差异，解释函数行为变化，推断漏洞触发条件，甚至辅助生成测试输入。

这会压缩漏洞利用的时间窗口。

也就是说，从官方发布补丁到攻击者完成漏洞复现之间的时间，可能越来越短。

这对企业安全运营提出了更高要求：

补丁发布后，不能长期停留在「评估中」。

对于基础组件、边界服务、邮件网关、证书处理系统、对外开放服务、VPN、代理网关、容器基础镜像等场景，必须更快完成版本排查、影响判断和升级计划。

AI 时代的漏洞响应节奏会变快，因为攻击者的分析成本也在下降。

六、这对防守方意味着什么？

对防守方来说，AI 辅助漏洞挖掘不是坏事。

相反，它可能是提升软件安全水平的重要机会。

过去很多基础软件项目存在一个长期矛盾：代码越关键，使用越广，但维护资源并不一定足够。大量开源基础设施支撑着全球互联网，但维护者数量有限，安全审计资源有限，企业使用方又经常把它们当成「默认可靠」的底层组件。

AI 的加入，有机会改变这种不平衡。

它可以帮助安全团队更高频地扫描代码库，帮助开源项目更早发现隐藏问题，帮助企业在上线前识别依赖风险，也可以辅助内部红队和安全研究人员提升效率。

但前提是，企业不能把 AI 漏洞挖掘当成「魔法」。

AI 发现的问题需要验证。 AI 生成的 PoC 需要控制。 AI 给出的修复建议需要评审。 AI 产生的误报需要筛选。 AI 使用的代码和数据需要合规。 AI 分析过程也需要审计和留痕。

真正可靠的模式，不是「AI 自动找洞并自动修复」，而是「AI 辅助发现，人工确认影响，工程化修复上线」。

七、企业应该如何处理这类 OpenSSL 漏洞？

对于企业安全团队来说，面对 OpenSSL 这类基础组件漏洞，建议不要只做简单的「扫版本」。

更合理的处理流程应该包括以下几个步骤。

第一，梳理资产中 OpenSSL 的使用位置。

不仅要看服务器系统自带的 OpenSSL 版本，还要看应用内置库、容器镜像、静态编译程序、第三方软件包、安全设备、中间件、邮件系统、VPN、代理服务和开发工具链。

很多 OpenSSL 不是通过系统包管理器安装的，而是被软件静态链接或打包进应用目录里。只查 rpm、dpkg 或 yum 结果，可能会漏掉真实风险。

第二，确认是否调用受影响功能。

以 CVE-2026-45447 为例，重点是是否使用 OpenSSL PKCS#7 API 处理 PKCS#7 或 S/MIME 签名消息。如果系统只是普通 HTTPS 服务，未必直接触发该路径；但如果是邮件安全网关、文档签名验证、证书处理平台、S/MIME 解析服务，就需要重点关注。

第三，区分边界资产和内部资产优先级。

对外暴露服务、自动处理外部输入的系统、邮件入口、网关类服务、证书处理服务，应优先排查和修复。内部低暴露、无相关功能调用的系统可以进入后续批次，但不应长期搁置。

第四，关注发行版回补版本。

很多 Linux 发行版不会直接升级到 OpenSSL 官方最新大版本，而是把安全补丁 backport 到当前维护版本中。因此判断是否修复，不能只看版本号是否完全等于官方推荐版本，还要看发行版安全公告和补丁记录。

第五，更新容器基础镜像。

大量业务运行在容器中，宿主机修复并不代表容器内部依赖同步修复。需要检查基础镜像、运行镜像和 CI/CD 构建链路中的 OpenSSL 版本，并重新构建发布。

第六，保留回滚与兼容性验证。

OpenSSL 属于底层基础库，升级可能影响应用兼容性，尤其是老旧系统、旧协议、弱算法、历史证书链和特殊加密套件。升级前应完成测试，升级后要观察握手失败、证书校验失败、业务调用失败等异常。

八、AI 漏洞挖掘会不会让漏洞数量暴增？

短期看，已知漏洞数量可能增加。

但这不一定是坏事。

漏洞数量增加，不代表软件突然变差，也可能代表原本存在的问题被更高效地发现了。

OpenSSL 当年经历 Heartbleed 后，安全社区对开源基础设施的关注明显提升。后来 OpenSSL 在开发流程、代码质量、安全响应、审计机制方面都有改进。一个成熟项目持续披露并修复漏洞，未必说明它不安全；长期没有漏洞披露，也不一定说明它安全。

AI 辅助漏洞挖掘进入主流后，很多历史遗留问题可能会被重新挖出来。

这会给维护者带来压力，也会给企业安全团队带来更多补丁工作。但从长期看，这有助于提升基础软件的整体安全水平。

真正需要担心的，不是漏洞被发现，而是漏洞被发现后企业没有能力快速判断和修复。

九、安全团队需要补上的新能力

AI 辅助漏洞挖掘进入主流后，企业安全团队需要补上几类能力。

第一，组件级资产识别能力。

要知道系统里到底用了哪些库、什么版本、通过什么方式引入、是否静态链接、是否存在于容器镜像或第三方软件中。没有 SBOM 和组件清单，就很难快速响应基础组件漏洞。

第二，漏洞影响路径分析能力。

不是所有漏洞都需要同等优先级处理。安全团队需要判断漏洞是否可被远程触发、是否处理不可信输入、是否位于边界链路、是否涉及高权限进程、是否存在业务调用路径。

第三，补丁差异分析能力。

AI 时代，攻击者会更快分析补丁。防守方也要具备补丁 diff、调用链分析、PoC 验证、日志排查和临时缓解能力。

第四，安全研发协同能力。

基础库升级往往需要研发、运维、安全、测试共同参与。安全团队不能只发漏洞通知，还要给出影响场景、排查命令、升级建议、验证方法和回滚方案。

第五，AI 安全工具使用能力。

既然 AI 能帮助攻击者，防守方也应该把 AI 纳入安全工作流中。包括代码审计、依赖风险分析、补丁影响评估、日志关联分析、规则生成、应急响应文档生成等。

十、结语：AI 不是安全答案，但会改变安全节奏

OpenSSL 这次漏洞修复背后的重点，不只是某一个 CVE，也不只是某个版本升级。

更大的变化在于：AI 正在进入真实的软件安全生产链路。

它会帮助研究人员更快发现漏洞，也会帮助攻击者更快理解漏洞。它会提升防守效率，也会压缩响应窗口。它会让更多历史问题浮出水面，也会让企业暴露出资产不清、依赖不明、补丁缓慢、验证不足的问题。

未来的软件安全，可能会进入一个新阶段：

漏洞发现更快。 漏洞披露更密。 补丁分析更容易。 攻击复现周期更短。 企业响应压力更大。

对安全团队来说，真正重要的不是恐慌，而是建立能力。

能不能快速知道自己用了哪些组件。 能不能判断漏洞是否影响真实业务。 能不能及时升级和验证。 能不能在无法升级时给出临时缓解。 能不能把 AI 变成自己的安全工具，而不是只让攻击者使用它。

AI 辅助漏洞挖掘进入主流，意味着安全攻防的速度正在变快。

在这个阶段，谁能更快识别资产、更快理解漏洞、更快完成修复，谁就能在新的攻防节奏中占据主动。

参考来源

1. OpenSSL Security Advisory：OpenSSL Security Advisory [9th June 2026]
2. OpenSSL Release and Advisory Timeline
3. SecurityWeek：OpenSSL Patches High-Severity Vulnerability Found With AI
4. AISLE：AISLE Discovered 12 out of 12 OpenSSL Vulnerabilities
5. AISLE：AISLE Uncovered 5 of 7 OpenSSL Vulnerabilities in the April 2026 Release
6. TechRadar：AI-assisted cybersecurity team discovers mass of OpenSSL vulnerabilities

---

免责声明：

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

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

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

本文转载自：NowSec JacobWang JacobWang《AI 辅助漏洞挖掘进入主流：OpenSSL 漏洞修复背后的新变量》