本文内容
2026年8月5日,由 Lidor Ben Shitrit 带领的 Novee 研究人员在 Black Hat USA 上发表了一项研究,披露了四个企业级 Java 平台中的十二个漏洞,其中包括两条严重的漏洞链,可以在完全无需登录的情况下在服务器上执行代码,分别位于 Bonita BPM 工作流平台和开源 ERP 系统 Apache OFBiz 中。对任何企业主来说,实际的启示是:你以为因为是内部系统所以受到保护的系统,如果暴露在外且未打补丁,只需两个浏览器请求就能被攻破。真正的防护始于清点你所运行的系统并建立打补丁的例行机制,而不是信任网络边界。
研究人员究竟发现了什么
这项研究并非建立在某个惊人的单一漏洞之上,而是通过组合中间件中常见的小错误构建而成:URL 解析方式上的差异、请求处理层上不完整的防护、硬编码在源代码中的加密密钥,以及不安全的模板求值。单独来看,这些问题都不显得危险,而这正是它们能逃过代码审查、被归入低优先级的原因。把它们串联起来,就形成了一条从匿名访问者到在服务器上执行命令的完整路径。在这十二个漏洞中,有四个在身份验证之前即可利用,另有一个能突破执行沙箱内部的隔离。
BadBonita 漏洞链:三个薄弱点造成一次完全攻陷
第一条漏洞链影响 Bonita BPM 10.4.3 版本。它始于一个由三个相互关联的弱点构成的身份验证绕过:使用 ..; 写法的路径遍历、按子字符串而非完整路径进行匹配的安全过滤器,以及内部请求转发逻辑。其结果是,一个请求到达了本不应被外部任何人看到的内部 API。该 API 接受不可信的 XML,并将其直接交给 XStream 库进行反序列化,再通过一条广为人知的 Commons Collections 利用链,最终在服务器上执行 Groovy 命令。
请注意,这些步骤都不需要泄露的密码、社会工程手段或事先的访问权限。攻击者唯一需要的,就是系统可以通过网络访问。
OFBiz:签名密钥发布在公开代码库中
第二个问题编号为 CVE-2026-31986,被评为严重级别,影响启用了单点登录的 Apache OFBiz 24.09.05 版本。问题在于,默认签名密钥就存放在公开发布的源代码中,而由于许多安装都保留默认设置不变,攻击者可以以管理员账号的名义伪造有效的 SSO 令牌。之后,请求会经过一个试图拦截 java、process 和 import 等词语的拒绝列表,但该列表区分大小写且只检查特定模式,因此只需改变某个字母的大小写,或使用另一个自动导入的类名,就足以绕过。最终结果是:在任何运行 SSO 的安装上,两个未经认证的 GET 请求就足以实现代码执行。
为什么这件事与你密切相关
因为这两者都不是边缘工具。OFBiz 是一款开源 ERP,许多公司用它来管理库存、采购和开票;Bonita 是一个工作流引擎,驱动着内部审批和流程。进入这两个地方的人不仅仅是在读取数据,而是站在了你运营流程的正中央:采购订单、供应商报价、员工档案、客户历史。研究人员报告称,两家厂商都在标准的九十天披露期限内发布了修复版本,这意味着更新已经存在,责任如今落在系统的运营者身上,而不是开发者身上。
市场上真正的缺口不是缺少补丁,而是缺少资产清单。许多机构没有一份最新的清单,记录他们实际运行了什么、是哪个版本、部署在哪个域名上。于是,一个旧的测试环境副本在某个被遗忘的子域名上挂了两年,成了没人想到的那扇门。
本周应该做什么
- 清点你的系统:一份书面清单,列出你运行的每个系统、其版本、是否暴露在互联网上,以及具体负责人的姓名。
- 如果你在运行 Bonita 或 OFBiz,请立即升级到已修复的版本,并在升级前阅读 Apache 官方安全页面。
- 替换产品出厂时附带的所有默认加密或签名密钥。任何印在文档中的值都不是秘密。
- 对开放互联网关闭管理入口,改为通过专用网络或一份简短的地址白名单来访问。
- 下线旧的测试环境副本和不再使用的子域名。它们是最容易攻击、也最缺乏监控的目标。
- 开启访问日志并加以保留。没有日志,你日后将无法回答到底有没有人进入过系统。
工程上的教训:内部网络不是安全边界
这项研究得出的最重要建议是:内部路由应当以互联网级别的控制措施来对待。“防火墙后面的一切都是安全的”这一旧观念在实践中已经失败:一个身份验证绕过漏洞就能把每个内部接口变成公开接口。由此引出三条工程规则,它们应当写进你的开发标准:
永远不要依赖拒绝列表来保护危险操作。如果某条代码路径并不需要表达式求值,就彻底移除它,而不是试图对它进行过滤。
第二条规则是,永远不要让敏感操作取决于可以在系统内部更改的配置开关或用户偏好。第三条是审查身份验证过滤器逻辑中的任何子字符串匹配,因为这是此类问题中最常见、也最容易被利用的错误。在 Origami 构建新的企业系统时,我们默认就遵循这些原则:每个接口都进行明确授权,并且不会因为请求在网络中的位置而给予信任。
沙特阿拉伯的监管角度
如果被攻陷的系统中保存着沙特王国境内个人的个人数据,这就不再只是技术问题。《个人数据保护法》(PDPL)要求数据控制者采取必要措施保护这些数据,并报告影响其隐私的事件。国家网络安全局(NCA)发布了涵盖漏洞管理、补丁管理和资产管理的基本控制措施,而这些恰恰是本可以阻断这条漏洞链的控制措施。运行一个存在已知且已修补漏洞的旧版本产品,在任何审计中都是难以辩护的立场。
简单的规则:把安全更新视为每月一次、有负责人、有日期的运营承诺,而不是事故发生后才执行的紧急任务。
参考来源
- Help Net Security:无需认证的 RCE 漏洞链及 CVE-2026-31986 详情:helpnetsecurity.com
- Apache OFBiz 官方安全页面:ofbiz.apache.org/security.html
- 国家网络安全局(NCA):控制措施与监管框架:nca.gov.sa
- 沙特数据与人工智能管理局(SDAIA):《个人数据保护法》(PDPL):sdaia.gov.sa
常见问题
我的公司是否受到这些漏洞的影响?
如果你运行的是 Bonita BPM 10.4.3 或更早版本,或者启用了单点登录的 Apache OFBiz 24.09.05 或更早版本,并且系统可以通过网络访问,那么你就面临风险。请核实你实际运行的版本,而不是合同或交接文件中写的版本,然后升级到已修复的版本。
我们的系统是内部系统,没有发布到互联网上,我们安全吗?
不一定。这项研究的核心观点是:一个身份验证绕过漏洞就能把任何内部接口变成开放接口,而网络中的一台受感染设备或一个泄露的员工账号就足以触及它。请以同等级别保护内部系统:明确的授权、非默认的密钥以及定期更新。
我至少应该向系统供应商提出哪些要求?
书面要求三件事:你的系统所依赖的组件及其版本清单;一份安全更新政策,其中规定针对严重漏洞的明确响应时间;以及一份定期报告,证明更新确实已经应用。把这些条款写进技术支持与维护合同,而不是留在电子邮件往来中。
开源软件是否比闭源软件更不安全?
不是。区别在于,开源软件的漏洞会连同补丁一起公开披露,因此你能看到并采取行动,而闭源软件的漏洞则取决于供应商的时间表。两种情况下真正的风险完全相同:在已有更新的情况下仍运行旧版本。只有当你把开源软件的默认密钥和设置原封不动地保留为出厂状态时,它才会变得更危险。
在 Google 上关注 Origami
把 Origami 设为首选来源,我们的文章就会优先出现在您的 Google 搜索和热门新闻中。








