OpenSSL 7个漏洞连环爆：RSA加密失败却骗过系统

4月8日，OpenSSL一口气放出7个安全补丁。最扎眼的是CVE-2026-31790——一个"加密失败却假装成功"的逻辑漏洞，能让攻击者从内存里捞出前任用户留下的敏感数据。

这不是什么边缘场景。受影响的是3.0到3.6全系列，连过FIPS认证的政务、金融系统也躺枪。OpenSSL官方给的修复方案是：要么升级版本，要么在调用封装接口前强制校验公钥。

一个负号引发的灾难

问题出在RSA KEM的RSASVE封装流程。开发者调用EVP_PKEY_encapsulate()时，底层会执行RSA_public_encrypt()。这个函数的设计很老派：成功返回密文长度，失败返回-1。

但OpenSSL的封装代码只判断了"是否非零"。-1是非零，所以加密失败时，系统误以为成功了。更糟的是，API还会正常设置输出长度、返回控制权，把根本没初始化的缓冲区当成有效密文交给调用方。

这个缓冲区里可能残留着上一轮计算的密钥碎片、用户会话数据，甚至是其他进程的内存痕迹。攻击者只要提供一个伪造的RSA公钥，就能诱导服务器把"内存快照"打包发送过来。

OpenSSL安全公告里的描述很克制：「uninitialized memory exposure」。但懂行的人知道， uninitialized memory在实战里往往等于可提取的敏感信息。

为什么你的代码可能中招

漏洞的触发条件听起来很苛刻：需要应用接受攻击者提供的公钥，且不做前置校验。但现实是，很多KEM（密钥封装机制，Key Encapsulation Mechanism）场景就是这么设计的。

典型的例子是匿名密钥交换。客户端连上来，服务端用对方公钥封装一个对称密钥发回去。如果代码里没显式调用EVP_PKEY_public_check()，就等于把内存的钥匙交给了陌生人。

OpenSSL的缓解建议很明确：在EVP_PKEY_encapsulate()之前，先跑一遍EVP_PKEY_public_check()或EVP_PKEY_public_check_quick()。这会把RSA公钥的数学有效性验证一遍，伪造的密钥会直接被拒绝。

但这里有个坑。很多开发者以为"封装失败"和"返回错误"是一回事。CVE-2026-31790证明，在OpenSSL 3.x的RSASVE实现里，这两件事可以彻底脱钩。

换句话说，你的异常处理代码可能从来没被执行过，因为底层根本没报错。

另外6个"低危"漏洞也不省心

除了C位出道的RSASVE漏洞，这次补丁还修了6个低危问题。它们单独看都不算致命，但凑在一起暴露了OpenSSL在边界处理和遗留代码上的债务。

CVE-2026-28386是AES-CFB-128在x86-64 AVX-512/VAES指令集下的越界读取。触发需要特定硬件和模式组合，但一旦命中，就是内核态的内存泄露。

CVE-2026-28387藏在DANE（基于DNS的实体认证，DNS-based Authentication of Named Entities）客户端的罕见配置里，是个释放后使用（use-after-free）。DANE本身部署率不高，但邮件服务器和DNSSEC重度用户得盯紧。

CVE-2026-28388和CVE-2026-28389/28390 trio都是空指针解引用，分别位于Delta CRL处理和CMS（加密消息语法，Cryptographic Message Syntax）的密钥协商/传输流程。这三个主要导致拒绝服务，但配合其他漏洞可能升级利用。

最复古的是CVE-2026-31789：32位平台上，超大OCTET STRING的十六进制转换会堆溢出。2026年还在维护32位代码路径的，大概只有嵌入式和某些工控场景了。

OpenSSL的版本矩阵已经更新。3.0.x用户跳3.0.20，3.3.x跳3.3.7，3.4.x跳3.4.5，3.5.x跳3.5.6，3.6.x跳3.6.2。FIPS模块用户注意：3.6、3.5、3.4、3.3、3.1、3.0的认证版本全部受影响。

修复之外：KEM API的设计教训

这次漏洞的核心矛盾，是OpenSSL 3.x引入的KEM抽象层与遗留RSA实现的摩擦。EVP_PKEY_encapsulate()被设计成算法无关的统一接口，但RSASVE的底层还是那套1990年代的RSA_public_encrypt()。

统一接口的好处是开发者不用关心底层算法。代价是，当底层返回-1这种"老派错误码"时，封装层可能理解错语义。这不是第一次了。2023年的CVE-2023-4807也是类似的返回码处理失误，导致ECDSA签名验证绕过。

一个观察：OpenSSL的FIPS模块这次同步受影响，说明问题出在核心算法实现，而不是可选组件。对于需要通过合规审计的系统，这意味着紧急补丁可能触发重新认证流程——不是简单apt upgrade就能解决的。

云厂商的动作很快。AWS在公告发布后24小时内更新了ACM和KMS的OpenSSL依赖。Azure和GCP的托管服务状态页也陆续变绿。但自托管服务的用户得自己盯版本号，尤其是那些在K8s里跑sidecar做mTLS的——镜像底层可能藏着3.5.x的漏洞版本。

GitHub的依赖扫描已经开始标记受影响的仓库。一个值得注意的细节：很多项目明明没直接调用RSASVE，但因为链接了OpenSSL 3.x，也被扫了出来。这是静态分析的误报，但也说明SBOM（软件物料清单）的粒度还不够细。

最后提一个修复后的实测发现。OpenSSL 3.6.2在RSASVE流程里加了显式的返回值检查，但错误提示还是原来的"encapsulation failed"。开发者调试时可能 still 分不清是密钥问题、内存问题，还是这个已经被修掉的逻辑bug——日志的颗粒度没跟上代码的修复。