PHP2Shell漏洞敲响警钟：楼宇自控谁来守住控制权

原创 关注智能与未来的 2026-10-23 09:23 广东

当AI攻防进入毫秒时代：楼宇自动化拿什么应战？

“

当AI攻防进入毫秒时代：楼宇自动化拿什么应战？从 PHP2Shell 到 AI 智能体，建筑智能化的安全短板正在从设备漏洞转向系统性风险！

—— 千家网

2026年10月21日，PHP 官方发布两个高危远程代码执行漏洞的修复版本。CVE-2026-109618 和 CVE-2026-109619 均被评为CVSS v4.0 9.2 分，攻击者在特定易受影响的部署条件下，无须登录即可触发远程代码执行。官方明确建议相关用户立即升级，并指出不存在能够完全替代更新的通用缓解措施。

与此同时，安全公司 Straiker 披露了多智能体协同攻击系统 CARLIY0S的调查结果；10月22日，Axios 又报道了美国大型银行应对未经充分授权的第三方 AI 智能体访问风险的举措。

攻击工具的自动化能力正在增强，而传统系统的资产管理、权限审批和更新维护，仍然高度依赖人工流程。

这一矛盾在建筑智能化领域尤其值得关注。楼宇自控系统（BAS/BMS）、门禁平台、能源管理系统和智能化网关，正在从相对独立的控制网络，逐步走向跨系统互联、远程运维和 AI 辅助决策。网络安全问题因此不再只是信息系统能否正常运行，还可能影响空调、照明、能源设备等设施的运行与管理。

！踩坑提示 🕳

目前这些事件并不能证明 AI 攻击者已经利用上述漏洞大规模攻陷楼宇系统。它们真正提供的，是一次重新审视建筑智能化安全架构和运维机制的现实契机。

📌 本文要点

01

漏洞藏在不起眼的组件里

02

AI 改变的是权限风险

03

从设备验收到持续运营

01

SUPPLY CHAIN

PHP2Shell真正敲响的警钟：建筑设备也有软件供应链

PHP2Shell 并不是一个可以笼统理解为“所有 PHP 网站均已被攻破”的事件。

根据 PHP 官方公告，CVE-2026-109618 涉及内存耗尽处理过程中的状态异常，CVE-2026-109619 涉及请求状态释放后仍被后续处理使用的问题，两者均可能导致远程代码执行。官方已为 PHP 8.5、8.4、8.3 和 8.2 发布对应修复版本，分别为 8.5.12、8.4.27、8.3.36 和 8.2.35。

PHP 8.1 及更早版本已不再获得 PHP 项目直接提供的常规安全更新，但部分操作系统发行版或长期支持供应商可能提供回移补丁，不能简单地将版本号与实际修复状态画等号。

9.2

CVSS v4.0 评分

V4

需升级的 PHP 版本分支

对建筑智能化行业而言，最值得关注的并非 PHP 语言本身，而是其可能被封装在各类设备和管理平台中。

例如，部分能耗管理平台、门禁管理软件、设备管理后台、运维门户及边缘网关，可能使用 PHP 或其他服务端组件。即便系统没有对外提供公开网站，只要相关服务能够接收攻击者可触达的请求，就有必要评估其风险。

瑞士相关网络安全机构发布的 PHP2Shell 技术资料，也特别提醒用户不要只检查公网网站，还应关注嵌入式管理界面、内部应用及包含 PHP 的产品和设备。

设备在工程上已经完成交付，却未必在软件资产和安全管理体系中拥有清晰的身份。

一套 BMS 平台可能有明确的软件名称，却没有完整记录其操作系统版本、Web 组件、第三方库和固件版本；一台能源网关可能列在设备清单中，却没有人知道其内部运行环境是否仍受支持。

当漏洞出现时，问题随之变得具体：

1

设备内部是否包含受影响的软件组件？

2

厂商是否仍提供安全更新？

3

更新需要停机多长时间，是否影响正常控制？

4

如果厂商已经停止维护，由谁承担替换、隔离或风险接受的责任？

这些问题无法仅靠一次漏洞扫描解决。建筑智能化系统的安全能力，首先取决于是否掌握资产的真实构成，以及能否找到负责维护它的人。

02

LEGACY RISK

比单个漏洞更难解决的，是楼控系统的遗留安全问题

PHP2Shell 可以通过更新受影响组件来修复，但建筑智能化系统还有另一类更复杂的风险：一些问题并不来自某个新发现的软件漏洞，而是源于协议设计、网络部署和长期积累的权限管理缺陷。

BACnet 是建筑自动化领域广泛使用的通信标准，承担着控制器、传感器、执行器及管理系统之间的信息交换任务。传统 BACnet/IP 部署通常不会仅凭协议本身，就为所有通信提供现代 IT 网络所期待的身份认证、传输加密和细粒度访问控制。因此，设备是否可信、谁可以访问、哪些指令可以执行，很大程度上取决于网络分区、设备配置和外围安全措施。

不过，将其简单概括为“BACnet 没有安全机制”同样不够准确。BACnet 生态已经发展出 BACnet Secure Connect（BACnet/SC）等安全能力。BACnet/SC 采用基于 TLS 的安全通信和证书机制，为设备间连接提供身份验证及通信保护。真正的问题在于，既有项目是否采用这些能力，以及现场设备、网关和管理平台是否能够形成完整的安全链路。

对于存量建筑，这意味着不能只看协议标准，还要检查实际部署。

尤其值得关注的是BACnet 可命令对象的优先级机制。对于支持命令优先级的对象，控制请求可以通过优先级数组参与仲裁，设备通常依据最高优先级的有效命令决定最终输出；当相关优先级槽位为空时，才可能回退到设备自身的默认值或其他实现规定的行为。

这一机制原本是为了协调不同控制命令之间的关系，但也可能造成运维人员难以察觉的异常：上位机界面显示控制策略正在正常下发，现场设备却持续执行来自更高优先级槽位的命令。

！踩坑提示 🕳

这并不意味着任何能够接入 BACnet 网络的终端，都可以不受限制地控制整栋建筑。实际风险取决于网络可达性、设备配置、对象权限和具体实现。但它提醒行业，单纯观察上位机的指令状态，并不足以证明现场控制链路安全。

对于重要控制点，运维人员应当结合命令状态、优先级数组、实际输出值和设备运行反馈进行交叉验证，并对异常优先级占用、非预期控制源和持续偏离设定值的情况建立告警机制。

同样，设备发现和点位读取也需要受到关注。传统 BACnet 网络中的设备发现、对象读取等服务，在缺乏有效访问控制的网络环境下，可能帮助未经授权的终端了解设备类型、点位和部分运行状态。即便攻击者尚未取得控制权限，这些信息也可能降低后续攻击的侦察成本。

协议安全、网络边界、控制权限和运行监测必须共同发挥作用，任何单一措施都无法独立解决全部问题。

03

AI & PERMISSION

AI改变的不只是攻击效率，更是权限风险

如果说软件漏洞和遗留协议代表着建筑智能化行业长期存在的安全问题，那么 AI 智能体的发展，则正在改变风险被发现、利用和扩散的方式。

Straiker 于10月21日发布的 CARLIY0S 调查报告，描述了一个利用多个 AI 模型分工协作的攻击系统。报告称，该系统针对拉丁美洲400多家银行及金融机构开展攻击活动。需要注意，这里的数字指报告所描述的目标范围，并不意味着这些机构均已被成功攻陷。

这项调查的重要意义，在于展示了 AI 如何被纳入更完整的攻击流程：不同模型承担信息分析、任务执行和结果协调等工作，再与其他工具结合，减少人工逐项操作的负担。

10月22日，Axios 关于美国大型银行应对第三方 AI 智能体访问风险的报道，则呈现了另一面：当智能体使用用户凭据访问服务时，平台可能难以判断具体操作是否真正符合用户意图。相关机构因此开始重新审视第三方智能体的访问方式和权限范围。

两类事件共同说明，安全管理的重点正在从“账号是否通过认证”，扩展到“这个账号背后的自动化主体，究竟被允许做什么”。

这一问题将很快成为建筑智能化 AI 应用必须正面回答的议题。

假设某物业管理平台引入 AI 运维助手，用于分析告警、优化空调能耗、生成控制策略。若系统仅允许读取数据、提出建议，其风险相对可控；若智能体同时拥有修改温度设定值、调整运行时间表、控制设备启停甚至变更用户权限的能力，一旦模型判断错误、凭据泄露或工具调用链被滥用，影响就可能从信息错误扩大到实际运行异常。

因此，建筑 AI 应用不应简单地在“允许使用”和“禁止使用”之间二选一，而应按照任务风险建立分层授权：

第一层：只读分析

允许智能体读取经过授权的设备状态、告警和能耗数据，生成诊断结果及优化建议。

第二层：受控操作

对经过验证的低风险操作，可以在明确的设备范围、参数边界和时间窗口内执行，并保留完整审计记录。

第三层：关键控制

涉及重要设备启停、安全联动、消防相关控制及其他高影响操作时，应由经过授权的控制系统或人员依既定流程执行，不应让通用 AI 智能体绕过原有安全机制。

这也意味着，AI 智能体不能因为使用了合法账号，就自动获得该账号所能触及的全部权限。系统需要把身份认证、任务授权、操作审批和执行审计分开设计。

对于建筑行业，真正需要建立的不是一个“更聪明的控制助手”，而是一套即使面对错误建议、异常调用和凭据泄露，仍能限制影响范围的控制机制。

04

CONTINUOUS OPS

从“设备验收”走向“持续安全运营”

建筑智能化项目过去的交付逻辑，主要围绕设备安装、系统联调、功能验收和资料移交展开。网络安全往往被理解为网络隔离、防火墙配置或项目验收中的一项检查。

但在系统持续联网、远程维护和 AI 应用逐渐增加的背景下，这种一次性交付思维已经不足以应对现实风险。

首先，资产管理必须覆盖软件组件

设备台账不能止于品牌、型号和 IP 地址，还应尽可能记录固件版本、操作系统、关键软件组件、维护状态和供应商支持期限。对于无法完整掌握内部组件的设备，应要求厂商提供安全声明、漏洞响应机制和更新支持承诺。

其次，网络隔离不能只停留在拓扑图上

楼控、视频监控、门禁、办公网络和远程运维通道，应根据实际业务与风险进行分区，通过访问控制限制跨区通信。对于必须远程维护的设备，应采用受控接入、强身份认证、最小权限和操作审计，避免将控制端口直接暴露于互联网。

再次，控制系统需要具备可验证的异常检测能力

除了传统的在线状态、通信故障和告警监测，还应关注非预期控制命令、异常优先级占用、设定值突变、设备运行反馈与指令不一致等情况。安全事件的判断应与工艺逻辑、设备保护机制和现场运行状态结合，避免将普通控制波动一概视为攻击。

最后，补丁管理必须与运行连续性结合

楼宇控制系统不像普通办公终端那样可以随时重启。更新前需要核实受影响组件、评估设备和业务影响，准备备份、回退方案及必要的隔离措施。对于已经停止维护、无法安全升级的设备，应制定限期替换、网络隔离或其他经评估的风险控制方案，而不是无限期搁置。

这些要求也会改变集成商和运维服务商的业务边界。未来，项目交付不应只移交点位表、组态文件和竣工图，还应明确软件维护主体、漏洞通知渠道、远程访问规则、备份恢复要求以及重大安全事件的处置责任。

05

REGULATION

政策监管正在强化安全责任，但不能泛化适用范围

国内政策变化同样值得建筑智能化行业关注。

2025年10月28日，全国人大常委会通过修改《中华人民共和国网络安全法》的决定，相关修改自2026年1月1日起施行。修改后的第二十条明确提出支持人工智能关键技术研发，同时要求加强风险监测评估和安全监管，并支持运用人工智能等新技术提升网络安全保护水平。

这表明，AI 发展与安全治理正在被放入同一政策框架。但这并不意味着所有采用 AI 的楼宇系统都自动承担相同的新增法定义务。具体责任仍需结合系统性质、运营主体、数据处理活动及适用法律法规判断。

《国务院关于深入实施“人工智能+”行动的意见》也将安全能力作为推动 AI 应用的重要基础支撑，并提出有序推进市政基础设施智能化改造。对于建筑智能化行业而言，发展 AI 运维、智能控制和能源优化的同时，应将安全设计纳入方案论证和项目实施，而不是等系统投入运行后再补做安全措施。

另一个值得关注的方向是智能终端安全监管。

2026年6月，国家网信办、工业和信息化部、公安部印发《实施网络安全标识的产品目录（第一批）》及相关实施规则，首批目录涉及消费类网联摄像头。该制度按照自愿原则实施，且明确不适用于公共安全领域摄像头。

！踩坑提示 🕳

不能据此认定所有公共安防摄像机或建筑监控设备均须取得这一标识。不过，这一制度仍传递出重要信号：联网终端的安全能力、检测依据、生产者信息和产品责任，正在变得更加透明、可核验。

对建筑智能化设备厂商而言，安全更新能力、漏洞响应机制和生命周期支持，正在成为产品竞争力的一部分；对建设方和物业管理方而言，设备采购与验收也应更加关注长期维护条件，而不仅仅是初始价格和功能清单。

06

FOUR ACTIONS

楼宇自动化应战，先把四件事做实

面对 AI 驱动的攻防变化，建筑智能化行业并不需要把所有系统推倒重来。更务实的路径，是从能够落实、能够验证的措施开始。

第一，盘清资产

对 BMS、门禁、视频、能源平台、网关和远程运维设备建立统一台账，明确软件版本、联网方式、维护主体及支持状态，优先排查公网暴露和停止维护的设备。

第二，守住边界

对控制网络实施合理分区，限制不必要的跨网访问；对 BACnet 等工业与楼宇协议，结合实际设备能力评估安全通信、访问控制和异常监测方案，避免将网络可达性误当成可信授权。

第三，限制智能体权限

AI 运维助手默认采用只读权限。需要执行控制操作时，应通过独立授权、参数约束、人工审批或经过验证的策略执行机制完成，避免智能体直接持有长期有效的高权限共享账号。

第四，明确运维责任

在采购、集成和物业运维合同中明确漏洞通报、补丁评估、版本升级、远程维护、备份恢复和事件响应的责任边界。对于无法及时修复的遗留设备，应形成书面风险评估和处置计划。

这些措施并不意味着每个楼宇项目都需要部署复杂的安全运营平台，而是要求安全管理与项目规模、系统重要性和实际风险相匹配，并且能够在交付和运营过程中持续验证。

∞

EPILOGUE

真正的安全能力，是让失误和攻击都受到约束

PHP2Shell 提醒行业，漏洞可能藏在并不显眼的软件组件中；CARLIY0S 展示了 AI 模型如何参与自动化攻击流程；银行对第三方智能体访问风险的应对，则进一步说明，身份认证并不等于操作授权。

对建筑智能化行业而言，这三条线索最终汇聚到同一个问题：当建筑越来越依赖软件、网络和 AI 来运行，谁有权读取数据、谁可以发出控制指令、谁负责修复漏洞，以及异常发生时系统能否限制影响范围？

答案不能只写在网络安全方案里，也不能只依赖设备厂商的一纸承诺。

真正成熟的建筑智能化系统，不仅要能够自动控制，更要能够验证控制来源、约束操作权限、发现异常行为，并在出现故障或攻击时维持必要的安全状态。

当 AI 逐渐进入建筑运行的核心环节，网络安全就不再是智能化工程的附加项，而应成为系统设计、工程交付和长期运维共同遵守的基础条件。

END

∞

invitation

CIBIS2026 下周双城亮相，敬请期待！

 10月27日 成都 

 10月29日 西安 

 报名参会 

点击/阅读原文/

阅读原文

跳转微信打开