sshole (CVE-2026-123158): Вразливість OpenSSH, що впливає на Alpine Linux, та як її виправити

Від Eoin Villarin, 2026-11-07

Уразливість OpenSSH під назвою sshole дозволяє зловмисникам входити до облікових записів без пароля на Alpine Linux та інших системах на основі musl, і вона вже використовується. Хто постраждав, як перевірити свої сервери та як це виправити.

Чи я піддаюсь впливу помилки OpenSSH sshole?

Ви під загрозою, якщо сервер працює з OpenSSH старішою за 10.6p2 на системі на основі musl, наприклад Alpine Linux без PAM, дозволяє вхід за паролем SSH і має обліковий запис, поле пароля якого містить лише зірочку поряд із іншим обліковим записом із реальним хешем пароля. Debian, Ubuntu, Fedora та налаштування, які використовують PAM, не піддаються впливу.

Основні висновки

CVE-2026-123158, звана sshole, дозволяє зловмисникам входити до облікових записів без пароля на основі Linux на основі musl шляхом надсилання надмірного пароля.
Пакет openssh-server за замовчуванням у Alpine Linux уразливий, тоді як системи на основі glibc, такі як Ubuntu, і налаштування з використанням PAM - ні.
Зловмисники використали його менш ніж через дев'ять годин після публікації та отримали права root на пастбі.
Виправлення - це OpenSSH 10.6p2 або виправлений пакет Alpine для вашої гілки, після чого слід перезапустити sshd.
Якщо ви не можете оновити ще, встановіть PasswordAuthentication no та використовуйте ключі SSH.

Нещодавно виявлена помилка OpenSSH під назвою sshole, відстежувана як CVE-2026-123158, дозволяє зловмисникам входити до певних облікових записів Linux, які не повинні приймати паролі взагалі. Вона впливає на OpenSSH на системах на основі musl, таких як Alpine Linux, вона була виправлена 5 листопада 2026 року, і зловмисники почали використовувати її менш ніж через дев'ять годин після її публікації. Якщо ви запускаєте сервери Alpine, образи Docker на основі Alpine із SSH або невеликі пристрої на OpenWrt, перевірте їх сьогодні.

Що таке вразливість sshole OpenSSH?

На системах на основі musl функція crypt() бібліотеки C повертає одну зірочку (*) при невдачі хешування пароля, наприклад, коли пароль довший за його 256-байтний ліміт. Багато систем Linux також використовують одну * у полі пароля, щоб означати "цей акаунт не має пароля". OpenSSH порівняв їх, побачив *, і розглядав це як збіг. Відправка надмірного пароля була достатньою для входу до акаунту без пароля.

Поведінка сягає 2016 року, коли відбулася зміна обробки пароля в OpenSSH. Дослідник безпеки Özgün Kültekin виявив його за допомогою агентів ШІ, які виконали близько 17 600 тестів автентифікації. CVE має оцінку CVSS 3.1 - 8.1, яка оцінюється як Висока, та виправлення було відправлено у OpenSSH 10.6p2.

Чи я піддаюсь впливу?

Сервер знаходиться під загрозою, коли всі ці умови є істинними:

Він запускає OpenSSH старіше 10.6p2 на системі на основі musl, наприклад Alpine Linux, OpenWrt, Buildroot або Yocto.
sshd не використовує PAM. Це значення за замовчуванням для пакету openssh-server у Alpine.
Вхід за паролем SSH увімкнено, що є значенням за замовчуванням OpenSSH.
Існує принаймні один обліковий запис із лише * у полі пароля, наприклад користувач із ключем, поряд із іншим обліковим записом із реальним хешем пароля.

Офіційні хмарові образи Alpine для AWS та Azure від 3.18.11 до 3.24.3 є серйозним випадком: вони містять обліковий запис користувача alpine за замовчуванням із відсутнім паролем та безпарольним doas, що означає, що успішний вхід може стати root.

Не впливає: системи на основі glibc, такі як Debian, Ubuntu та Fedora, налаштування, які перевіряють паролі через PAM, Dropbear та OpenBSD. Облікові записи із справжнім хешем пароля не можна обійти таким чином.

Як перевірити свої сервери

Запустіть їх як root на кожному сервері або контейнері Alpine, який запускає sshd:

Перевірити налаштування SSH: sshd -T | grep -i -E 'passwordauthentication|usepam'. Якщо автентифікація паролем вимкнена або PAM увімкнено, ця помилка не може бути використана.
Перевірте встановлений пакет: apk list --installed | grep openssh, і порівняйте його з виправленими версіями нижче.
Список акаунтів без пароля: awk -F: '$2=="*" {print $1}' /etc/shadow.
Шукайте входи до цих акаунтів: grep "Accepted password" /var/log/messages. Парольний логін до облікового запису із * у полі пароля означає, що сервер, імовірно, був атакований.

Як виправити CVE-2026-123158 на Alpine Linux

Alpine постачає виправлені пакети для кожної гілки від 3.16 до edge у той же день, що й розкриття інформації. Оновити та перезапустити sshd, тому що встановлення оновлення не перезапускає процес, що виконується:

apk upgrade -U -a а потім rc-service sshd restart

Гілка Alpine	Виправлена версія openssh
край	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Для Docker перебудуйте кожен образ, який містить openssh, з нового базового образу та розгорніть його. Зауважте, що деякі образи SSH на Docker Hub, такі як linuxserver's openssh-server, вимикають вхід за паролем за замовчуванням, але стають відкритими, коли встановлено PASSWORD_ACCESS=true.

Старіші версії Alpine ніж 3.16 не отримують виправлений пакет. Оновити їх до підтримуваної версії або використовувати рішення нижче.

Швидкий обхід: вимкніть вхід за паролем SSH

Якщо ви не можете оновити відразу, встановіть PasswordAuthentication no у /etc/ssh/sshd_config, перезапустіть sshd та виконайте перевірку sshd -T ще раз. Переконайтеся, що ваш вхід за допомогою ключа SSH працює до того, як зробити це, інакше ви можете заблокувати собі доступ. Ключ SSH як єдиний варіант входу є гарним рішенням за замовчуванням для будь-якого сервера.

Що робити, якщо ви вважаєте, що були вражені

Перегляньте використання doas, нещодавно створених користувачів та кожен файл authorized_keys.
Перевірити наявність невідомих процесів, завдань cron та вихідних підключень.
Якщо ви не можете виключити компрометацію, ставтеся до сервера як скомпрометованого: перебудуйте його з чистого образу та змініть усі паролі, ключі та токени, які він містив.
Не завантажуйте експлойти з підтвердженням концепції з GitHub для тестування ваших серверів. Дослідники попереджають, що деякі з них не перевірені та можуть містити шкідливе програмне забезпечення.

Збереження серверів у виправленому стані є великою частиною підтримка веб-сайту Я роблю це для клієнтів. Якщо ви хочете допомогу у перевірці вашого хостингу, налаштування Docker або конфігурації SSH, Зв'язатися зі мною.

Часті питання

Чи впливає sshole на Ubuntu чи Debian?

Ні. Debian, Ubuntu, Fedora та інші системи на основі glibc не піддаються впливу, як і налаштування, які використовують PAM для перевірки паролів.

Чи захищає мене тільки ключ SSH?

Так. Якщо для параметра PasswordAuthentication встановлено значення no, сервер не приймає паролі, тому уразливість не може бути використана.

Чи експлуатується CVE-2026-123158?

Так. Фірма з аналізу загроз Previdian побачила першу спробу менш ніж через дев'ять годин після публікації CVE, і зловмисник отримав права root на одному з її медов, що працює під керуванням Alpine Linux.

Яка версія OpenSSH виправляє проблему?

OpenSSH 10.6p2. У Alpine встановіть виправлений пакет openssh для своєї гілки та перезапустіть sshd.

Чи впливають контейнери Docker?

Контейнери на основі Alpine, які запускають sshd із увімкненою авторизацією за паролем, можуть бути під загрозою. Відновіть їх із оновленого базового образу та розгорніть знову.

Чи потрібно мені перезапустити після оновлення?

Так. Робочий sshd зберігає вразливий код у пам'яті, доки ви не перезапустите службу.