台达DIAEnergie工控软件曝6个洞:无需密码直接进系统能源管理平台,最高9.8分

开头导语

9月24日，台达电子（Delta Electronics）正式发布安全公告 Delta-PCSA-2026-00014，旗下工业能源管理软件 DIAEnergie 一次披露 6 个安全漏洞，编号从 CVE-2026-78308 到 CVE-2026-78313，其中最严重的一个 CVSS 9.8 分——未认证攻击者无需任何密码即可绕过登录直接进入系统。更扎心的是，这已经是 DIAEnergie 最近两个月第二次批量爆洞：上个月（8月24日）它刚因 4 个 SQL 注入可导致远程代码执行被推上风口浪尖（CVE-2026-78314~78317），修复版本 v1.11.00.002 上线还不到 30 天，新补丁 v1.11.00.022 就又来了。

DIAEnergie 是一套部署在工厂、楼宇、数据中心里的能源管理系统，向下采集电表、水表、燃气表数据，向上给管理层出能耗报表。它跑在 Windows 服务器上，管的是企业的能耗账本，一旦被拿下，攻击者不仅能看光全厂用电数据，还可能以它为跳板横向渗透到生产网络。如果你所在的工厂、园区、连锁门店用了台达的电表或能源管理系统，这篇文章请务必看完。

快速自查（2 分钟速查）

第一步：确认服务器上是否装了 DIAEnergie，版本是多少。登录安装 DIAEnergie 的 Windows 服务器，打开系统控制台或直接查安装目录版本文件：

# 查看安装目录（默认路径） dir "C:\Program Files (x86)\Delta Electronics\DIAEnergie"  # 或查程序版本（PowerShell） Get-ItemProperty "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" |   Where-Object { $_.DisplayName -like "*DIAEnergie*" } |   Select-Object DisplayName, DisplayVersion

版本 < 1.11.00.022 即受全部 6 个漏洞影响。也可以登录 DIAEnergie Web 界面，在"关于/帮助"菜单里直接看版本号。

第二步：确认这套系统是否暴露在公网。在服务器上查 80/443 端口监听，再结合边界防火墙 / 云安全组配置判断：

# 查 DIAEnergie Web 端口监听（默认 IIS 站点） netstat -ano | findstr ":80 :443" | findstr "LISTENING"  # 在外部网络用手机热点访问测试（替换为你的服务器公网IP） curl -I -m 5 http://<服务器公网IP>/DIAEnergie/

如果公网能打开登录页，说明你的能源管理系统正裸奔在互联网上，属于最高风险情形——台达官方公告里"避免让控制系统及设备暴露于因特网上"这条建议说的就是这种部署。工控安全圈的经验是：能源管理系统暴露公网的比例远比管理层想象的高，很多是当年为了"领导在手机上看能耗报表"临时开的端口，开了就没人关。

第三步：查登录审计日志里有没有异常登录。重点看深夜时段、陌生 IP 的成功登录记录：

# DIAEnergie 登录日志（Web 界面：系统管理 → 日志管理 → 用户登录日志） # 或查 IIS 日志中的登录接口调用 C:\inetpub\logs\LogFiles\W3SVC1\u_ex260924.log # 检索关键词：Login / signin / 200 状态码 + 陌生IP

如果发现非运维人员的账号在奇怪时间登录，或出现大量 401 之后紧跟一次 200 的模式，要按"已被入侵"处理：立即断网取证，而不是先打补丁。

影响范围（风险确认表）

这次公告的 6 个漏洞全部影响 v1.11.00.022 之前的所有 DIAEnergie 版本。逐个看严重程度和类型：

哪些部署不受影响？

常见误区提醒：不少工厂运维认为"我们这套系统只在内网用，无所谓"。但 DIAEnergie 这类系统的实际部署中，"给总部看报表""给节能服务商远程运维"这类需求，往往通过端口映射、VPN 账号共用、远程桌面直通等方式打穿了隔离。攻击者只要拿到办公网任意一台机器的权限（一封钓鱼邮件就够了），就能顺手摸进能源系统。内网不是免死金牌，只是提高了攻击门槛。

误区二："上个月刚升过级，这次不用管。"DIAEnergie 的版本号极易看走眼：8 月那批 SQL 注入漏洞被发现的版本是 v1.11.00.002，本次公告的修复版本是 v1.11.00.022——两串数字只差末尾一位，肉眼扫过去几乎一样，含义却天差地别。如果你的系统停在 v1.11.00.002，说明它恰好是 8 月批次被曝漏洞的版本，而这次 6 个新漏洞它也一个不落地全中。建议运维同事把版本核对动作固化成截图留档，升级完成后拍照存证，避免口头汇报"升过了"但实际升错版本的情况——这在多站点连锁企业里是真实发生过的教训。

误区三："我们用的台达电表，但不装这个软件，与我无关。"DIAEnergie 不一定是你自己采购的。很多企业的能源管理平台由节能改造承包商、电力运维公司整套建设并托管，合同里写的可能是"能耗在线监测系统""电力需求侧管理平台"这类名字，底层跑的正是 DIAEnergie。建议向维保方直接发函确认两件事：底层软件是不是台达 DIAEnergie，当前版本号是多少。如果对方答不上来，那本身就是个风险信号。

技术分析

先看最危险的 CVE-2026-78308。它的 CVSS 向量为 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，逐项拆开读：

CWE-287"不当认证"在工控 Web 系统里是个经典老毛病：登录校验逻辑存在缺陷，使得攻击者可以构造特殊请求跳过密码验证环节，直接以合法会话身份进入系统。结合 9.8 的满分三要素（网络可达、无权限要求、低复杂度），这意味着任何能访问到 DIAEnergie Web 端口的人，理论上都能直接登入系统。拿到管理员会话之后，系统内的能耗数据、设备台账、组织架构信息一览无余，还可以配合下面要讲的 SQL 注入和路径遍历进一步扩大战果。

再看 CVE-2026-78312 路径遍历，向量 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H，同样无需任何认证。CWE-22 路径遍历的典型场景：应用处理文件上传或下载请求时，没有把用户提交的路径参数（比如 filename=../../windows/win.ini）规范化并限制在预定目录内，攻击者借助 ../ 序列跳出 Web 根目录，就能读取服务器任意文件（拖走配置文件、数据库连接串），或向系统目录写入文件。在 Windows + IIS 的组合里，往启动目录或计划任务目录写文件是常见的落地 RCE 手法。这个洞 I 项为 High、C 项为 N——重点在"改"和"删"而不是"读"，与官方公告"path traversal 攻击可能允许写入预期目录之外"的表述吻合。

两个 SQL 注入（CVE-2026-78309/78311，各 8.8 分）需要低权限账号，门槛略高，但在 78308 面前这个门槛形同虚设——先用认证绕过拿到任意账号会话，再拿 SQL 注入拖库提权，一套组合拳下来整个能源管理平台彻底沦陷。这也解释了为什么这 6 个洞要一起修：单看每个 8.8 分似乎"可控"，组合利用时就是完整的攻击链。

把时间轴拉长看，DIAEnergie 的漏洞史堪称工控软件的"惯犯档案"：2021 年 8 月一轮 8 个漏洞（含 3 个 9.8 分，未认证添加管理员、任意文件上传）；2022 年 3 月单次披露 29 个 CVE，其中 26 个 9.8 分 SQL 注入；2022 年 10 月又来 7 个；2023 年 1 个认证绕过；2024 年 5 月和 10 月各一轮（含未认证 SQL 注入 9.8 分）；2025 年 8 月 4 个 XSS；2026 年 8 月 4 个 SQL 注入可 RCE；本月再添 6 个。NVD 里 DIAEnergie 名下已累计 78 条 CVE 记录，其中 9.8 分一档就有 30 多个。这个模式说明问题不是"某个函数写错了"，而是整个代码库的输入校验和安全设计存在系统性缺陷——这也是所有采购工控/能源管理软件的企业应该记取的教训：看一个产品的安全水平，不要看它"有没有漏洞"，要看它历史上的漏洞是不是同类问题反复出现。

中国用户相关性：台达电子是华人创办的全球电源管理与自动化巨头，创始团队出自台湾，在大陆的中达电通渠道体系深耕三十年，工厂、楼宇、电信基站、数据中心里台达的变频器、PLC、电表装适量极大，DIAEnergie 正是配套这些设备的能源管理上位机软件，国内制造业和园区用户基数可观。更值得警惕的是，这类系统在国内的实际部署里"为了报表好看"而暴露公网的现象并不罕见，且大部分工厂的能源管理系统由节能服务商或系统集成商代维，版本常年不更新。本次 6 洞中两个"无需认证"的漏洞恰好打在这种部署形态最痛的位置。

修复指南（分优先级）

P0 紧急操作（48 小时内）：

第一，立即切断公网暴露面。登录边界防火墙/云安全组，关闭 DIAEnergie Web 端口（默认 80/443）的一切公网映射。远程报表需求改走 VPN 或堡垒机。这一步不解决漏洞本身，但能立刻把"路边谁都能打"变成"得先进内网才能打"，性价比最高。

# Windows 防火墙临时限制：只允许内网网段访问 Web 端口 netsh advfirewall firewall add rule name="DIAEnergie-Lockdown" dir=in action=allow protocol=TCP localport=80,443 remoteip=192.168.0.0/16,10.0.0.0/8 netsh advfirewall firewall add rule name="DIAEnergie-Block-Public" dir=in action=block protocol=TCP localport=80,443

第二，联系台达技术支持获取升级包。官方修复版本为 v1.11.00.022，公告明确"用户请联系台达技术支持人员获取并更新"，即安装包不公开下载，需走台达下载中心或客服渠道（www.deltaww.com / 中达电通 400 热线）。升级前务必备份数据库和配置，并在测试环境验证——上个月刚升到 v1.11.00.002 的用户这次还得再升一次，注意确认版本号最后一段是 .022 而不是 .002。

第三，轮换凭据并查入侵痕迹。如果系统曾经暴露公网，升级完成后修改所有 DIAEnergie 账号密码（包括集成商的维保账号），并按本文"快速自查"第三步回查至少 90 天的登录日志。SQL 注入可能已拖走后台数据库，里面常有其他系统的对接密码。

P1 长期方案：

一是网络分区。把能源管理系统划入独立的 OT 管理区，与办公网之间部署防火墙做双向控制，只放行报表所需的特定端口；对外报表展示用 DMZ 区的数据镜像服务器，而不是把工业服务器直接挂公网。

二是建立版本跟踪机制。DIAEnergie 两年爆 50+ 个 CVE，平均每季度都有安全更新，建议把"检查台达安全公告"列入季度运维清单（台达官网 Product Cybersecurity Advisory 页面），由固定责任人跟进，而不是等供应商群里的消息。合同层面，下次续签维保时把"安全补丁 30 天内推送并安装"写进 SLA。

三是纵深防御。在 DIAEnergie 服务器上部署主机防护（EDR 或工控主机卫士），开启 Web 访问日志集中采集；对 ../ 等路径遍历特征、登录接口的高频失败模式配置告警。即便未来再出类似漏洞，也能在利用早期发现异常。

额外防护建议：台达官方公告给出四条通用建议同样值得抄录：不点击不可信链接和邮件附件；避免控制系统暴露互联网；系统置于防火墙之后并与业务网络隔离；远程访问必须走 VPN 等安全通道。另外提两个公告没写但很实用的点：其一，DIAEnergie 常与 SQL Server 同机部署，sa 密码很多是装机时的弱口令，趁这次升级一并改掉；其二，检查 IIS 站点是否还保留着默认文档和过期的测试页面，这些是攻击者踩点的第一站。

总结 + 参考信息

行动清单：

1. 确认 DIAEnergie 版本，低于 v1.11.00.022 即在影响范围；

2. 立即关闭 Web 端口公网映射，远程访问改走 VPN；

3. 联系台达技术支持获取 v1.11.00.022 升级包，备份后升级；

4. 回查 90 天登录日志，轮换所有账号密码和数据库 sa 口令；

5. 把台达安全公告检查加入季度运维清单，维保合同补上补丁 SLA；

6. 能源系统独立组网分区，报表走 DMZ 镜像，不再直挂公网。

参考信息：

最后多说一句：工控和能源软件的漏洞响应节奏和互联网产品完全不同——没有灰度发布、没有自动更新，一个补丁从公告到全量落地往往要几个月。这期间"不暴露公网 + 内网分区 + 日志可查"这三件事，才是工控安全真正的压舱石。DIAEnergie 两年 78 个 CVE 的历史告诉我们，指望一次升级一劳永逸是不现实的，把"暴露面管理"做成日常动作，比追着每个 9.8 分打补丁更重要。

这次事件还有两条值得所有软件团队记取的工程教训。其一，"修复了"不等于"修完了"。8 月那批 SQL 注入刚修完，9 月又爆出新的认证绕过和路径遍历，说明安全修复如果只针对单个报告点打补丁，而不做同类问题的代码级排查，同类洞会像打地鼠一样反复出现——DIAEnergie 从 2021 年到 2026 年 78 个 CVE 里，SQL 注入一个类型就占了半壁江山，这是最直观的证据。其二，供应链视角要有"软件档案"意识。企业采购整套能源管理系统时，合同里通常只写功能指标和验收标准，很少有企业会问"底层用的是什么软件、历史 CVE 记录如何"。下次招标时加一条"投标方须披露系统核心组件清单及其近三年安全漏洞历史"，成本几乎为零，却能在选型阶段就避开高危常客。

对安全社区而言，本次披露流程也算一个正面样本：漏洞由 Pellera Technologies 的研究员 Alex Williams 报告，VulnCheck 参与协调，台达在公告里实名致谢并同步给出中英文双语说明，从报告到修复版本发布走完了负责任披露的完整链路。厂商响应态度值得肯定，但正如前面所说，态度解决不了历史代码的系统性缺陷——对用户来说，行动永远比观望重要：今天就去做本文开头的三步自查。

龙虾池子