群晖发布DSM更新修复Telnetd安全漏洞 即便未启用也可能影响安全性
群晖发布 DSM 更新修复 Telnetd 进程安全漏洞，即便未启用 Telnet 服务也可能影响安全性，建议所有用户立即升级。目前没有任何证据表明该漏洞已经被利用，但基于安全考虑建议无论是否启用 Telnet 服务的用户都立即升级到最新版以强化系统安全性。
NAS 服务器制造商群晖在 2026 年 1 月 29 日发布多项 DSM 操作系统软件更新，此次更新部分被标记为重要或关键修复，除非用户手动禁用更新功能否则 DSM 系统将自动升级到新版本。
此次漏洞主要涉及群晖终端机功能的 telnetd 进程 (属于 Telnet 的服务守护进程)，漏洞编号为 CVE-2026-24061，群晖给出的漏洞评级为严重或高危级别。
目前群晖并未透露有关该漏洞的详细信息，不过建议所有用户立即升级到最新版，尤其是那些需要开启并使用 Telnet 服务的用户需要立即升级到最新版以提升安全性。
受影响的系统版本：
Synology DSM 7.3 系列：7.3.2-86009 之前的版本。
Synology DSM 7.2.2 系列：需升级至 7.2.2-72806-5 或更高。
Synology DSM 7.3.1 系列：需升级至 7.3.1-86003 Update 1 或更高。
即使没开启 Telnet 也需要升级：
尽管群晖没提但在社区讨论中有安全研究人员建议即便用户没有开启 Telnet 服务也需要升级，群晖在默认情况下是不会开启终端机的 (包括 SSH 和 Telnet 服务)。
但 Telnet 涉及到系统核心文件，漏洞存在不等于漏洞会被触发，但漏洞存在也意味着防御降级，即这会弱化群晖 NAS 的安全性因此同样建议升级。
如果黑客发现其他漏洞进入系统的低权限环境，则可能可以利用 telnetd 进程存在的漏洞进行本地提权，所以升级到新版本确保漏洞被修复才是正确的选择。
via 群晖DSM发行说明
此次漏洞主要涉及群晖终端机功能的 telnetd 进程 (属于 Telnet 的服务守护进程)，漏洞编号为 CVE-2026-24061，群晖给出的漏洞评级为严重或高危级别。
目前群晖并未透露有关该漏洞的详细信息，不过建议所有用户立即升级到最新版，尤其是那些需要开启并使用 Telnet 服务的用户需要立即升级到最新版以提升安全性。
受影响的系统版本：
Synology DSM 7.3 系列：7.3.2-86009 之前的版本。
Synology DSM 7.2.2 系列：需升级至 7.2.2-72806-5 或更高。
Synology DSM 7.3.1 系列：需升级至 7.3.1-86003 Update 1 或更高。
即使没开启 Telnet 也需要升级：
尽管群晖没提但在社区讨论中有安全研究人员建议即便用户没有开启 Telnet 服务也需要升级，群晖在默认情况下是不会开启终端机的 (包括 SSH 和 Telnet 服务)。
但 Telnet 涉及到系统核心文件，漏洞存在不等于漏洞会被触发，但漏洞存在也意味着防御降级，即这会弱化群晖 NAS 的安全性因此同样建议升级。
如果黑客发现其他漏洞进入系统的低权限环境，则可能可以利用 telnetd 进程存在的漏洞进行本地提权，所以升级到新版本确保漏洞被修复才是正确的选择。
via 群晖DSM发行说明
关于作者
评论3次
### 结论 该漏洞存在xi统级风险，即使未启用 Telnet 服务仍需升级。核心风险为： 1. **漏洞存在于xi统核心文件**，未启用服务不代表代码/配置不存在，攻击者可通过本地提权扩大权限。 2. **防御链断层**：若攻击者通过其他漏洞获取低权限，telnetd 的缺陷可能被用作提权跳板，破坏纵深防御体xi。 3. **代码缺陷影响全局**：xi统底层逻辑（如进程控制、文件解析）可能受漏洞波及，需通过版本回滚或补丁验证修复点。 --- ### 分析路径（T00ls方法论） #### **L1 攻击面识别：Source-Sink 分析** - **Source（漏洞源）**： - `telnetd` 进程的代码逻辑（如配置解析、权限控制、协议处理）。 - xi统级依赖文件（如 `/etc/telnetd.conf` 或 `/etc/rc.subr` 中的启动脚本）。 - **Sink（风险点）**： - **远程利用**：若服务未彻底禁用（如残留 socket 或未关闭端口），攻击者可能直接触发 RCE。 - **本地提权**：低权限进程可利用代码漏洞（如缓冲区溢出、路径遍历）控制 `telnetd` 进程或修改敏感配置，获得 root 权限。 #### **L2 假设与验证** - **假设1**：即使 Telnet 未启用，漏洞相关代码仍存在于内核或用户空间，可能被本地利用。 - **验证步骤**： - 检查xi统中是否存在 `telnetd` 二进制文件或配置文件： ```bash ls /usr/syno/bin/telnetd || grep -r "telnetd" /etc/ ``` - 若存在，进一步分析其权限（如 SUID/SGID）或是否被其他进程调用： ```bash lsof | grep telnetd ``` - **假设2**：漏洞与 Telnet 服务逻辑相关，如配置解析时未验证输入导致内存破坏。 - **验证步骤**： - 比较新旧版本的 `telnetd` 文件差异（需获取旧版本二进制）： ```bash diff <old-telnetd> <new-telnetd> | grep -E "memory|buffer|parse" ``` - 或通过逆向分析旧版本寻找堆栈/整数溢出等漏洞模式。 #### **L3 边界/异常场景** - **未启用 Telnet 的场景**： - 检查xi统是否仍有 `telnetd` 相关 socket 或监听端口残留： ```bash ss -tulnp | grep telnet ``` - 若未监听，需验证漏洞是否存在于非网络面（如本地文件写入或命令注入）。 - **混合攻击场景**： - 攻击者通过其他漏洞（如 Web 服务 RCE）获取 shell 后，利用 `telnetd` 漏洞提权。需测试低权限用户是否可触发漏洞： ```bash su -s /bin/bash nobody # 尝试调用 telnetd 或执行提权操作 ``` #### **L4 防御反推与修复** - **防御链修复点**： - **代码层**：新版本可能修复了 `telnetd` 的输入验证或内存管理逻辑。 - **配置层**：移除过时配置项，或禁用危险功能（如默认关闭服务并删除无用二进制）。 - **验证修复有效性**： 1. 升级后重复 L2/L3 验证步骤，确认漏洞代码不存在或漏洞路径已阻断。 2. 检查补丁发行说明中的修复描述，定位代码变更点。 --- ### 验证步骤（最小可执行路径） 1. **确认当前版本是否受影响**： ```bash dsmcontrol.sh -v # 对比输出版本与公告中的受影响版本列表 ``` 2. **检查 Telnet 服务状态**： ```bash sudo synopkg list | grep -i telnet ``` 3. **检查是否存在漏洞相关文件**： ```bash strings /usr/syno/bin/telnetd | grep -E "CVE-2026-24061|exploit_pattern" ``` 4. **强制升级并验证**： ```bash sudo synousbupdate --force --check-update --accept-license # 重启后重复上述检查 ``` --- ### 修复建议 1. **立即升级 DSM**，即使 Telnet 未启用，因漏洞可能存在于未运行的服务代码中。 2. **检查升级后的xi统**：确保 `telnetd` 相关文件被更新或移除，关闭非必要服务。 3. **加固策略**： - 禁用 SSH/Telnet 默认端口，改用高随机端口并设置白名单。 - 定期监控 `/var/log/messages` 中 `telnetd` 相关异常日志。 4. **防御纵深**： - 限制低权限用户对敏感进程/文件的访问权限（如通过 SELinux/AppArmor）。 - 部署本地提权检测规则（如 Wazuh 的提权事件监控）。 --- **注**：若群晖未公开 PoC 或漏洞类型，建议直接依赖官方补丁，避免自行测试可能触发未知风险。
是不是意味着其他NAS厂商也会受这个漏洞影响
家用NAS 的被攻击频率 也加快了啊 ，这是1个网络攻击满天飞的世界。