MZ Automation lib60870 因远程崩溃漏洞面临 CISA 网络安全警告

研究人员发现，一条格式错误的消息即可使存在漏洞的 lib60870 解析进程崩溃，MZ Automation 因此面临 CISA 网络安全警告。该漏洞影响截至 2.4.0 版本的 lib60870，编号为 CVE-2026-16002。2.4.1 版本已包含修复。

该漏洞位于工业控制环境中用于处理 IEC 60870-5 通信的软件内。这类通信可连接控制中心、变电站、远程终端单元及其他运营技术系统。因此，解析器故障的影响不同于普通应用程序崩溃。

核心矛盾在于，代码范围很小，运营后果却可能很广。存在问题的解码器仅处理一种专用消息类型，但受影响的库支持能源、化工、供水和污水处理基础设施中使用的通信。CISA 称该产品已在全球部署。

这并非已被证实可接管工业设备的漏洞。研究人员观察到的是越界读取及拒绝服务结果，而非任意代码执行。不过，一旦构造的帧抵达暴露的解析器，具备网络可达性的攻击者无需账户或用户交互。

眼下的应对措施很明确：识别 lib60870 部署，确定其是否处理受影响的消息类型，并升级至 2.4.1 或更高版本。更困难的任务是找出每一个嵌入式副本，并在无法承受随意停机的运营系统中安全实施变更。

CISA 网络安全公告带来的变化

CISA 将一个解析器缺陷转化为在运营环境中运行 lib60870 的组织必须面对的具体资产管理期限。

CISA 网络安全公告指出，MZ Automation lib60870 存在越界读取漏洞。这种内存安全错误会让软件读取超出数据缓冲区预期边界的内容。

成功利用该漏洞可使解析进程崩溃并造成拒绝服务。CISA 将截至 2.4.0 的 lib60870 版本列为受影响版本，并确认 2.4.1 为修复版本。

该公告将问题关联至 CVE-2026-16002 和 CWE-125，后者是越界读取的标准分类。公告还称，该产品已在化工、能源、供水和污水处理业务中实现全球部署。

这份行业清单并不意味着这些行业中的每一家组织都在运行存在漏洞的代码。它说明了 CISA 为何将该库视为工业控制系统软件，其影响超出传统服务器应用程序的范畴。

供应商的详细安全记录将受影响组件缩小至 CS101 master 和 CS104 client。这些组件接收并解析来自其他设备的消息，因此易受攻击的代码位于入站通信路径上。

经测试的易受攻击版本为 2.4.0，对应源代码提交 083dc8e。开发分支在修复提交 182ed30 之前同样受影响。MZ Automation 发布了 2.4.1 作为已修补版本。

相关日期有助于说明紧迫性。MZ Automation 于 2026 年 7 月 16 日宣布发布 2.4.1，并于 7 月 17 日在 GitHub 上发布安全公告。随后，CISA 将该问题纳入其工业公告流程。

目前公开记录中出现了两个严重性评分。CISA 材料给出的 CVSS v3 评分为 8.2，而供应商的 GitHub 公告显示为 5.3，并标注为中等。

供应商较低的评分采用的向量描述了一种网络攻击：复杂度低、无需权限、无需用户交互。该评分认定可用性影响较低，且未确认存在机密性或完整性影响。

组织不应将评分差异视为某一记录必然错误的证据。当评估者对影响或部署环境作出不同假设时，CVSS 结果可能不同。工业运营方应根据实际可达性、工艺关键性、冗余情况和恢复行为确定优先级。

在具备冗余的测试系统中可自动重启的解析器，与支持单一生产遥测路径的解析器，其运营影响截然不同。源代码缺陷可以相同，但运营风险会发生显著变化。

因此，新的义务并不只是“安装补丁”。团队必须将软件标识符关联到真实设备、网关、工程系统和应用程序。这一资产盘点步骤通常决定了已发布的修复能否触及真正需要它的系统。

一条格式错误的帧即可越过缓冲区边界

该漏洞之所以存在，是因为解码器验证的数据少于其随后实际消耗的数据。

受影响的代码处理 IEC 60870-5 ASDU TypeID 41，也称为 S_IT_TC_1。ASDU 即应用服务数据单元，在 IEC 60870 端点之间传递结构化运营信息。

S_IT_TC_1 表示带时间标签的安全统计累计总数。该缺陷出现在 cs101_information_objects.c 内 IntegratedTotalsForSecurityStatistics 的解码路径中。

根据供应商安全公告，解析器的长度保护仅检查每个预期元素的一部分数据。随后，解码器会读取一个更大的结构，其中包含计数器信息和时间戳。

完整元素约需 14 字节。其中包括一个两字节 AID 值、一个五字节二进制计数器读数，以及一个七字节 CP56Time2a 时间戳。易受攻击的验证逻辑在核心大小检查中仅计算了五字节。

当消息声明的元素数量多于其实际负载包含的元素时，这种不匹配就会变得危险。解码器会在足够长的时间内信任声明的数量，从而越过所提供缓冲区的末尾。

研究人员使用约 201 字节的最小化帧演示了这一行为。其可变结构限定词声明了 93 个元素，而该帧实际仅包含约 11 个。

解析器在尝试处理下一个元素时到达偏移量 201。当解码器越过缓冲区边界时，一个被标记为不可访问的保护页导致了确定性故障。

这条技术路径很重要，因为利用漏洞不需要长时间交互，也不需要一系列精心定时的操作。公告称，一条格式错误的 TypeID 41 ASDU 即可触发读取。

IEC 60870-5-104 通常通过 TCP 2404 端口传输消息。底层协议本身不提供内置身份验证，尽管部署方可增加传输层和应用层安全控制。

攻击者仍需将构造的消息送达解析器。这通常需要具备网络可达性、访问中间通信路径，或通过其他方式将流量注入相关链路。

一旦满足这一条件，已公布的向量无需权限，也无需用户交互。操作员无需打开文件、批准提示或登录界面。

受影响路径比“所有 lib60870 通信”这一说法所暗示的范围更具体。供应商表示，处理 S_IT_TC_1 安全计数器对象的应用程序会暴露于已演示的崩溃风险中。

这一细节应指导测试，但不应成为忽略已确认易受攻击版本的借口。组织可能无法完整掌握集成商、下游应用程序或未来配置启用的每一种消息类型。

修复扩大了验证范围，确保解码器读取前先覆盖每个元素实际消耗的全部数据。这是对边界不匹配问题的直接修复，而非网络层面的缓解措施。

MZ Automation 将该修复纳入更广泛的 2.4.1 版本更新。该版本还修复了消息长度检查、证书验证、服务器通信及其他稳定性问题。

更广泛的发布范围增加了回归测试的必要性。运营方在某些情况下并非只应用一项孤立的源代码变更，而是升级至包含多项安全与行为修正的软件包。

一个小型解码器漏洞给大型工业系统施压

主要风险不在于受损内存的数量，而在于停止运行的进程所承担的运营角色。

Lib60870 以可移植 C 代码实现 IEC 60870-5-101 和 IEC 60870-5-104 通信。前者支持串行远动链路，后者则通过 TCP/IP 网络承载相关通信。

官方代码库列出了 master 和 slave 支持、CS104 client 和 server 功能、冗余组以及文件服务。使用所需依赖项构建时，它还支持 TLS 功能。

这些能力使该库处于交换遥测和控制信息的应用程序内部。由于 lib60870 是软件组件而非单一固定的工业设备，具体产品架构各不相同。

一家公用事业企业可能在接收远程站数据的控制中心 client 中使用它。设备供应商可能将其集成至网关。集成商可能将其编译进专用监控应用程序。

这种多样性带来了第一个现实压力点。安全团队可能认识某个设备名称，却不知道其固件或软件包中包含哪一个通信库。

源代码用户可以检查依赖项记录、构建清单和提交历史。商业客户则可能需要供应商文档、软件物料清单，或供应商的直接确认。

第二个压力点是正常运行时间。工业通信往往支持持续可见性、告警处理和远程操作。从技术上说，重启一个进程可能很简单，但在运营上可能造成干扰。

已演示的影响是崩溃，而非直接导致物理损害。尽管如此，通信中断可能遮蔽当前测量数据、中断历史数据采集、延迟告警，或迫使操作员转入备用流程。

实际后果取决于系统设计。冗余 client、进程监管器、网络分段和本地自治控制可限制影响。扁平网络和单一通信路径则可能放大影响。

第三个压力点是变更控制。运营技术团队通常会在生产部署前，针对设备行为、时序、证书和供应商特定扩展测试协议库更新。

这种谨慎有助于保障可用性，但也可能延长暴露时间。组织必须在已知格式错误帧崩溃的风险，与引入测试不足的库更新的风险之间取得平衡。

CISA 的受影响行业清单让这种权衡更加显眼。能源和供水运营方不能假定，为普通办公软件设计的维护策略同样适用于遥测系统。

问题也不仅限于互联网暴露。某台设备即便与公共互联网隔离，仍可能通过受入侵的工作站、远程访问服务、供应商连接或相邻运营网络被访问。

这就是为什么只搜索公开的 TCP 2404 端口端点并不足够。外部暴露只是其中一条路径，而非全部攻击面。

资产审查应追踪完整的数据路径。团队需要识别哪些系统接收 IEC 60870 消息、哪些进程解析这些消息，以及哪些上游来源能够传递 TypeID 41 流量。

它们还应确定崩溃后会发生什么。受监督的进程可能会立即重启，而另一项服务则可能在人工干预前始终不可用。

如果相同流量到达已重启的进程，重复的恶意帧可能会绕过自动恢复。因此，网络过滤和进程监督可作为补丁的补充，但不能替代补丁。

一项实用的运营测试是：受影响客户端丢失后，改变的是控制能力、仅监控能力，还是两者兼有。该区别将影响事件严重性、维护排程和临时补偿性控制措施。

真正的取舍在于快速打补丁与安全变更之间

版本 2.4.1 修复了已知的解码缺口，但工业运营方仍需要受控部署和分层遏制措施。

最明确的修复方式是将受影响应用升级至 lib60870 2.4.1 或更高版本。MZ Automation 特别建议使用 S_IT_TC_1 信息对象的应用采取这一步骤。

组织应首先建立包含 lib60870 的系统清单。可用证据包括源代码锁定文件、构建记录、固件清单、供应商证明、软件包元数据，以及在合同允许范围内进行的二进制分析。

团队应同时记录库版本和应用的角色。接收消息的易受攻击 CS104 客户端，与虽包含该库但从不调用受影响组件的软件，面临的路径不同。

随后应梳理可达性。相关问题包括：端点是否接受来自不受信任网络、经路由的企业网段、维护笔记本电脑、跳板主机或第三方远程服务的流量。

修复应先经过具有代表性的测试环境，再进入生产环境。测试应涵盖正常遥测、畸形输入处理、故障切换、重连行为、证书验证和供应商特定的消息组合。

除 CVE-2026-16002 外，版本 2.4.1 还包含多项变更。MZ Automation 表示，该版本新增了消息长度验证，并修复了其他安全性和稳定性缺陷。这些变更强化了升级理由，但也扩大了回归测试范围。

若无法立即部署，网络控制措施可降低暴露风险。运营方可将访问限制为已知通信端点，并阻断通往 IEC 60870 网段的不必要路径。

虚拟专用网络可以保护远程访问，但并不能保证受信任路径内的每台设备都安全。被盗凭证或遭入侵的获授权主机仍可能提供网络可达性。

具备协议感知能力的监控可帮助识别异常的 TypeID 41 流量、不一致的元素数量、重复连接失败以及进程重启。运营方应验证监控设备能否正确解析相关协议变体。

端点监督可通过重启失败服务来缩短中断时间。然而，除非重启事件能够生成告警并保留有用日志，否则它也可能掩盖重复利用行为。

对 S_IT_TC_1 消息进行临时过滤需要谨慎的工程审查。阻断合法的安全计数器对象可能改变预期的监控行为，因此不应盲目采用。

CISA 网络安全响应还应保留证据。相关记录包括数据包捕获、进程崩溃转储、重启日志、应用消息，以及受影响端点周边的配置变更。

这些材料可以区分漏洞利用、存在缺陷的对端、损坏流量或无关的应用故障。同样的畸形结构既可能被刻意构造，也可能意外产生。

在确定优先级时，应谨慎处理严重性评级分歧。CISA 的 8.2 评分表明其高度关注，而供应商的 5.3 计算结果则反映了已证实安全影响有限。

这两个数字本身都无法描述某个具体工厂或控制中心的情况。本地风险评估应考虑暴露面、运营依赖性、重启行为、冗余情况以及可视性丢失带来的安全后果。

团队还应避免夸大这一发现。公开通告报告的是越界读取，而非越界写入。研究人员并未证明可实现任意代码执行。

供应商指出，在某些条件下，邻近堆数据可能会暴露，这取决于内存布局以及解码后的值是否会返回给对端。这种可能性尚未被证实为可行的数据泄露利用。

同样，公开的概念验证尚不可用。通告描述了触发条件和实验结果，但组织不应在没有单独证据的情况下，假定存在大范围的活跃利用。

因此，严谨的应对方式应介于轻视与恐慌之间。修复已确认的缺陷，在部署期间降低可达性，并监控所描述的故障模式。

这一发现对工业软件测试的启示

CVE-2026-16002 表明，现代模糊测试能够在长期运行的工业协议实现中发现狭窄的内存缺陷。

供应商通告称，一款名为 Eldprov 的开源、LLM 辅助工具使用 AFL++ 或 libFuzzer 配合 AddressSanitizer 发现了该问题。模糊测试向软件输入异常数据，以暴露崩溃和错误假设。

自动化工具识别了候选故障，但随后由人工复现并验证。研究人员使用了保护页测试工具，并在报告结果前审查了相关源代码路径。

这一过程很重要，因为自动化漏洞报告可能包含误报或描述不充分的崩溃。在这里，公开记录描述了确定性的复现结果和一个具体的边界检查错误。

这一发现还为较早的工业安全研究提供了有益对照。此前与 lib60870 相关的通告曾涉及消息处理和拒绝服务情况，表明解析器韧性仍是持续关注的问题。

协议库面临复杂的输入空间。一个帧可能在某一层有效，却在另一层携带相互矛盾的计数、长度、标志和对象类型。

测试常规设备通信很少能覆盖每一种畸形组合。模糊测试可以更快探索这些组合，尤其是与可检测无效内存访问的 sanitizer 配合使用时。

人的角色仍然居于核心。一项崩溃必须被最小化、追踪、复现，并在运营方能够采取行动前与现实暴露面关联起来。

这一发现也区分了协议安全与实现安全。加密、认证和网络分段可以限制谁能发送流量，但接收端解析器仍必须安全地处理畸形数据。

MZ Automation 已发布指南，将 IEC 60870-5-101 和 IEC 60870-5-104 描述为原生不具备加密、认证或完整性保护的协议。其 IEC 安全概览讨论了可分层部署的 TLS 和 IEC 62351 保护措施。

在正确实施的情况下，这些控制措施能够减少未授权访问。但它们不能成为解码器在读取内存前不验证每个字段的借口。

反过来，修正后的解析器也无法解决薄弱的网络信任问题。版本 2.4.1 阻止了这条已知读取路径，但并不会将传统协议变成完整的安全边界。

这正是该事件背后的核心取舍。工业运营方既需要更安全的代码，也需要更狭窄的通信路径，同时还要保持与可能部署多年设备的兼容性。

供应商可通过发布机器可读的依赖信息、支持的升级路径，以及受影响组件的清晰说明来改善这一平衡。这样，运营方就能识别暴露面，而无需对每个已部署二进制文件进行逆向工程。

该库的开源镜像有助于研究人员检查代码，也让源代码用户能够比较提交记录。不过，当客户无法直接重新构建采用该库的商业产品时，仍需要与供应商协调。

下一个测试问题是，其他 ASDU 解码器中是否存在类似的部分长度检查。版本 2.4.1 新增了更广泛的消息长度验证，表明该版本处理的不止一行孤立代码。

这并不能证明还存在其他可被利用的漏洞。但它确实有理由对结合可变计数、可选地址、计数器和时间戳的解码路径进行重点审查。

安全团队还应跟踪下游供应商是否发布自己的通知。库的修正只有在维护者重新构建、测试并发布更新软件后，才能覆盖嵌入式产品。

三个信号将显示风险是否得到控制

下一阶段取决于补丁采用情况、下游披露以及真实世界利用的证据。

第一个信号是版本 2.4.1 是否出现在实际运营产品中。库版本发布启动了修复流程，但并不能证明集成商已交付修正后的应用或固件。

运营方应询问供应商：其产品是否包含 lib60870-C、使用哪个版本，以及受影响解码器是否可达。答复应明确修正后的版本及受支持的部署流程。

一波有力的下游通告将确认供应商已在其产品组合中追踪了这一依赖关系。沉默可能意味着产品未受影响，也可能反映清单尚不完整。

第二个信号来自升级的运营证据。组织在迁移至 2.4.1 后，应关注互操作性问题、证书行为变化、重连问题，以及对不常见 ASDU 的意外处理。

干净的部署将支持在更大规模的设备群中快速采用。显著的回归问题则会拖慢打补丁进度，并增加对网络分段、允许列表和监控的依赖。

第三个信号是任何攻击者在受控测试之外使用 CVE-2026-16002 的证据。公开利用代码、事件报告、重复的畸形 TypeID 41 流量或目录升级都会提高紧迫性。

根据已发布通告的细节，已证实的结果是在实验室条件下触发解析器崩溃。公开记录并未证实任意代码执行或广泛利用。

组织应关注 CISA 更新、供应商通知及自身运营遥测，而不是等待新闻标题。即使边界设备没有显示公开暴露，IEC 60870 客户端上反复出现的进程故障也值得调查。

最有用的即时行动是开展有针对性的清单审查。找出每个接收 IEC 60870-5 消息的系统，确定其 lib60870 版本，并记录谁可以访问其解析器。

然后使用具有代表性的流量和故障场景测试版本 2.4.1。若无法及时更新，则应限制通信路径，并对解析器重启或畸形 TypeID 41 消息发出告警。

这种方法与现有证据相符，而不会夸大其影响。CISA 网络安全警告描述了受影响配置中一个已确认、可远程触发的拒绝服务情况。

尚未解决的问题不是错误的边界检查是否存在，而是有多少生产系统包含它、这些系统有多么可达，以及其所有者能够以多快的速度安全部署修正。