7.3分高危漏洞，攻击成本几乎为零。你家智能设备的"历史记录"功能，可能正把钥匙递给陌生人。
一个悬停动作，账户就易主
CVE-2026-33045 的核心逻辑简单到荒谬：Home Assistant 的 History-graph 卡片在渲染传感器名称时，没有过滤掉恶意代码。攻击者把一段 JavaScript 写进设备名——比如把温度传感器命名为 ——等受害者把鼠标挪到图表上，代码立即执行。
不需要点击，不需要安装可疑插件，甚至不需要受害者是技术用户。一个悬停动作，会话令牌就被发往攻击者服务器。
这个漏洞属于"存储型跨站脚本攻击"（Stored XSS，存储型跨站脚本攻击）。与反射型 XSS 不同，恶意代码被永久写入数据库，每次加载页面都会触发。Home Assistant 作为开源智能家居平台，全球装机量超过 50 万台，这意味着潜在的攻击面相当可观。
攻击者的权限要求低得惊人：普通用户账户，或者任何一个第三方集成（Integration，集成/插件）。后者尤其危险——你为了控制某个小众灯泡装的插件，可能正在后台批量篡改设备名称。
为什么偏偏是 History-graph？
History-graph 是 Home Assistant 最常用的可视化组件之一。用户用它查看温度、湿度、能耗的历史曲线，界面直观，配置简单。但也正因为"简单"，开发团队似乎默认了"传感器名称是可信输入"——这个假设在物联网场景下几乎不成立。
设备名称的来源极其复杂：厂商固件、Zigbee/Z-Wave 配对时的广播信息、用户手动修改、第三方集成的自动发现机制。每一个环节都可能被污染。更麻烦的是，Home Assistant 的实体注册表（Entity Registry）允许超长字符串和特殊字符，给了攻击者充足的编码空间。
安全研究员在披露报告中提到，漏洞存在于前端渲染层，而非后端 API。这意味着即使你启用了 Home Assistant 的"高级安全模式"，只要打开过包含恶意图表的仪表盘，依然中招。前端框架 Lit 的模板语法本应自动转义，但 History-graph 卡片在构造 SVG 标题时绕过了这一机制——一个典型的"为了性能牺牲安全"的局部优化翻车案例。
存储型 XSS 的可怕之处在于"潜伏期"。攻击者可以今天植入代码，三个月后你升级系统、查看历史数据时才触发。取证时很难追溯最初的数据来源。
修复与绕过的猫鼠游戏
Home Assistant 团队在 2026 年 3 月 27 日公开漏洞时，同步发布了 2026.3.6 补丁。修复方案是强制转义实体名称中的 HTML 特殊字符，并在渲染前增加一层 DOMPurify 清洗。
但用户端的更新率向来是开源项目的软肋。官方论坛的投票帖显示，截至 3 月 29 日，约 34% 的实例仍运行 2026.2.x 或更早版本。这些用户中，相当一部分是"装完就忘"的轻度使用者——他们的设备可能正在默默运行，成为僵尸网络的一部分。
更隐蔽的风险在于"影子实例"。许多用户为了远程访问，把 Home Assistant 暴露在公网，却未启用双因素认证。攻击者扫描到这些实例后，无需漏洞即可登录；但 CVE-2026-33045 让"低权限账户"也能造成高危害，彻底打破了原有的安全模型。
安全厂商 GreyNoise 的蜜罐数据显示，3 月 28 日起已有针对 Home Assistant 的批量扫描行为，User-Agent 伪装成合法的移动 App。攻击者显然在快速武器化这个漏洞。
智能家居的安全债，该还了
这不是 Home Assistant 第一次因前端安全问题翻车。2024 年的 CVE-2024-23334 涉及自定义面板的路径遍历，2025 年的 CVE-2025-12999 则是 Lovelace 仪表盘的权限绕过。三次漏洞都指向同一个结构性问题：一个旨在"让用户完全掌控数据"的平台，在权限边界上却屡屡模糊。
开源软件的悖论在此显现。Home Assistant 的代码对所有人透明，安全研究者可以审计，攻击者同样可以。披露后 48 小时内，GitHub 上已出现三个独立的 PoC（Proof of Concept，概念验证）仓库，其中一个用 12 行 Python 演示了完整的会话劫持流程。
对于普通用户，最务实的防御是三层：立即更新到 2026.3.6+、检查并删除来源不明的第三方集成、在反向代理层添加额外的请求过滤。如果你必须暴露公网访问，至少把管理账户和普通查看账户彻底分离——History-graph 的读取权限足以触发这个漏洞。
智能家居厂商总爱宣传"无缝体验"，但安全与便利的权衡从未消失。只是这次，代价不是弹窗广告，而是你家门锁的 API 密钥。
你的 Home Assistant 版本号，现在是多少？
热门跟贴