一场说不清楚的数据泄露
2025 年初，一个化名“rose87168”的黑客在暗网上挂出了一批数据，声称是从 Oracle 云基础设施里盗取的。据称被盗的数据包括加密的 SSO 密码、JKS 文件、企业管理器 JPS 密钥以及 LDAP 系统相关的用户凭据，涉及约 600 万用户记录，可能波及超过 14 万租户。
尽管 Oracle 坚称被盗的凭证并非来自 Oracle Cloud，没有任何客户遭遇数据泄露或损失。但网络安全公司 CloudSEK 发现，截止 2025 年 2 月，涉事服务器运行的是 Oracle Fusion Middleware 11g 版本，这个版本曾受漏洞 CVE-2021-35587 影响，允许未经身份验证的攻击者直接攻破 Oracle Access Manager。事件曝光后，Oracle 迅速将这台服务器下线，似乎在无声中承认了问题的存在。
从季度补丁到每月修复，Oracle 做了什么
不管这场数据泄露的风波最终如何定性，所暴露出来的问题迫使 Oracle 不得不有所行动。2026 年 4 月，Oracle 安全博客发布了一篇题为 https://blogs.oracle.com/security/accelerating-vulnerability-detection-and-response-at-oracle 的文章，宣布了几项重要变化。
最具实质意义的一项，是补丁发布机制的调整。Oracle 宣布从 2026 年 5 月起推出月度关键安全补丁更新 (CSPU)，专门针对高优先级漏洞提供定向修复，允许客户在不等待季度发布的情况下快速应对严重安全问题。每个 CSPU 更小、更聚焦，便于快速应用。季度关键补丁更新将继续涵盖此前所有 CSPU 中发布的修复内容。
此外，Oracle 也在重申云端与本地部署之间的安全责任差异：在 Oracle 托管的云服务中，漏洞修复是持续进行的，客户无需自己操心；而对于客户自管理的本地部署，Oracle 提供补丁，但打补丁的责任仍在客户一侧。
一个结构性的老问题
Oracle 的困境并非孤例，而是整个企业软件行业长期存在的顽疾。
厂商发布补丁，客户需要评估、测试、计划停机时间、协调各个组件依赖，才能完成更新。对于大型企业来说，一次数据库补丁更新可能需要几个月的准备工作。结果就是，补丁已经发布了，但现网环境里依然跑着几年前的旧版本。这是行业共识，也是攻击者最清楚的事实。
CVE-2021-35587 这个漏洞，早在 2021 年就发布了，安全公告一遍遍重申它的风险等级，工具扫描持续的告警，但服务器就是没打补丁，直到出事。这也不是单纯的技术问题，是组织和流程上的问题。
每季度发布补丁，设计之初是为了给大型企业足够的评估和部署时间。这个节奏在二十年前有其合理性，但今天的攻击节奏已经发生了很大的变化，一个高危漏洞可能几天时间就会被大规模利用。季度补丁意味着，在最坏的情况下，一个企业可能需要等待近三个月才能拿到官方修复，而这三个月里，漏洞细节早已成了公开信息。
对软件行业的几点启示
Oracle 的调整，指向了几个值得整个行业认真对待的方向。
**补丁机制需要重新设计，而不只是提速。**从季度到月度，是节奏上的改变，但根本问题在于，如果降低打补丁的成本。如果打一个补丁仍然需要数周的测试和协调，那缩短发布周期并不能真正缩短风险暴露窗口。理想的方向是让补丁更小、更精准、影响范围更可预测，这也是 Oracle 的调整方向。
**AI 用于安全扫描，价值在于规模和速度，但不能替代流程。**用 AI 模型扫描代码库、识别潜在漏洞，这件事并不新鲜，但前沿大模型的加入确实提高了发现复杂漏洞模式的能力。不过，技术上的加速只有在整个响应流程都足够敏捷的前提下才有意义，发现漏洞更快，但修复和部署依然慢，没有任何实际意义。
**遗留系统是最大的风险。**Oracle 的案例再次说明，一个几年前的已知漏洞，完全可能成为今天重大事件的入口。企业往往在新系统上投入大量资源，却对遗留系统的版本现状缺乏清晰的掌控。系统性的资源梳理和版本升级更新计划，虽然会有一定的资源投入，还是非常有必要的。
写在最后
软件安全没有终点，只有不断收窄的风险暴露窗口。Oracle 的这次调整，是在压力下被迫做出的，但是代表了未来的方向。真正的问题是，行业内有多少公司愿意在自己的服务器还没有被攻破前，就开始认真对待那些已经躺在漏洞库里多年的“旧账”？
