SSHole: OpenSSH до 10.6p2 пускает без пароля (CVE-2026-123158)

5 ноября 2026 года вышел OpenSSH 10.6p2 с исправлением уязвимости SSHole (CVE-2026-123158, CVSS 8.1). На Linux с библиотекой musl и без PAM, а это по умолчанию Alpine Linux, SSH-сервер принимает пароль длиннее 256 символов для учётной записи без пароля. Атаку уже пробуют в сети, 9 ноября CISA включила уязвимость в каталог эксплуатируемых (KEV). Что делать: обновить пакет, перезапустить sshd и до этого момента отключить вход по паролю.

Что случилось и когда

Исследователь Özgün Kültekin нашёл ошибку на стыке двух старых решений. Патч OpenSSH 2016 года (против перебора имён пользователей, CVE-2016-6210) заставляет sshd для записи без хеша подставлять чужую соль и всё равно проверять введённый пароль. А функция crypt() в musl с 2012 года не принимает SHA-256/512-пароли длиннее 256 байт и возвращает *. Это совпадает со значением * в /etc/shadow у учётки без пароля, и сервер решает, что пароль верный.

Alpine опубликовал бюллетень 5 ноября и в тот же день выпустил исправленные пакеты для веток от 3.16 до edge. Помимо Alpine Linux, об уязвимости написали Help Net Security и The Hacker News, а Previdian сообщил о первых попытках взлома менее чем через девять часов после публикации CVE.

Кого это касается

Под удар попадают сервера, где одновременно верны все условия:

• OpenSSH старше 10.6p2 на Linux с musl (Alpine, а также часть образов OpenWrt, Buildroot, Yocto и Docker-контейнеров на Alpine);
• sshd без PAM: пакет openssh-server или openssh-server-pam при UsePAM no;
• PasswordAuthentication yes (в OpenSSH так по умолчанию);
• есть учётная запись с * в поле пароля (root, пользователи только с ключом) и ещё хотя бы одна учётка с хешем $5$ или $6$.

Не затронуты Debian, Ubuntu, Fedora и другие системы на glibc, серверы с PAM-проверкой паролей, Dropbear и OpenBSD. Уровень доступа ограничен правами взломанной учётки. Но в официальных облачных образах Alpine (tiny-cloud, версии 3.18.11 – 3.24.3) пользователь alpine имеет doas без пароля, так что практически это путь к root.

Как проверить себя

1. Узнайте, на чём работает сервер: cat /etc/os-release, для контейнеров проверьте базовый образ в Dockerfile.
2. Посмотрите версию: sshd -V или apk info openssh-server. Всё, что старше 10.6p2 или соответствующего исправленного пакета вашей ветки, уязвимо.
3. Проверьте настройки: sshd -T | grep -iE 'passwordauthentication|usepam'.
4. Найдите входы по паролю у учёток без пароля: в /var/log/messages ищите строки Accepted password for с пользователями root, alpine и теми, кто должен входить только по ключу.
5. Просмотрите doas, свежесозданных пользователей, новые файлы и authorized_keys. Если вход исключить нельзя, Alpine советует считать машину скомпрометированной.

Как закрыть

1. Обновите пакет: apk upgrade -U -a. Исправленные версии: 10.6_p2-r0 (edge), 10.3_p1-r2 (Alpine 3.23), 10.2_p1-r1 (3.22), для старых веток см. бюллетень.
2. Перезапустите sshd: rc-service sshd restart. Одно обновление не заменяет работающий процесс, и старый код продолжит принимать соединения.
3. Если обновиться нельзя прямо сейчас, поставьте PasswordAuthentication no и перезапустите sshd. Сначала убедитесь, что вход по ключу работает, иначе потеряете доступ.

Что это значит для владельца сайта

Если ваш сайт или сервис живёт на VPS с Alpine, особенно в контейнере с sshd «для удобства», это ваш случай. Вход по паролю на сервере нужен редко: ключи и отдельный пользователь без пароля надёжнее. Мы советуем проверить доступы ещё раз и сократить их до минимума: об этом же рассказываем в разборе что проверить после покупки VPS, а регулярный контроль версий входит в поддержку серверов. Если подозреваете, что на машину уже входили, переходите к экстренной помощи и защите сайта.

Первоисточники: бюллетень Alpine Linux, оповещение CISA от 9 ноября, материал Help Net Security и The Hacker News.