8 月 24 日，MikroTik 推送了 RouterOS 7.24.1。看版本号就是个常规补丁：修掉了 7.24 引入的 WireGuard 隧道问题，顺手处理了 7.22 遗留的 RB3011 交换稳定性问题，还有一批 CRS8xx 系列交换机的 MLAG 修复。MikroTik官方论坛但官方论坛发布帖的回复区里，却为一件事吵了起来——这次大概 20 条更新里，有 5 条越看越不对劲。
直接把原文贴出来：
snmp - properly validate password length when applying configuration
system - improve handling of invalid SSL/TLS requests
www - improve service responsiveness when receiving malformed packets
ssh - refactor SSH service internal processes
container - improve host isolation when container is set to “privileged=yes”
这 5 条全是两类事：拦异常输入，和收紧服务内部。发布帖刚出来，就有人在回复里说，这几条看起来全都像 CVE。MikroTik官方论坛
还有人自称知情：至少有一个攻击者可控的堆溢出，从没被登记成 CVE，只用一句 improved system stability 糊弄过去了。注意，这是论坛用户的说法，官方没有证实。MikroTik官方论坛
版主出来打住，请大家别再开 CVE 这个话题。MikroTik官方论坛
但老用户 crosswind 说得很直白：RouterOS 的安全修复通常不会登记成 CVE，不是不能，而是 MikroTik 选择不披露。MikroTik官方论坛
也有人补充：藏也没用，谁都能下载两个版本的固件包，解包对比二进制，大致就能看出改了什么。MikroTik官方论坛反对方同样有理由：不是所有安全相关的修复都有已知可利用路径，CVE 数据库也不是垃圾桶。
这场争论不是第一次，每次发版都会循环上演一遍。MikroTik官方论坛但既然吵到这儿了，我把这件事给大家捋清楚。
MikroTik 不是不披露的公司。官网有专门的安全页面，目前挂着 6 个 CVE，看时间线很有意思：公告发布时间全在 2025 年，其中还有两条是 2023 和 2024 年的旧账补录。挑三个跟家用用户关系最大的说。
CVE-2025-10948（2025 年 9 月登记）：RouterOS 7 REST API 组件 libjson 的缓冲区溢出，通过 /rest/ip/address/print 就能远程触发，官方的说法是漏洞利用代码已经公开、可能已被实际使用。MikroTik官网
官方给出的修复建议是升级到 7.20.1。MikroTik官网如果你的机器还停在 7.20.1 之前，REST API 端口又朝着公网，这就不是论坛八卦，是真实风险。
CVE-2025-6443（2025 年 6 月）：VXLAN 不校验远端源地址，远程攻击者可以绕过访问限制，编号 ZDI-CAN-26415，也就是说这个漏洞是被外部安全研究机构的披露流程推着公开的，修复版本 7.20。MikroTik官网
CVE-2024-54772（2025 年 2 月登记）：WinBox 登录时对正确和错误用户名返回的响应长度不一致，攻击者可以借此枚举账户，修复版本 7.18。MikroTik官网
其余三个：SMB 服务内存破坏拒绝服务（官方建议升级到最新 7.x stable），hotspot 跨站脚本攻击（7.19.2 修复），以及 IPv6 traceroute 默认配置暴露问题（7.14 修复）。MikroTik官网MikroTik官网MikroTik官网
把这些 CVE 放一起，规律就两条。第一，正式公开的几乎都是藏不住的：要么利用代码已经满天飞，要么被外部机构推着走。第二，公告经常迟到，比如 CVE-2023-47310 直到 2025 年 6 月才挂出公告，而修复它的 7.14 早就发布了。MikroTik官网所以，等着官方宣布这是安全更新再动手，默认就是慢一拍。
今年 4 月，针对 APT28（Fancy Bear）盯上 MikroTik 设备的报道，官方在论坛发过一份声明：被攻陷的设备都是旧固件或弱配置，目前没有证据表明存在活跃且未修补的漏洞。MikroTik官方论坛这份声明信不信由你，但官方的口径始终一致：版本保持更新，管理端口别暴露给不可信网络。
实操：RouterOS 更新怎么读，三步
既然 changelog 不直说，我们就得自己会读。把这次的信息消化完，可以总结成三步。
第一步，看信号词。更新日志里密集出现这几类表述时，建议按安全相关更新对待：malformed / invalid（异常输入）、validate / validation（补上之前没有的校验）、improve handling of（改进对异常情况的处理）、sensitive（把字段标记为敏感，说明此前可能从配置导出里泄露）、refactor（重构服务内部）、isolation（加强隔离）。7.24.1 一口气命中 5 个信号词，难怪论坛炸锅。
第二步，看暴露面。同样是修复，紧迫性完全不同。改的是管理面——www/webfig、REST API、WinBox、SSH、SNMP、SMB、hotspot、VPN 端点——而你的这些端口恰好朝着公网，就当急件处理；改的是内部功能——控制台命令、LED、统计展示——按正常节奏来就行。这次的 5 条里，snmp、ssh、www、SSL 全是管理面的事。
第三步，事后对账。真正确认的漏洞，官方安全页面迟早会补上一页，每次补丁更新后去翻一遍，养成习惯；怕漏的话，官方论坛的 Announcements 板块也值得盯着。
更新节奏也按人群给个建议（不是标准答案，按自己的风险承受力校准）：
管理端口朝公网的（远程管理、DDNS、WireGuard 端点这类）：stable 出来就及时跟，别等 long-term。这个场景下，漏掉安全修复的成本远大于踩回归的成本。
纯家庭内网、断网一秒都不行的：等一周左右，看 .1 / .2 补丁出来再动。7.24 的 WireGuard 隧道回归就是 7.24.1 修掉的，这个节奏最稳。或者直接守 long-term 通道：现在的 long-term 是 7 月初更新的 7.21.5，连 v6 的 6.49.20 都在 7 月更新过，老机型没被放弃。
容器、AP 重度玩家：动手前把发布帖回复区翻一遍，看有没有同机型翻车报告再动。
这次的发布帖就很有信息量，摘几条真实反馈。有人的 RB4011 升级后重启直接无响应，最后靠 RESET 加恢复备份配置才救回来。MikroTik官方论坛
有人的 RB3011 自动备份脚本升级后一直失败，卡在 SFTP 上传那一步，疑似和这次的 SSH 调整有关。MikroTik官方论坛
还有人的设备在 7.23.3 上好好的，升到 7.24.1 后反复掉线，社区怀疑是 7.24 升级 wifi-qcom 驱动的回归，官方暂无结论。MikroTik官方论坛
同时也有人遇到两台 RB5009 的定时升级任务只重启没升级，只好手动重来。MikroTik官方论坛
而 RB5009Upr、CRS310、cAP ax、CCR2004、CRS812、CRS326、hAP ax3 这些机型的用户，大多反馈顺利升级。MikroTik官方论坛
所以老话再说一遍：升级前做好 export / backup，存一份到路由器以外的地方。在 changelog 不告诉你修了什么的时代，这是唯一的保险。
MikroTik 就是这种文化：功能给得大方，安全上喜欢修了不说。作为用户可以批评这种做法，但更重要的，是自己学会读更新，把判断权留在手里，而不是一句 improved system stability 就糊弄过去。
你手里的路由器停在哪个版本？7.24.1 准备跟吗？评论区聊聊。
