群晖用户最近需要特别留意一项与 telnetd 相关的安全更新。CVE-2026-24061 来自 GNU Inetutils 的 telnetd 认证绕过问题,影响 1.9.3 至 2.7 版本,攻击者可借此绕过验证并以 Root 权限登录启用了受影响服务的系统。群晖已在 1 月 29 日发布 DSM 7.3.2-86009 Update 1 进行修复。DSM 默认不会启用 Telnet,日常应用也不会主动打开该协议,但这不等于可以跳过系统更新——只要设备仍运行未修补版本,风险就还在。
下面按「检查—更新—验证」三步,把需要动手的地方写清楚,方便你对照自己的 NAS 完成处理。
先确认:你的 DSM 是否需要更新
打开 DSM 网页控制台,进入「控制面板」→「系统」→「更新与还原」(部分界面也可能写作「更新与还原」下的「DSM 更新」)。页面会显示当前 DSM 版本号,例如 7.3.2-86009 以及是否已安装 Update 1。
判断标准很直接:若版本低于 DSM 7.3.2-86009 Update 1,就应尽快更新。若已是该版本或更高,仍建议在同一页面确认「没有待安装的重要安全更新」,避免遗漏分阶段推送的补丁。
顺手再看一眼 Telnet 是否被打开。DSM 默认关闭 Telnet,多数用户从未启用过;可在「控制面板」→「终端机和 SNMP」中确认 Telnet 服务处于关闭状态。即便这里显示已关闭,也请继续完成系统更新——补丁针对的是系统组件本身,不只是当前是否开了服务。
两条更新路径:自动或手动
路径一:让 DSM 自动下载并安装
在「控制面板」→「更新与还原」中,若系统已检测到 Update 1,直接点击下载并安装即可。群晖对这类重要安全更新通常会自动拉取;安装完成后系统需要重启,请提前结束正在进行的备份、Docker 任务或大文件传输,避免中断。
自动更新最省事,适合能连上群晖更新服务器、且控制台已提示有新版本的用户。若页面长时间显示「已是最新版本」但你确认官方已发布 7.3.2-86009 Update 1,可改用手动方式,或稍后再刷新检查——部分型号采用分阶段推送。
路径二:从官方存档手动安装
无法自动获取更新时,可到群晖官方 DSM 存档下载对应包。针对本次修复,可使用 DSM 7.3.2-86009 Update 1 更新文件(官方存档路径示例:https://archive.synology.com/download/Os/DSM/7.3.2-86009-1)。下载时务必选择与自己机型匹配的 DSM 包,不要混用其他型号的镜像。
手动更新步骤:
- 在「控制面板」→「更新与还原」中选择「手动 DSM 更新」。
- 上传刚下载的更新文件,按向导完成安装。
- 更新结束后按提示重启 NAS。
重启过程中设备会短暂离线,局域网访问、远程连接和已挂载的共享都会中断,属于正常现象。重启完成后重新登录 DSM,再核对版本号。
更新后如何验证
重启并登录后,回到「控制面板」→「更新与还原」,确认当前版本已包含 7.3.2-86009 Update 1。若页面显示该版本且无待处理的重要更新,说明补丁已就位。
建议再做两处顺手检查:一是「终端机和 SNMP」里 Telnet 仍为关闭;二是打开「安全顾问」(若已安装),跑一次安全扫描,按提示处理其余基础加固项。这些步骤不能替代本次补丁,但能降低整体暴露面。
操作时注意这几点
更新前尽量完成一次重要数据的备份或至少确认近期备份任务成功,这是处理任何系统级更新的基本习惯。更新包只从群晖官方渠道获取,不要使用第三方镜像或来源不明的 .pat 文件。
CVE-2026-24061 的公开信息显示,该问题在 GNU Inetutils 侧存在时间较长,近期才被披露,并已有被实际利用的迹象。群晖官方公告主要说明已通过 DSM 更新修复,并未展开更多可被直接复现的技术细节;对普通用户而言,完成官方安全更新并保持 Telnet 关闭,就是当前最稳妥的处置方式。
若你的 NAS 型号较旧、官方已停止向该型号推送 DSM 7.3.2 线更新,应到 群晖产品安全顾问 与对应型号的发行说明页面,确认是否另有适用补丁或支持策略,再决定是否迁移数据到仍受支持的设备。
做完「看版本 → 装 Update 1 → 重启 → 再看版本」这一圈后,这台群晖针对 CVE-2026-24061 的处置就可以收工。之后保持自动更新开启,或定期在控制面板里扫一眼待装安全补丁,比临时追新闻更省心。

评论(45)
刚更新完,版本号对上了,心里踏实多了
老型号没推送,看来得考虑换设备了
一直开着 Telnet 做开发,这下赶紧关掉
手动下载补丁包有点慢,不过还是装上了
慢点没事,只要最后能校验通过就行
安全顾问跑了一遍,确实发现几个小问题
这种底层漏洞最可怕,必须第一时间打补丁
备份做完才敢点更新,数据安全第一
原来默认是关的,那我应该没事吧?
重启时间有点长,差点以为变砖了
感谢整理步骤,照着做很清晰
更新前备份确实是底线,数据丢了啥都白搭
确实,手滑一次就全剧终了
老设备支持周期短,换机成本真得提前算
确实,老机型换起来肉疼,得掂量下
版本号一致就稳了,今晚能睡个安稳觉
这种底层漏洞不补,半夜惊醒太吓人了
手动下载包确实慢,建议找个网速好的时段
我这边电信宽带还行,联通就龟速
安全顾问扫完发现几个小问题,赶紧处理下
默认关 Telnet 就好,但补丁还是得打全
重启那几分钟盯着进度条,手心都出汗了
第三方镜像不敢用,官方渠道最让人放心
没错,尤其是涉及系统更新,绝对不能冒险
旧型号没推送的话,是不是只能考虑迁移了?
刚看了一眼控制面板,还在推送中
分批次推送的,再刷新几次或者等等看
这种认证绕过太隐蔽了,防不胜防
这种漏洞确实难搞,只能靠官方更新了
还好平时没开终端机,风险小很多
但补丁还是得打,毕竟底层组件在
没开也建议打上补丁,防的是组件本身
重启的时候灯狂闪,心里七上八下的
安全顾问扫完记得把异常项处理掉
老机型用户表示很焦虑,怕被抛弃
更新完顺手改了个强密码,双重保险
刚检查完,我的还没推送,得等两天
手动更新那个路径挺方便的,省得等推送
现在只要是联网设备,安全更新真得跟上
重启前把 Docker 关了才敢点更新
有没有人试过更新后系统变慢的情况?
习惯开启自动更新,省得天天盯着新闻看
赶紧去看看自己的版本号,以防万一
刚才手动上传安装包,重启后稳了
这种底层漏洞还是别抱侥幸心理,赶紧更