发生了什么？
2026 年 7 月 6 日，卡内基梅隆大学 CERT 协调中心（CERT/CC）发布了一份措辞严厉的安全公告（VU#213560），披露中国网络设备制造商 Tenda（腾达）的多款路由器固件中，存在一个未公开的认证后门。这个漏洞被编号为 CVE-2026-11405，攻击者无需任何有效凭据，即可直接获取设备的完整管理员权限。
更令人不安的是，CERT/CC 表示在漏洞披露前无法联系到 Tenda，因此截至公告发布之日，没有任何官方补丁可用——用户只能依靠临时缓解措施来保护自己的设备。
技术细节：一扇藏在认证流程里的门
CERT/CC 公告中对漏洞的技术描述相当清晰，也相当令人震惊。这个后门深藏在路由器 Web 管理界面的核心组件——/bin/httpd 二进制文件中。
正常的认证流程是这样的：用户通过 Web 登录页面提交用户名和密码，login() 函数对密码进行 MD5 哈希后与存储值比对。这部分逻辑本身没有问题。
然而，最关键的代码出现在认证失败之后。公告原文写道：
如果认证失败，该函数会调用
GetValue("sys.rzadmin.password")从设备配置中检索一个备用密码值，然后用明文strcmp()直接将用户提供的密码与该配置值比较。一旦匹配，就授予role=2（管理员级别）的权限，并创建一个有效会话。
更糟糕的是，用户名字段完全不被验证——只要你输入了正确的后门密码，用户名随便填什么都能登录。
那么，这个后门密码是什么？根据安全研究员 Olivier Laflamme（Boschko）在 2022 年对 Tenda 固件的深入逆向分析，sys.rzadmin.password 的值就是 rzadmin。是的，一个字面意义上的「弱密码」——但与你设置的任何强密码都无关，它存在于用户不可见的配置层。
这意味着你的 Tenda 路由器实际上有两套并行的认证系统：一套是你设置的管理员密码（可能会被暴力破解，但至少需要攻击者知道或猜出）；另一套是这个硬编码在固件中的 rzadmin 账户——只要攻击者知道这个密码，你的路由器随时可以被他完全接管。
受影响的具体型号
根据 CERT/CC 公告，以下五个固件版本确认受影响：
| 型号 | 受影响固件版本 |
|---|---|
| FH1201 | US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD |
| W15E | US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE |
| AC10 | US_AC10V1.0re_V15.03.06.46_multi_TDE01 |
| AC5 | US_AC5V1.0RTL_V15.03.06.48_multi_TDE01 |
| AC6 | US_AC6V2.0RTL_V15.03.06.51_multi_T |
需要特别指出的是，这五个版本不代表只有这些版本存在问题。CERT/CC 列出的是已验证受影响的具体构建版本，其他固件版本是否包含相同的后门代码，目前没有完整审计。Tenda 的产品线非常广泛，涵盖家用路由器、企业级 AP、交换机甚至视频监控设备——如果同样的认证逻辑被复用到了其他产品线，影响面可能远大于当前披露的范围。
「后门」还是「调试遗留」？这是个好问题
这个漏洞在 Hacker News 上引发了激烈讨论（230 points，72 comments）。最核心的争议点在于：这到底是一个故意植入的后门，还是工程师留下用于调试的便捷入口，发布时忘记删除了？
从技术特征来看，有几个值得注意的点：
支持「调试遗留」论：后门逻辑非常「直白」——明文 strcmp() 比较，没有任何混淆或隐藏。用户名字段直接被忽略，这在隐蔽性上可以说是零分。如果是设计精良的后门，更常见的做法是使用某种密码学挑战-响应机制，或者至少做一个看起来合理的用户名验证。此外，密码 rzadmin 也像是「RZ Admin」的缩写，符合内部调试账户的命名习惯。
支持「故意后门」论：在安全领域有一条反过来的汉隆剃刀——「永远不要用愚蠢来解释那些可以被恶意充分解释的事情」。后门存在于固件的生产发布版本中，而不是开发阶段的内测构建。Tenda 至今未对漏洞做出回应，也未提供补丁。考虑到中国 IoT 制造商过去多次被发现在设备中植入后门（无论是自主行为还是在监管要求下），这个「调试遗留」的故事听起来有点过于天真。
HN 用户有一些非常精准的评论：
「在计算机安全领域，永远不要用无知来解释那些可以被恶意充分解释的事情。」——一位用户故意反转了经典的汉隆剃刀。
「这根本不算后门，这就是一个愚蠢的默认 root 密码设计——后门至少会试图做得隐蔽一点。」——另一位用户则认为这只是糟糕的工程实践。
「后门通常（几乎总是？）被设计成看起来像无能，以提供合理的推诿借口。」
一个关键事实是，安全研究员 Olivier Laflamme 在 2022 年就曾对 Tenda W15Ev2 路由器进行了全面的逆向分析，发现了包括命令注入、缓冲区溢出、XSS 在内的共 11 个漏洞。他在披露时间线中记录了多达六次尝试联系 Tenda 的过程——包括通过微信和 QQ——但从未收到任何回应。
这揭示了一个更深层的问题：无论这个后门是故意的还是无意的，Tenda 对待安全研究的态度令人担忧。一个年营收数十亿人民币、在全球市场（尤其是东南亚、南亚、拉美）拥有大量份额的公司，竟然连续多年对安全研究人员的报告置之不理。
攻击者能做什么？
一旦攻击者利用此后门获取管理员权限，影响的严重程度相当高：
- 修改 DNS 设置：将你访问的银行网站、邮箱等重定向到钓鱼页面
- 关闭防火墙和安全规则：让内网设备完全暴露
- 建立 VPN 隧道：将你的路由器变成攻击其他网络的跳板
- 加入僵尸网络：你的路由器成为 DDoS 攻击的肉鸡
- 流量嗅探和劫持：监控所有经过路由器的网络流量
- 横向移动：从路由器进一步渗透到内网中的 NAS、电脑、IoT 设备
对普通家庭用户而言，最直接的后果可能是网银密码被盗、隐私泄露；对小企业而言，这可能意味着整个内网被攻陷。
现在该怎么办？
由于 Tenda 尚未发布补丁，CERT/CC 建议采取以下临时缓解措施：
1. 关闭远程 Web 管理 这是最重要的一步。进入路由器管理页面，找到「远程管理」或「Remote Management」选项，确保它处于关闭状态。这能防止来自互联网的攻击者直接访问你的路由器管理界面。
2. 修改局域网 IP 地址段 将路由器的默认 LAN IP（通常是 192.168.0.1 或 192.168.10.1）更改为非标准地址段的 IP（如 10.88.99.1）。这无法阻止有针对性的扫描，但能规避大量依赖默认 IP 范围的自动化攻击。
3. 隔离受影响设备 将 Tenda 路由器放在一个独立的网络隔离区中，不要让它直接暴露在互联网上。如果条件允许，在它前面加一层更可信的防火墙/NAT 设备。
4. 考虑替换或刷写固件 长远来看，替换受影响设备是最彻底的解决方案。如果需要继续使用 Tenda 硬件，检查你的型号是否支持 OpenWrt 等开源固件。多个 HN 用户指出，Tenda 的部分型号（尤其是基于联发科和高通芯片的）对 OpenWrt 有较好的支持——但需要留意的是，据社区反馈，较新的 Tenda 固件开始使用加密打包，使得第三方审计和定制变得越来越困难。
更大的图景：IoT 固件供应链的信任危机
Tenda 后门事件折射出 IoT 安全生态长期失序的深层问题。
供应链透明度为零：绝大多数消费者购买路由器时，不会——也没有能力——检查固件中是否包含后门。我们只能信任制造商。而当制造商本身的行为让人无法信任时（拒绝与安全研究人员沟通、不发布补丁），这种信任就彻底崩塌了。
谁来审计？：CERT/CC 的公告中提到，发现者是一位希望匿名的研究人员。这暗示着，如果没有这位研究人员的偶然发现，这个后门可能还会继续存在很多年。可问题是，有多少其他 IoT 设备的固件中也有类似的问题，只是还没被发现？
加密固件的趋势令人担忧：HN 上有用户指出，Tenda 近期已经开始对其固件进行加密打包，使得类似的安全审计变得更加困难。这或许是出于知识产权保护的目的，但客观上也让第三方安全分析几乎不可能进行。
经济诱因的缺失：对于 Tenda 这类主打性价比的厂商来说，投入资源进行安全审计和漏洞修复并不会带来直接的经济回报。在「卖出去就不管了」的商业模式下，固件安全永远是最后一个被考虑的优先级。
社区反应：从愤怒到恶搞
HN 讨论区的氛围混合了愤怒、无奈和黑色幽默。一些值得注意的声音：
- 多位用户表示从此以后「绝不使用任何厂商提供的黑盒固件」，只使用可以刷 OpenWrt 的设备
- 有用户指出 Tenda 是多个亚洲国家 ISP 的默认路由器供应商，实际影响可能远超表面数字
- 有人调侃道：「在你家网络拓扑图上，前面放一个中国防火墙，后面放一个美国防火墙，再后面放一个俄罗斯防火墙，让它们互相拦截各自的后门」
- 一个严肃的观点是：「如果你的安全需要依赖路由器本身不被攻陷，那你从一开始就做错了——你应该假设路由器是不可信的，并在此基础上设计你的网络防护。」
总结
CVE-2026-11405 是一个教科书级别的固件供应链安全事件。一个隐藏在数百万台设备中的明文密码，让精心设置的所有安全措施都化为乌有。更糟糕的是，厂商对漏洞报告的态度、加密固件的趋势、以及补丁的缺席，让用户的处境比漏洞本身所描述的更加被动。
如果你的网络里有 Tenda 设备，现在就去检查远程管理是否已关闭。如果你还在使用出厂固件，尽早考虑替代方案——无论是更换设备还是刷写开源固件。密码是你自己的，但后门不是。
参考链接：
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。