Siemens Mendix SAML 修复高严重性账户劫持漏洞

研究人员发现一条可导致账户劫持的攻击路径后，Siemens Mendix SAML 发布了紧急安全更新，该漏洞的 CVSS v3.1 评分为 8.7。该漏洞影响特定单点登录配置，攻击者无需预先拥有账户权限。

该漏洞编号为 CVE-2026-80465，存在于 Mendix SAML 模块中，而非更广泛的 SAML 标准本身。易受攻击的应用可能未能正确验证响应签名，从而削弱了连接身份提供商与用户会话的信任判定。

这一差异决定了实际风险。Microsoft Entra ID、Okta、Auth0、Ping、Keycloak 及其他身份提供商可能会签发合法响应。然而，易受攻击的 Mendix 模块在特定配置下处理响应时可能错误地完成验证。

Siemens 于 2026 年 9 月 3 日发布安全公告。CISA 随后针对关键制造业和信息技术环境中的组织重点提示了该问题。两份通知均建议客户升级至已修复的模块版本，而非采用仅靠配置的缓解措施。

眼下的行动很明确。Mendix 10 和 Mendix 11 应用应使用 SAML 模块 4.2.3 或更高版本。使用 Mendix 9.24 的应用则应升级至 3.6.27 或更高版本。

更困难的是运营层面的工作。团队必须找出每一个嵌入受影响模块的应用，确认其已部署版本，审查其 SSO 配置，并判断是否需要调查现有会话。

Siemens Mendix SAML 有何变化

此次安全更新修复了一个签名验证缺口；该缺口可能让伪造或被不当信任的 SAML 响应转化为已认证的应用会话。

SAML 响应是身份提供商在完成身份验证后发送的 XML 消息。它可包含用于识别用户，以及描述与该身份关联的属性或角色的断言。

接收该响应的应用充当服务提供商。它必须验证响应来自预期的身份提供商，并确认受保护内容未被篡改。

数字签名提供这一完整性检查。服务提供商会在接受身份声明前，使用受信任证书验证签名。

在受影响版本中，CVE-2026-80465 打破了这一预期的信任链。根据 Siemens 公告，该模块在特定配置下未能正确验证 SAML 响应签名。

Siemens 表示，若满足这些条件，未经身份验证的远程攻击者可能劫持账户会话。该公司尚未公开完整攻击过程，因此无法安全地复现相关技术细节。

受影响版本的界限非常明确：

• Mendix 10 的 Mendix SAML 在 4.2.3 之前的版本受影响。

• Mendix 11 的 Mendix SAML 在 4.2.3 之前的版本受影响。

• Mendix 9.24 的 Mendix SAML 在 3.6.27 之前的版本受影响。

Siemens 为该问题评定的 CVSS v3.1 基础分数为 8.7，CVSS v4.0 分数为 8.8。两项评分均处于高严重性范围。

v3.1 向量表明，该攻击可通过网络实施，不要求权限，也不需要用户直接交互。它还对机密性和完整性赋予了高潜在影响评级。

不过，攻击复杂度被评为高。这一评级很重要，因为该漏洞仅适用于特定 SSO 配置，并未被描述为通用的登录绕过漏洞。

v4.0 向量增加了已存在的攻击要求，并将用户交互归类为被动。这些细节表明，利用该漏洞取决于环境或协议条件，不能仅凭能够访问应用就完成攻击。

这并不意味着可以忽视该问题。能够满足这些条件的攻击者可瞄准身份验证边界，而一次验证错误就可能带来广泛后果。

Mendix 的模块发行说明将 4.2.3 描述为针对账户劫持漏洞的安全加固。其强烈建议使用 SAML 身份验证的客户升级。

该版本还直接标明了 CVE-2026-80465。这消除了常规模块更新是否包含相关修复的不确定性。

该警报涉及安装在 Mendix 应用内部的可复用 SAML 组件。这并不意味着所有使用 Mendix 构建的应用都存在漏洞。

暴露程度取决于实际被打包和部署的模块版本，也取决于应用是否使用了受影响的 SAML 响应处理路径。

这构成了本文的核心张力。SSO 集中化了身份决策，但依赖该身份的应用仍必须正确验证每一条身份消息。

受信任的身份提供商无法弥补接收应用内部存在的验证缺陷。最后一步验证仍属于应用安全边界的一部分。

为什么签名验证会成为账户问题

加密签名只有在应用使用正确的受信任密钥验证正确对象时才有价值。

SAML 允许身份提供商向应用声明某一用户已完成身份验证。这种委托减少了独立密码的需求，但也将信任集中在已签名的协议消息中。

典型流程始于用户打开 Mendix 应用。应用将浏览器重定向至身份提供商，后者验证用户身份并返回 SAML 响应。

该响应可包含已签名的断言、已签名的外层响应，或两者兼有。具体模式取决于身份提供商和服务提供商的配置。

随后，Mendix 模块会将已接受的身份映射至应用账户。根据配置，它还可创建新用户，或分配从受信任属性派生的角色。

最后的映射步骤说明，签名验证并非抽象的密码学问题。若验证结果错误，应用就可能将攻击者控制的流程关联到合法身份。

MITRE 将底层弱点归类为 CWE-347，即未正确验证加密签名。该类别涵盖未能正确验证已签名数据或执行不完整检查的软件。

常见后果包括冒用他人身份、修改应用数据，以及获取敏感信息访问权限。具体结果仍取决于目标账户所拥有的权限。

普通账户可能暴露个人或运营数据。管理员账户则可能使攻击者获得应用层控制权，包括访问特权工作流。

Siemens 的评分反映了这种影响范围。在 v3.1 评估中，机密性和完整性获得高影响评级，而可用性未被评定为存在直接影响。

从实际角度看，核心风险是未经授权的访问和操作。公告未将服务中断描述为主要后果。

Mendix 文档指出，受支持的模块版本可以要求 SAML 断言已签名。它还支持签名继承，即已签名的响应可保护其中未签名的断言。

这种灵活性存在的原因是，不同身份平台以不同方式实现 SAML。一家提供商可能对响应签名，另一家则可能对每个断言签名。

模块必须确定哪一个签名保护了正在使用的身份数据，还必须确认该签名属于已配置的身份提供商。

正是在这里，实现细节变得与安全息息相关。检查签名是否存在，并不等同于证明其覆盖了稍后用于登录的身份断言。

同样，成功解析 XML 文档并不能证明其真实性。加密可以隐藏消息内容，但不能取代正确的签名验证。

公开公告并未说明是哪一条验证分支发生故障，也未说明问题是否涉及签名范围、继承、证书选择或其他处理条件。

读者不应将这些可能性当作既定事实。经验证的事实更为有限：受影响版本会在特定 SSO 配置下不当验证 SAML 响应签名。

在客户完成修补前，这种有限披露是合理的。它降低了防御指导成为现成攻击指南的可能性。

这也意味着防御者不应等待公开的概念验证。供应商已确认该弱点、评定其为高严重性，并发布了修复版本。

配置灵活性遇上严格的信任边界

核心冲突在于灵活的 SSO 互操作性，与应用在创建受信任会话前必须执行的严格验证之间。

企业 SSO 环境很少采用单一通用的消息模式。组织会组合不同身份提供商、证书、绑定方式、断言格式和账户配置规则。

Mendix SAML 模块支持 Microsoft Entra ID、Okta、Auth0、Ping、AWS IAM Identity Center、ForgeRock 和 Keycloak 等常见身份服务。它还支持基于 Shibboleth 和欧洲 eID 方案的提供商。

这种广泛支持有助于低代码团队将应用连接至现有身份基础设施，但也增加了安全敏感代码必须正确处理的配置路径数量。

Mendix 默认支持 HTTP POST 绑定。它还在兼容版本中支持工件绑定，在这种模式下，应用通过单独交换获取 SAML 消息。

该模块可以请求用户属性、映射主体标识符、分配角色，以及自动创建用户。每项功能都依赖应用对已验证身份的信任。

根据 SAML 配置指南，模块的加密设置还控制签名行为。Mendix 默认启用该保护，并不建议在 POST 绑定中将其禁用。

启用保护后，消息会被加密和签名。导出的服务提供商元数据表明，身份验证请求已签名，并且断言应当已签名。

文档指出，签名不当的断言应被拒绝。它也允许断言从已签名响应中继承保护。

这种继承模型本身是合法的，但要求精确验证。软件必须将受信任签名关联到用于授权的确切数据。

该漏洞说明，配置灵活性不能削弱这种关联。支持多种有效的 SAML 布局需要多个处理分支，但每个分支都必须安全地得出相同的信任结论。

身份提供商并非此次事件中的问题所在。该公告未指出 Entra ID、Okta、Keycloak 或其他提供商存在漏洞。

问题存在于接收方 Mendix 模块的受影响版本中。更换身份提供商无法修复易受攻击的服务提供商代码。

Mendix 还提供 OpenID Connect SSO 模块。其文档将 OIDC 描述为更易于用于和定制的新部署方案。

OIDC 使用不同的令牌格式和验证规则，因此 CVE-2026-80465 不会自动影响该模块。不过，对于暴露风险的 SAML 应用而言，迁移并非当下的补救措施。

仓促的协议迁移可能引入新的身份映射和授权错误。更新受影响的 SAML 模块才是直接且受厂商支持的应对措施。

在实现身份验证现代化时，架构团队可以单独评估 OIDC。该决策应考虑身份提供商支持、应用兼容性、声明映射以及运维责任归属。

当前事件则应促使人们提出一个更聚焦的问题：组织能否可靠地盘点并更新其 Mendix 产品组合中的可复用身份验证模块？

低代码开发可能将应用所有权分散到各业务团队。中央身份团队可能负责配置 SSO，平台团队负责管理运行时版本，而应用团队则选择 Marketplace 模块。

这种分工可能模糊补丁责任。平台运行时升级并不一定会更新嵌入应用中的每一个第三方或 Marketplace 模块。

反过来，在开发项目中变更模块也无法保护生产环境，除非应用经过重新构建、测试和重新部署。

因此，组织需要建立应用级清单。其中应记录 Mendix 运行时、SAML 模块版本、身份提供商、部署环境以及责任所有者。

这对于暴露管理工作流、客户记录、制造数据或员工信息的应用尤为重要。在这些场景中，账户接管造成的业务影响各不相同。

即使部署工作流很便利，身份边界也应保持严格。灵活性应体现在配置中，而真实性校验必须不可妥协。

谁必须采取行动，以及更新需要什么

每个运行受影响版本的团队都应将修复后的模块视为基准，并确认已修正的版本已覆盖每一个已部署应用。

对于 Mendix 10 和 Mendix 11，修复版本下限为 4.2.3。对于 Mendix 9.24，修复版本下限为 3.6.27。

团队应从已部署的生产应用入手，而不应只检查源项目。代码仓库可能显示依赖项已修正，但较旧的应用包仍可能在为用户提供服务。

第一步是识别使用基于 SAML 身份验证的应用。团队应将它们与使用本地身份验证、OIDC 或其他 SSO 实现的应用区分开来。

接下来，确认每个应用安装的模块版本。不要根据 Mendix 运行时版本或平台范围的软件清单进行推断。

受影响的对象是 SAML 模块。应用可以运行受支持的 Mendix 运行时，同时仍携带较旧版本的模块。

应用所有者随后应在升级前审查兼容性指南。Mendix 会针对特定的运行时和 Atlas UI 组合发布不同的模块分支。

Marketplace 发布信息显示，版本 4.2.3 的框架版本为 Mendix 10.21.1。运行其他受支持分支的团队应验证正确的升级路径，而不是强行使用不兼容的软件包。

Mendix 9.24 用户则对应自己的修复分支 3.6.27。这一区分可避免安全响应演变为计划外的运行时迁移。

更新后，团队应通过其常规受控流程重新构建并重新部署应用。身份验证变更值得进行重点测试，因为登录失败可能影响每一位用户。

测试应涵盖成功登录、拒绝无效响应、角色映射、现有用户匹配，以及在启用时创建用户。使用多个身份提供商的应用应测试每一个已配置的提供商。

团队还应测试注销行为和会话续期。该通告涉及账户会话，因此验证不应止步于登录后能否进入首页。

使用自定义预配逻辑的应用需要额外关注。SAML 模块可能会将已通过身份验证的用户传入应用特定工作流，这些工作流会修改用户资料、角色或相关记录。

正确的签名校验可以保护最初的身份判定。身份验证完成后，自定义逻辑仍必须执行自身的授权规则。

水平扩展的应用还存在另一项运维考量。Mendix 文档指出，在某些部署中，配置变更不会自动传播到所有实例。

模块更新通常需要一次新的部署，但团队仍应确认每个正在运行的实例都使用同一个应用包。混合版本可能导致部分暴露仍然存在。

安全团队应在常规保留策略清除前保存相关身份验证日志。有用的记录包括 SSO 失败、异常账户活动、不寻常的角色变更，以及来自陌生来源的会话。

公开通告并未报告已确认的利用行为，也未表示现有客户已经遭到入侵。

这种缺失应影响调查用语。团队可以搜寻异常情况，但不能仅因发现受影响版本就宣布发生了事件。

如发现可疑活动，调查人员应将 Mendix 应用日志与身份提供商记录关联。一次合法的身份提供商登录，应在预期时间存在对应事件。

缺少预期上游身份验证证据的 Mendix 会话值得进一步审查。不过，日志缺失和保留期限差异可能使这种比对变得复杂。

组织应按账户权限和数据敏感性对应用进行优先级排序。面向互联网的管理应用应比隔离的测试环境更快得到处置。

CISA 的 ICS 安全通告将该问题置于关键制造业和信息技术背景之中。这种表述并不意味着该漏洞可直接控制工业设备。

Mendix 应用可支持工业环境周边的运营、管理和数据工作流。因此，遭入侵的账户可能影响重要业务流程，而无需直接利用控制器。

网络限制可以降低暴露程度，但不能替代更新。Siemens 将受保护的网络访问列为一般性安全措施，而针对该产品的修复措施仍是版本升级。

团队不应只依赖 Web 应用防火墙。该弱点涉及应用对协议响应作出的信任判定，而此类流量可能看起来与预期的 SSO 流量无异。

除非组织有证据表明发生了单独的密钥泄露，否则仅轮换证书同样不足以解决问题。CVE-2026-80465 涉及模块中的验证行为。

最后，所有者应记录已部署的修复。安全工单应包含旧版本、新版本、部署时间、已测试的身份提供商，以及任何调查发现。

当审计人员或事件响应人员询问特定应用在披露后是否仍处于暴露状态时，这份记录将极具价值。

该通告未能证明什么

该漏洞很严重，但公开证据并不支持“普遍暴露”“正在被利用”或“SAML 标准已遭破坏”等说法。

“特定 SSO 配置”这一表述是重要边界。Siemens 尚未公布使安装实例可被利用的完整条件清单。

假定禁用加密、响应签名、断言签名或某个特定身份提供商定义了易受攻击条件，都是不安全的。该通告并未确立这些细节。

较高的攻击复杂度评级表明，利用需要准备工作或环境知识。但这并不能证明攻击不具可行性。

一旦满足必要条件，未经身份验证的攻击者仍可远程操作。根据 CVSS v3.1 评估，不需要任何账户权限。

该评分也不描述任何单个应用的业务重要性。CVSS 在标准化假设下衡量技术严重性。

客户门户和工厂维护应用可能使用同一个易受攻击组件，但造成的后果可能截然不同。本地权限、数据访问权限和工作流授权决定最终影响。

同样没有公开证据表明，每个 SAML 响应都会在未经过验证的情况下被接受。厂商描述的是验证不当，而不是完全移除所有签名检查。

这种区分对于准确报道至关重要。关于“加密已失效”或“所有 SAML 登录”的泛化说法都会超出已知事实。

该问题也不是身份提供商密码身份验证的弱点。当接收应用错误处理受信任的身份消息时，攻击者不一定需要窃取用户密码。

身份提供商侧的多因素身份验证仍然很有价值。不过，它无法纠正服务提供商在交换流程末端错误接受响应的问题。

这并不意味着多因素身份验证毫无用处。它保护正常登录路径，并有助于降低其他形式的账户入侵风险。

该事件反而说明了分层责任。身份提供商负责对用户进行身份验证，而应用必须验证令牌并实施授权。

组织也应避免将成功升级视为没有发生任何入侵的完整证明。修补会移除已知的易受攻击行为，但不会审查此前的会话。

与此同时，发现旧模块版本并不能证明已被利用。调查应保持证据驱动，并避免夸大上游身份验证日志中的缺口。

公开的利用信息可能改变风险评估。可靠的概念验证会减少对前置条件的不确定性，并使暴露测试更加紧迫。

有证据显示存在主动利用会进一步提高优先级。截至该通告发布时，此处审阅的官方通告未报告此类活动。

因此，最稳妥的立场应当审慎且直接。该漏洞已获厂商确认，严重性高，可远程触及，已有修复版本，并可能对账户造成严重影响。

这些事实足以证明应迅速采取行动，无需提出推测性说法。面对已有受支持修复措施的身份验证漏洞，防御者不需要一个耸人听闻的场景来确定优先级。

Siemens Mendix SAML 修复后需关注的三个信号

下一阶段将取决于升级覆盖率、更多技术披露，以及攻击者是否在组织完成修补前利用该漏洞的任何证据。

第一个信号是生产应用对版本 4.2.3 和 3.6.27 的采用情况。这比下载量更难衡量，因为下载模块不等于模块已部署。

内部平台团队应跟踪已知 SAML 应用中运行修复版本的百分比，也应跟踪所有权未知或部署状态未确认的应用。

快速采用将强化一种判断：厂商提供的直接修复措施在运维上可控。庞大的兼容性积压则会表明，分布式低代码所有权增加了补丁延迟。

第二个信号是 Siemens 或 CISA 通告的修订。更新可能添加受影响条件、检测指南、致谢信息，或对利用活动作出澄清。

更多配置细节将帮助团队缩小回溯调查范围，也可能识别出除版本检查外需要优先处理的应用。

防御者应监控通告历史，而不是依赖被复制的摘要。厂商发布更正后，二级漏洞数据库可能仍保留早期措辞。

第三个信号是可信的在野利用证据。这包括被纳入 CISA 的已知遭利用漏洞目录、供应商发布的事件更新，或事件响应人员经验证的报告。

此类证据将进一步支持扩大会话失效范围并开展更深入的取证审查。即使没有这类证据，仍然需要修补漏洞，但调查范围会因此有所不同。

组织还应关注解释签名验证路径的技术分析文章。它们有助于改进防御测试，但未经验证的演示不应取代供应商的指导意见。

眼下即可作出实际行动决策：盘点 Mendix 应用，确认其 SAML 模块版本，升级受影响的版本，重新部署，并测试每个已配置的身份提供商。

随后应问：你的组织能否快速重复这一流程？哪个团队负责可复用的身份验证模块？又如何证明已修复的组件确实已进入生产环境？

Siemens Mendix SAML 不会是最后一个需要紧急更新的共享身份组件。持久的经验教训是，应将应用层 SSO 模块视为安全基础设施，并配备相应的资产清单和部署证据。