2026 年 2 月，一起看似偶然的安全事件揭开了消费级物联网设备背后潜藏的系统性风险。一位软件工程师仅想用 PS5 手柄遥控自己的 DJI Romo 扫地机器人，却在逆向分析通信协议后意外获得了全球约 7000 台设备的控制权限。这一事件不仅暴露了设备本身的安全缺陷，更折射出整个消费级 IoT 行业在批量设备管控层面的深层问题。
事件回顾：从个人需求到批量控制
事件的起因极具偶然性。工程师 Sammy Azdoufal 购买了一台 DJI Romo 扫地机器人，希望通过自定义应用使用 PS5 手柄对其进行远程控制。为此，他借助 AI 编码助手的帮助，逆向工程了 Romo 与 DJI 云端服务器之间的通信协议，并提取了自己设备的访问令牌。
问题的关键在于 DJI 后端服务器的权限验证机制存在严重缺陷。当 Azdoufal 将自己设备的令牌提交给服务器时，服务器错误地将该令牌识别为 “万能钥匙”，不仅授权访问其自有设备，还一并开放了数千台其他用户设备的控制权限。在实际测试中，他能够访问约 7000 台分布在 24 个国家地区的 Romo 设备，以及超过 10000 台 DJI Power 便携电源站。
具体而言，Azdoufal 获取了以下敏感能力：查看其他设备实时传输的摄像头画面、激活并监听设备麦克风、获取家庭房间的 2D 平面图、通过 IP 地址推断设备大致地理位置，以及读取设备状态数据（包括正在清洁的房间、电池电量、行驶路径和障碍物信息）。整个过程无需破解服务器或暴力破解凭证，仅凭一个有效的设备令牌便实现了对海量设备的非法访问。
技术根因：MQTT 协议权限控制失效
从技术层面分析，这起事件的核心问题在于 MQTT 协议层面的权限控制失效。DJI Romo 采用 MQTT（Message Queuing Telemetry Transport）作为设备与云端服务器之间的主要通信协议，该协议以其轻量级和低带宽特性广泛应用于 IoT 领域。然而，DJI 的 MQTT broker 在访问控制列表（ACL）配置上存在严重漏洞。
在 MQTT 架构中，主题（Topic）采用层级结构设计，支持单层通配符（+）和多层通配符（#）进行批量订阅。正常情况下，每台设备应当被限制仅能订阅和发布与其自身标识相关的主题，例如 dji/romo/{device_id}/telemetry 或 dji/romo/{device_id}/cmd。然而，DJI 的服务器未能正确实施这一隔离原则，导致任何通过身份验证的客户端都可以使用通配符订阅（如 #）来接收全局范围内的所有消息。
这正是 Azdoufal 所利用的漏洞。他向 The Verge 演示时解释：“一旦你成为 MQTT broker 上的认证客户端，如果缺乏适当的主题级访问控制，你可以订阅通配符主题（例如 #）并以明文形式查看所有设备的所有消息。TLS 只能保护传输管道本身，却无法阻止已授权的参与方访问管道内的内容。”
这意味着，即便通信链路采用了 TLS 加密（DJI 声称其设备与服务器之间的通信始终使用 TLS 加密），只要服务器端的授权检查存在缺陷，攻击者仍能在应用层获取完整的设备数据流。加密解决了数据在传输过程中被窃听的问题，但无法解决 “谁能读取这些数据” 的授权问题。
行业通病：批量控制权限的普遍困境
DJI Romo 事件并非孤例。2024 年，黑客曾入侵 Ecovacs 扫地机器人并通过设备发出种族主义言论和追逐宠物。2025 年，韩国政府机构报告 Dreame X50 Ultra 存在漏洞，可被黑客实时查看摄像头画面；另有 Ecovacs 和 Narwal 设备被发现允许黑客远程访问和窃取照片。相比之下，三星、LG 和部分 Roborock 设备在安全评估中获得了较高评价。
这一系列事件揭示了消费级 IoT 行业的普遍困境。首先，许多厂商在产品设计中过度追求功能丰富性，将摄像头、麦克风等高敏感度传感器集成到扫地机器人这类看似无害的设备中，却未能匹配同等级别的安全防护。其次，云端架构的设计往往假设 “已认证即可信”，忽视了设备身份与操作权限之间的精细映射关系。再次，厂商在发现漏洞后的应急响应机制不够透明 ——DJI 最初声称问题已修复，但实际演示表明漏洞依然存在，直至媒体确认后才推出完整补丁。
工程实践：MQTT 权限控制要点
针对此类 MQTT 权限控制漏洞，以下是工程实践中应遵循的关键原则。
身份与主题命名空间绑定是基础要求。每个设备的主题应当包含其唯一标识符，例如 tenant/site/device_id/telemetry 和 tenant/site/device_id/cmd。 ACL 规则应当基于客户端标识（client ID）或证书主题（subject）进行匹配，确保设备只能访问与其自身标识相关的主题。
最小权限原则必须贯彻到每个客户端的订阅和发布权限。设备应当仅被允许向自己的遥测主题发布数据，例如 allow client dev123 publish tenantA/site01/dev123/telemetry；同时仅被允许订阅自己的命令主题，例如 allow client dev123 subscribe tenantA/site01/dev123/cmd。应避免赋予任何终端设备对通配符主题（如 #）的订阅权限。
通配符仅限受信任后端服务使用。数据聚合器、监控面板和分析服务可能需要订阅模式如 tenantA/+/+/telemetry，但这类权限应当仅限于经过严格审计的可信服务身份，而非普通终端设备。在生产环境中，不应向任何客户端开放对 # 的发布或订阅权限。
读写权限分离同样重要。用于数据可视化的仪表盘应当仅获得读取权限，而控制类应用则需要写入权限。使用不同身份或单独的 ACL 条目来实现这种分离，可以防止单一凭证被攻破后导致全面的控制权限落入敌手。
传输层安全与网络隔离是必要补充。尽管 TLS 加密无法替代应用层授权，但它能防止中间人攻击和流量窃听。此外，MQTT broker 不应直接暴露在公网环境中，应当通过防火墙、VPN 或 API 网关进行访问控制。定期监控异常订阅模式（如设备突然订阅其正常业务不需要的通配符主题）也是检测潜在攻击的有效手段。
用户侧防御建议
对于普通消费者而言，选择和使用 IoT 设备时应当考虑以下防御措施。若设备具备摄像头或麦克风功能，应评估是否存在不必要的隐私收集风险，必要时可在不使用时物理遮挡摄像头或切断设备电源。将 IoT 设备部署在独立的网络分区或 VLAN 中，与主要的工作和生活网络隔离，能够有效限制潜在攻击的横向移动范围。关注厂商的安全公告和固件更新，及时应用安全补丁。
从更宏观的视角来看，DJI Romo 事件提醒我们，消费级 IoT 设备的安全风险已从理论层面的隐私担忧演变为可实际利用的批量控制漏洞。在厂商层面，加强 MQTT 协议的主题级访问控制、实施最小权限原则、建立透明的漏洞披露和修复机制，是重建用户信任的必经之路。在用户层面，提升安全意识、采取网络隔离策略、审慎选择具备良好安全口碑的品牌，同样是降低风险的重要手段。当 7000 台设备可以在几分钟内被一个偶然的逆向工程行为所控制时，安全不再是可选项，而是必备的基础能力。
资料来源：The Verge 报道（2026 年 2 月 14 日）、Malwarebytes 安全分析、DJI 官方声明。