Уязвимость в OpenSSH под кодовым именем SSHole (её же записывают как *sshole) начали эксплуатировать менее чем через девять часов после публикации CVE. Об этом сообщает компания Previdian: на ханипоте с Alpine Linux и OpenSSH ей удалось подтвердить успешный вход с правами root. Дыра получила идентификатор CVE-2026-123158 и оценку CVSS 8.1, исправление вышло в OpenSSH 10.6p2.
Суть проблемы — в том, как OpenSSH обрабатывает пароль, когда хеширование не удаётся. При определённых условиях неудачная попытка хеширования даёт тот же результат, что и отключённый на уровне системы пароль, — символ *. Атакующему достаточно отправить слишком длинный пароль (от 257 до 1 024 байт), чтобы сбить хеширование и получить звёздочку, с которой sshd сравнит содержимое поля пароля в учётной записи. Совпадение означает успешный вход — без кражи учётных данных и без SSH-ключей.
Кого касается: musl, PAM и Alpine
Уязвимы Linux-системы, где OpenSSH работает поверх библиотеки musl при отключённых Pluggable Authentication Modules (PAM). Сюда попадает конфигурация OpenSSH-сервера по умолчанию в Alpine Linux. Корни проблемы уходят в патч 2016 года, которым закрывали перечисление имён пользователей (CVE-2016-6210): тогда и появилось поведение, при котором сбой хеширования неотличим от отключённого пароля.
Важное ограничение: эксплойт срабатывает, только если в системе есть хотя бы одна учётная запись, в поле пароля которой стоит *. Обойти пароль на аккаунтах с настоящими хешами SSHole не позволяет. Не затронуты Dropbear, дистрибутивы на glibc, не-Linux системы и серверы, которые проверяют пароли через PAM.
Что видели в атаке
По данным Previdian, первые попытки эксплуатации пошли менее чем через девять часов после публикации CVE. Телеметрия зафиксировала восемь попыток с IP-адреса 89.116.89[.]18, который геолоцируется в Японии. Вредоносные запросы использовали oversized-пароли, а после входа выполняли разведочные команды id, uname и hostname через неинтерактивные SSH-сессии. Об этом рассказал основатель и CEO Previdian Райан Дьюхёрст.
Последствия зависят от прав скомпрометированной учётной записи. Как отмечает Safe Security, успешная атака SSHole даёт доступ в рамках существующих разрешений аккаунта; при этом злоумышленник может добраться до учётных данных развёртывания, секретов приложений и подключённой инфраструктуры — это открывает путь к боковому перемещению и нарушению работы сервисов.
Как закрыть уязвимость
Поставьте OpenSSH 10.6p2 или пропатченный пакет вашего дистрибутива и перезапустите sshd. Alpine дополнительно советует искать в логах записи «Accepted password for» для учётных записей, которые не должны принимать вход по паролю:
Look in /var/log/messages for sshd lines reading Accepted password for an account that has no password (alpine, root, or any key-only user)
Там же рекомендуют проверить использование doas, недавно созданных пользователей, файлы и authorized_keys на машинах, доступных извне. Если исключить вход не удаётся, машину следует считать скомпрометированной.
Практика показывает, что уязвимости с публичным эксплойтом в OpenSSH и подобных сервисах разбирают в первые же сутки — так было и с критической дырой в Node-RED, которую эксплуатировали до того, как админы успевали обновиться. Схожая история — уязвимость в APT в Debian и Ubuntu, где CVE-2026-109518 позволяет подменить пакет и получить root: обе проблемы бьют по Linux-серверам, которые чаще всего и стоят на периметре.
Для администраторов в России ситуация та же, что и везде: если на сервере Alpine Linux со стандартным sshd и отключённым PAM есть учётка с отключённым паролем, её нужно либо закрыть, либо срочно обновиться. Проверьте конфигурацию sshd на предмет использования PAM и наличие аккаунтов с * в поле пароля — это первое, что стоит сделать, пока пакет с исправлением не доехал в репозиторий.
Частые вопросы
Какие версии OpenSSH уязвимы?
Проблема затрагивает сборки OpenSSH на musl с отключённым PAM, включая конфигурацию по умолчанию в Alpine Linux. Исправление вышло в OpenSSH 10.6p2; дистрибутивы выпускают свои патчи.
Может ли SSHole обойти пароль на любой учётной записи?
Нет. Эксплуатация возможна, только если в системе есть хотя бы одна учётная запись с * в поле пароля. Аккаунты с настоящими хешами паролей так не обойти.
Что именно делает атакующий?
Отправляет пароль длиной от 257 до 1 024 байт. Хеширование срывается и возвращает *, а sshd сравнивает этот результат с полем пароля учётной записи — совпадение даёт вход.
Затронут ли мой сервер на Debian или Ubuntu?
Если OpenSSH собран с glibc и проверка паролей идёт через PAM, уязвимость не применяется. Именно эти два условия и определяют защищённость.
Как проверить, что меня не взломали?
Ищите в /var/log/messages строки Accepted password for для учётных записей без пароля — например, alpine, root или пользователей только с ключами. Дополнительно проверьте doas, недавно созданных пользователей, файлы и authorized_keys.
Что делать, если обновиться прямо сейчас нельзя?
Минимизируйте число учётных записей с * в поле пароля, ограничьте доступ к SSH по сети и включите проверку паролей через PAM, если это возможно в вашей конфигурации. После обновления обязательно перезапустите sshd.
Насколько быстро начали атаковать?
Previdian зафиксировала первую попытку менее чем через девять часов после публикации CVE. Всего с одного IP-адреса, геолоцированного в Японии, пришло восемь попыток эксплуатации.
Опасна ли уязвимость для Dropbear и не-Linux систем?
Нет. Dropbear, не-Linux системы и дистрибутивы на glibc в список затронутых не входят.
Источник: thehackernews.com