Компания Previdian сообщила о попытках эксплуатации CVE-2026-123158 в OpenSSH менее чем через девять часов после публикации сведений об уязвимости. В одном из наблюдений атакующий получил права root на honeypot с Alpine Linux и OpenSSH.
Уязвимость получила название SSHole (sshole) и оценку 8,1 по CVSS. Она затрагивает Linux-системы, где OpenSSH использует библиотеку musl, а модули PAM отключены. В эту категорию входит стандартная конфигурация сервера OpenSSH в Alpine Linux.
CVE-2026-123158 позволяет неаутентифицированному удалённому пользователю войти в учётную запись с намеренно отключённым паролем — без кражи пароля или SSH-ключа. Исправление включено в OpenSSH 10.6p2. Уязвимость обнаружил исследователь Озгун Культeкин.
Как работает SSHole
Причиной стал патч 2016 года, выпущенный против перебора имён пользователей и отслеживаемый как CVE-2016-6210. При определённых условиях OpenSSH неверно обрабатывает ошибку хеширования пароля: сбой интерпретируется как успешная аутентификация.
Для атаки достаточно передать произвольный пароль длиной от 257 до 1 024 байт. Такая строка вызывает ошибку хеширования, после чего обработчик возвращает символ «*». То же значение используется на системном уровне для учётной записи с отключённым паролем. Демон sshd сравнивает полученную «*» со значением в поле пароля и принимает попытку входа.
Критичное ограничение — на системе должна существовать хотя бы одна учётная запись, у которой в качестве хеша пароля установлена «*». SSHole не обходит пароли пользователей с действительными хешами.
Что увидели в телеметрии
При планировании таких работ можно отдельно изучить в разделе услуг ИТБ по информационной безопасности доступные направления и сопоставить их с задачами своей организации.
По данным Previdian, телеметрия показала восемь попыток эксплуатации с IP-адреса 89.116.89[.]18, геолокация которого указывает на Японию. Это не является атрибуцией конкретному оператору или стране происхождения злоумышленника.
Новости информационной безопасности, технологий и государственного регулирования, а также анонсы новых исследований Tech Threat Lab.
Наблюдаемый узел передавал чрезмерно длинные пароли для обхода аутентификации, а после входа запускал через неинтерактивные SSH-сессии команды разведки: id, uname и hostname. Previdian подтвердила успешный вход с правами root на своём honeypot под управлением Alpine Linux и OpenSSH.
Успешная эксплуатация даёт права уже скомпрометированной учётной записи, а не максимальные привилегии автоматически. Однако доступ к привилегированному пользователю может открыть учётные данные развёртывания, секреты приложений и связанную инфраструктуру. Это создаёт условия для бокового перемещения или нарушения работы сервисов, но такие сценарии зависят от прав конкретной учётной записи и не реализуются при каждом входе.
Какие системы не затронуты
Проблема не распространяется на Dropbear, Linux-дистрибутивы на базе glibc, не-Linux-системы и конфигурации, в которых проверка паролей выполняется через PAM. Сам факт использования OpenSSH ещё не означает уязвимость: необходимо проверить используемую библиотеку, состояние PAM и параметры аутентификации.
Что проверить администраторам
Затронутым организациям следует установить OpenSSH 10.6p2 либо исправленный пакет своего дистрибутива и перезапустить sshd. Для систем на Alpine Linux также рекомендуется проверить журналы на записи вида «Accepted password for» для учётных записей, которым не должен быть разрешён вход по паролю.
В частности, Alpine рекомендует просмотреть /var/log/messages на строки sshd с «Accepted password for» для пользователей без пароля — например, alpine, root или учётных записей, рассчитанных только на вход по ключу. На потенциально уязвимых хостах следует проверить использование doas, недавно созданных пользователей, файлы и authorized_keys. Если исключить несанкционированный вход невозможно, Alpine рекомендует считать такую машину скомпрометированной.
Практический вывод: в первую очередь стоит выявить OpenSSH на musl без PAM, особенно серверы Alpine Linux, обновить пакеты и сопоставить успешные парольные входы в логах с политикой учётных записей. Наблюдения Previdian показывают, что попытки эксплуатации SSHole начались менее чем через девять часов после публикации CVE.