光伏电站的云端大门，被绕过了

2026年10月7日，安全研究员 Marlon Starkloff 公开披露了 阳光电源 iSolarCloud 平台的一个严重认证绕过漏洞——不需要任何有效密码，就能直接登入普通用户乃至管理员账户。几乎同一时间窗口，Citrix NetScaler 被曝出两个影响默认配置的零日漏洞，被形容为客户网络的"万能钥匙"。

一个直指能源命脉，一个直指企业网络边界。两件事看似不相干，结论却指向同一处：我们数字世界的信任入口，比想象中脆弱得多。

☀️ 一枚逻辑漏洞，绕过了整个光伏云

最危险的漏洞，往往不在密码学里，而在业务逻辑里。

想象一个光伏电站运维中心的早晨：值班工程师打开 iSolarCloud，例行查看各区电站的发电曲线、逆变器状态、储能充放电计划。这套平台是 阳光电源 全球电站运维的中枢——而 Marlon Starkloff 的研究发现，登录这道门，是可以被直接绕过去的。

根据披露信息，这是一个典型的业务逻辑缺陷：认证判断没有放在服务端做强校验，攻击者通过构造异常请求，就能在没有有效密码的情况下访问用户和管理员账户。更值得警惕的是波及范围——全部四个区域的 iSolarCloud 平台均受影响。这说明这不是某一次上线部署的操作失误，而是产品级的设计问题：四个区域复用了同一套认证实现，于是一个缺陷，四处失守。

失守之后的路径并不复杂：

接入平台的资产是什么？太阳能电站、逆变器、电池储能系统。换句话说，拿到管理员账户，理论上就拿到了对一整片能源资产的未授权控制能力——远程下发指令、篡改运行参数，都是云平台本身支持的功能。

这里的产业逻辑值得说透：过去十年，新能源电站管理全面云化，成千上万台逆变器被聚合到一个账户体系下统一调度。效率确实提升了，但攻击面也被"聚合"了。从前攻击者想动一台逆变器，得物理接近现场；现在，一个被绕过的登录接口，就是挂在几千台设备上的钥匙串。

🔑 NetScaler 的万能钥匙

边界设备是攻击者的最爱，因为它是企业主动暴露在公网上的那扇门。

同一时间线的另一边，Citrix NetScaler 的两个严重零日漏洞在客户群体中引发混乱。素材中的描述很直白：漏洞影响默认配置，等于给了攻击者一把打开客户网络的"万能钥匙"（skeleton key）。

"默认配置即受影响"这七个字，比漏洞本身更值得玩味。这意味着受害者名单里，不只是那些配置不当、疏于维护的组织——恰恰是那些"我们买回来就没怎么动过配置"的企业，处在最典型的暴露状态。攻防圈里流传的一句老话是：默认配置，往往就是默认漏洞。

NetScaler 这类边界网关设备，在攻防视角下有个天然劣势：它是企业网络里少数必须暴露在公网上的资产，承担 VPN 接入、应用发布、流量转发，攻击者不用钓鱼、不用绕防火墙，直接就能摸到它。而从行业经验看，这类设备历史上反复成为勒索事件的头号跳板，原因无非三条：暴露面固定、固件升级滞后、装完就没人再碰。

双零日同时存在，还切断了防守方"先打一个补丁顶一阵"的缓冲策略——两个洞，两条利用路径，处置窗口被同时压缩。对应急响应团队来说，这是最难受的局面：你不知道攻击者已经用哪条路径进来了，只能按"已沦陷"假设来做排查。

📊 两起事件的攻击面地图

把两个事件放在同一张地图上看，共性会自己浮出来。

从攻击者的排序逻辑看——影响面大、利用门槛低、目标资产价值高——能源云的认证绕过落在最扎眼的"低门槛＋高价值"象限；边界设备零日稍高一点的门槛，换来的是作为横向移动跳板的长期价值。

两者的技术形态不同，失败点却高度一致：

一个在云端 SaaS 层，一个在本地设备层，但都在回答同一个问题的环节上栽了跟头：你凭什么相信这次请求是谁发的？ 认证，正在成为新的边界——而大多数组织的安全预算，还花在旧的边界上。

🏭 能源数字化的安全债正在到期

SolarWinds 事件之后，大家都记住了供应链；但能源云这一课，行业还没真正交过学费。

过去几年，新能源装机高速扩张，电站的集控、运维、调度全面上云。资产上网的速度是一条陡峭的上行曲线，而安全能力的建设节奏，天然慢半拍——这不是某一家厂商的问题，是整个行业的结构现象。

麻烦在于，逆变器、储能这类设备的安全模型还停留在嵌入式时代：算力有限、跑不了终端检测agent、固件更新周期以月甚至年计。当"孤岛设备"变成"联网终端"，防护责任实际上转移到了云端平台身上——而 iSolarCloud 这次的教训说明，云端那道认证门，恰恰是整条链路上最薄弱的一环。一个业务逻辑缺陷，波及全部四个区域，这就是聚合风险的典型形态：平台越高效，单点失守的爆炸半径越大。

对设备厂商来说，云平台是重要的增值服务与运营收入来源，团队扩张通常围绕功能与规模；安全团队与安全评审的投入，能否跟上平台代码量的膨胀，业内普遍持保留态度。多位做能源行业攻防评估的从业者私下聊起过一个共识：能源客户的招标里，开始出现对云平台安全能力、漏洞响应流程的准入审查——这个信号比任何一次漏洞披露都更说明问题。

可以做一个冷静的推演：随着越来越多能源资产接入云平台，认证与授权的攻防会成为能源安全的主战场；研究员盯上能源云，意味着这个领域已经进入主流攻击面的视野，此类披露只会更密集，不会更稀少。

🛠️ 防守侧的落地清单

漏洞会过时，但失败模式会重演——防守方该做的，是把失败模式逐条拆掉。

针对这两类事件，把痛点和解法对应起来：

再补充几条一线经验：

• 资产台账先行。 先搞清楚哪些账户连着哪个平台、哪些设备由哪个账户管理。这次事件里，四个区域平台全部中招——不知道自己有哪些账户的组织，连排查范围都圈不出来。
• 补丁与监测双轨。 关注 阳光电源 与 Citrix 的官方通告，按厂商建议尽快处置；在修复落地前，用日志监测与访问收敛顶住窗口期。
• 给 OT 做分段。 控制指令通道与办公网络隔离，对远程下发参数、切机、改保护定值这类行为设置基线告警——正常的调度和攻击者的动作，在指令模式上是不一样的。
• 演练"平台失守"剧本。 假设云端账户体系整体沦陷，电站能不能安全停机、本地能不能脱网运行？这个问题现在回答，比事故当晚回答便宜得多。

小结

一枚认证绕过，四个区域平台，无数台联网的逆变器和储能；两个零日，一套默认配置，无数个"以为没改过配置就没事"的企业。两起事件讲的是同一个故事：认证是新的边界，默认状态是新的风险源。接下来可以预见的是，能源云平台会进入更多红队和研究员的射程，厂商的安全评审必须前移到设计阶段，而不是等到披露那天。对防守方来说，最值钱的动作只有一个——现在就去重新审视你环境里那些"一直没动过的门"。