В старой сетевой утилите для Linux вскрылась критическая уязвимость, которая спокойно прожила в коде почти 11 лет. Ошибка в сервере telnet (telnetd) из набора GNU InetUtils позволяет получить удалённый доступ к системе сразу с правами суперпользователя (root). Эксплойт для её эксплуатации умещается в одну строку и не требует глубоких знаний администрирования.
Уязвимости присвоен идентификатор CVE-2026-24061, её опасность оценена в 9,8 балла по шкале CVSS — фактически максимум. Причиной стал программный баг, допущенный ещё в мае 2015 года при выпуске версии 1.9.3 GNU InetUtils. Тогда разработчики исправляли другую проблему с аутентификацией, связанную с определением имени пользователя, подключающегося к telnet-серверу, и вместе с патчем добавили в код новый, гораздо более опасный изъян.
Telnet — один из старейших сетевых протоколов, созданный для организации текстового терминального доступа к удалённым системам. Он не шифрует трафик, передаёт логины и пароли в открытом виде и давно считается небезопасным. Тем не менее, telnet всё ещё встречается в ряде дистрибутивов Linux и до сих пор используется в некоторых инфраструктурах, особенно в промышленности и на «наследованных» серверах, где ПО годами не обновляют.
GNU InetUtils — это набор сетевых инструментов под эгидой Фонда свободного ПО. В него, помимо telnet/telnetd, входят ftp и tftp для передачи файлов, rlogin и rsh для удалённого управления, а также привычные ping и traceroute. В некоторых системах эти утилиты по-прежнему ставятся по умолчанию или остаются в образах, собранных несколько лет назад, что и создаёт основу для уязвимых конфигураций.
Механизм атаки основан на том, как telnetd проверяет учётные данные. По задумке, сервер вызывает системную программу `/usr/bin/login`, передавая ей имя пользователя, указанное на клиентской стороне. Утилита `login` поддерживает флаг `-f`, который говорит системе: «пользователь уже прошёл аутентификацию на другом уровне, пароль повторно спрашивать не надо». Такой механизм нужен, например, для SSO-сценариев и интеграций с другими сервисами.
После изменения кода в 2015 году telnetd стал получать имя пользователя не из протокольных данных, а из переменной окружения USER. Это значение без дополнительной проверки и без экранирования специальных символов подставлялось в команду запуска `login`. В результате злоумышленник может присвоить переменной USER строку `"-f root"`, а затем подключиться к уязвимому серверу с параметром `-a` или `--login` — и `login` воспримет это как легитимный запрос на вход от уже аутентифицированного суперпользователя.
На практике эксплойт выглядит как однострочное выражение:
`USER='-f root'; telnet -a servername`
где `servername` — имя или адрес целевого сервера. После выполнения этой команды атакующий получает сеанс с root-доступом без ввода пароля. Никаких сложных манипуляций, перебора паролей или эксплуатации переполнения буфера не требуется — всё держится на неверной обработке параметров при вызове системной утилиты.
Эксперты по информационной безопасности отмечают, что эксплуатация бреши предельно проста: достаточно выполнить корректно сформированную команду telnet, и система сама предоставит полный контроль над собой. Исследователи подтвердили, что уязвимость воспроизводится тривиально и действительно даёт полные привилегии суперпользователя на атакуемом хосте.
По данным профильных сервисов мониторинга аномальной сетевой активности, уже за первые сутки после раскрытия информации было зафиксировано не менее двух десятков уникальных IP-адресов, с которых предпринимались попытки обойти аутентификацию, используя CVE-2026-24061. Это показывает, что злоумышленники очень быстро включили новую дыру в свои скрипты сканирования интернета в поисках уязвимых узлов.
Root-доступ в Linux — это фактически «ключи от всего дома». Обладатель таких привилегий может устанавливать и удалять программы, менять конфигурации, просматривать и модифицировать любые файлы, перехватывать трафик, подменять системные утилиты, встраивать бэкдоры и скрытые механизмы удалённого управления. В случае сервера это означает полную потерю контроля над системой и необходимость считать её скомпрометированной.
Особенно опасна эта уязвимость для организаций, где до сих пор используются старые версии Linux или специализированные прошивки, которые годами не обновлялись. Telnet там нередко включён по умолчанию для удалённой настройки сетевого оборудования, промышленных контроллеров, встраиваемых устройств и старых серверных инсталляций. В таких средах переход на современные протоколы и регулярные обновления зачастую откладываются «на потом», что и создаёт идеальные условия для подобных атак.
Эксперты настоятельно рекомендуют всем, кто по какой-либо причине продолжает использовать telnet в 2026 году, как минимум обновить пакет GNU InetUtils до версии, где уязвимость закрыта. Оптимальный вариант — полностью отказаться от telnet и перейти на защищённые протоколы удалённого доступа, например на SSH, который шифрует трафик и поддерживает более гибкие механизмы аутентификации и ограничения прав.
До установки обновлений администраторам стоит временно отключить службу telnetd. Если сервис по бизнес-причинам нельзя остановить немедленно, необходимо максимально ограничить к нему доступ: закрыть порт 23/TCP для всех внешних IP-адресов, кроме строго определённого списка доверенных источников, а также вынести доступ к telnet за VPN или иной защищённый контур. Это не устраняет уязвимость, но серьёзно осложняет её эксплуатацию извне.
Профильные центры реагирования на компьютерные инциденты уже выпустили рекомендации, в которых прямо говорится об отказе от использования telnet-сервисов. Подчёркивается, что вопреки всем современным практикам безопасности в интернете всё ещё остаётся множество хостов, где telnet доступен напрямую, без дополнительной защиты. Такие системы автоматически попадают в зону повышенного риска и становятся лёгкой добычей для автоматизированных ботнетов и таргетированных атак.
История с CVE-2026-24061 хорошо иллюстрирует типичную проблему программного обеспечения: уязвимости в старых, «забытых» компонентах живут годами. Разработчики считают их второстепенными, пользователи — «и так рабочими», а на аудит и пересмотр архитектуры редко находятся время и ресурсы. В результате один неочевидный баг в редко трогаемом сервисе может превратиться в главный вход для атакующих.
Отдельная проблема — наследованные образы и конфигурации, которые мигрируют с сервера на сервер без полноценного пересмотра. Администраторы могут даже не помнить, что telnet установлен и запущен: он просто «достался по наследству» от старой инсталляции. Поэтому первым шагом должно стать инвентаризирование — поиск всех работающих telnetd в инфраструктуре, проверка открытых портов и актуальности версий установленных пакетов.
Организациям имеет смысл включить в регламенты безопасности отдельный пункт о запрете использования устаревших протоколов удалённого доступа, таких как telnet и rsh, за исключением чётко задокументированных исключений в изолированных сегментах. Для таких случаев нужно предусматривать дополнительные меры контроля: сегментацию сети, строгие ACL, мониторинг попыток подключения и быстрый план отказа от этих сервисов.
Встраивание практик безопасной разработки и эксплуатации (DevSecOps) также помогает уменьшить вероятность появления и многолетнего существования подобных «дыр». Регулярные проверки кода, статический и динамический анализ, периодические пентесты и ревизия конфигураций позволяют выявлять опасные изменения, вроде неэкранированных параметров при вызове системных утилит, ещё на ранних этапах.
Случай с уязвимостью telnetd — напоминание, что безопасность системы определяется не только современностью её основных компонентов, но и «мелочами» из прошлого, которые когда-то были настроены «на время», а потом о них просто забыли. Отключение и замена таких устаревших сервисов часто даёт больший прирост к уровню защищённости, чем установка ещё одного модного средства защиты поверх небезопасного фундамента.
