文章总结： GNUInetUtils的telnetd存在高危漏洞CVE-2026-24061，攻击者通过注入环境变量USER为-froot，可绕过认证直接获取Root权限。该漏洞潜伏11年，目前已被黑产利用进行扫描攻击。建议立即停止Telnet服务改用SSH，或升级软件版本并严格限制端口访问。 综合评分： 91 文章分类： 漏洞分析,漏洞预警,应急响应

离谱！这可能是今年最简单的提权姿势：利用环境变量注入攻破 Linux 登录

原创

Hankzheng Hankzheng

技术修道场

2026年1月30日 07:59 广东

大家好，说实话，今天看到这个新闻的时候，我刚喝进嘴里的咖啡差点喷在屏幕上。都 2026年了，我们居然还在讨论 Telnet？而且还是一个已经在代码里“裸奔”了快 11 年的重磅级漏洞！

就在这几天，安全圈炸锅了。一个编号为 CVE-2026-24061 的漏洞被披露，CVSS 评分高达 9.8/10（接近满分）。

这个漏洞有多离谱？简单来说，攻击者只要在客户端动点手脚，就能在不需要任何密码的情况下，直接以 Root 身份登录你的服务器。

这哪里是漏洞，简直就是给黑客留了个 VIP 专属通道！今天，就带大家扒一扒这个“活久见”的 Bug 到底是怎么回事，以及它背后的技术原理。

01 这一行代码，让黑客“如入无人之境”

这次出问题的组件是 GNU InetUtils 中的 telnetd（Telnet 守护进程）。受影响的版本跨度惊人：从 2015 年发布的 1.9.3 一直到最新的 2.7 版本，全军覆没。

核心原理：由于“过度信任”引发的参数注入

要理解这个漏洞，我们得先复习一下 Linux 的底层登录机制。通常情况下，当你通过 Telnet 连接服务器时，telnetd 会调用 /usr/bin/login 程序来处理你的登录请求。

正常的流程是这样的：

1. 客户端发起连接。

2. telnetd

   接收连接，准备环境。

3. telnetd

   执行 exec 系列函数调用 login 程序，让用户输入账号密码。

问题就出在第 2 步到第 3 步之间。

RFC 协议允许 Telnet 客户端通过环境变量（Environment Variables）向服务器传递一些信息，比如 USER 变量，用来告诉服务器“我是谁”。

GNU InetUtils 的 telnetd 在代码实现上犯了一个极其低级的错误：它没有对客户端传来的 USER 环境变量做任何清洗（Sanitize）或校验，就直接把它作为参数拼接到 login 程序的调用中去了。

致命的 “-f root”

懂 Linux 系统编程的朋友都知道，/usr/bin/login 有一个非常强大的参数：-f。

man login 手册写道：

-f

Do not perform authentication, user is pre-authenticated. （不执行认证，用户已被预先认证。）

这本来是为了某些特定内部程序设计的（比如 rlogind），但在这次漏洞中，它成了黑客的“万能钥匙”。攻击流程极其简单粗暴：

1. 黑客使用特制的 Telnet 客户端。
2. 将环境变量 USER 的值设置为 -f root。
3. 连接目标服务器，并带上 -a 或 --login 参数强制发送环境变量。

此时，服务器端的 telnetd 会傻乎乎地拼接命令，最终调用的命令变成了类似这样：

/bin/login -p -h -f root

login 程序看到 -f root，认为“哦，这是自己人，不用查密码了”，直接放行，给予 Root 权限。

这就好比你去银行取钱，保安问你是谁，你直接贴了张“我是行长”的条子在脑门上，保安看了一眼条子，就直接把你领进金库了。

02 潜伏 11 年，为何至今才被发现？

看到这你可能会问：这么低级的逻辑错误，开源社区那么多人盯着，怎么会藏了 11 年？

这个漏洞最早是在 2015 年 3 月 19 日 的一次代码提交中引入的。那个时候，开发人员可能只是想优化一下环境变量的传递逻辑，结果好心办了坏事。

至于为什么一直没被发现，我觉得主要有两个原因：

• 灯下黑：

  越是基础、越古老的工具，大家越觉得它“应该没问题”，很少有人会去审计 Telnet 的源码。

• 时代变了：

  在 SSH 普及的今天，绝大多数生产环境早就把 Telnet 扔进垃圾堆了。用的人少了，发现 Bug 的概率自然就低了。

直到 2026 年 1 月 19 日，安全研究员 Kyu Neushwaistein (Carlos Cortes Alvarez) 才捅破了这层窗户纸。

03 警报！黑产已经开工了

如果这只是个理论漏洞，大家笑一笑也就完了。但问题是，它正在被利用。

根据威胁情报公司 GreyNoise 的监测数据，就在过去 24 小时内，已经捕获到了来自全球多个地区（包括中国香港、美国、日本等）的 21 个恶意 IP 正在全网扫描这个漏洞。

他们的攻击剧本非常标准：

1. 全网扫描开放 TCP/23 端口（Telnet 默认端口）的主机。 2. 发送带有 “-f root” 的 Payload。 3. 一旦成功登录，立即植入 SSH 密钥（实现持久化控制）。 4. 部署挖矿木马或僵尸网络程序。

这意味着，如果你负责的老旧系统、网络设备或者嵌入式设备上还跑着 GNU InetUtils 的 telnetd，你现在极大概率已经“中招”了。

04 假如你是管理员，该怎么办？

作为一名有经验的运维或开发，看到这里你应该已经手心出汗了。别慌，解决方案在这里：

1. 终极方案：关掉 Telnet！

说真的，都 2026 年了，除非有极特殊的历史包袱，否则没有任何理由在互联网上开放 Telnet 服务。传输都是明文的，不仅有这个漏洞，嗅探密码也是分分钟的事。

• 动作：

  立即停止 telnetd 服务，改用 OpenSSH。

• 命令：systemctl stop telnet.socket

  / systemctl disable telnet.socket

2. 无法关停？立刻打补丁

如果你维护的是某些必须要用 Telnet 的遗留系统，请检查你的 GNU InetUtils 版本。如果是 1.9.3 到 2.7 之间，请立即升级到官方修复后的最新版本。

3. 临时方案

如果暂时无法升级，也可以配置防火墙，严格限制 TCP 23 端口的访问来源，只允许受信任的内网 IP 连接。或者修改配置，强制 telnetd 使用一个不支持 -f 参数的自定义登录程序。

最后：

这个漏洞给我们的教训是深刻的：安全没有“过时”一说。 即使是那些在这个 AI 满天飞的时代看起来像是“老古董”的协议，一旦暴雷，照样能把现代化的数据中心炸得人仰马翻。

这也是为什么我们一直强调代码审计和最小权限原则的重要性。哪怕只是透传一个看似无害的环境变量，在特定的上下文里，都可能成为致命的杀手。

你们公司的现网环境里，还有还在跑 Telnet 的“活化石”系统吗？ 评论区聊聊，让我看看谁最“复古”！👇

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：技术修道场 Hankzheng Hankzheng《离谱！这可能是今年最简单的提权姿势：利用环境变量注入攻破 Linux 登录》