CVE-2026-123158: Обхід аутентифікації за паролем в OpenSSH впливає на Alpine Linux

Вразливість високої серйозності в OpenSSH може дозволити неавтентифікованим віддаленим зловмисникам обійти автентифікацію за паролем на певних системах Linux, відправляючи надмірно довгий пароль. Відстежується як CVE-2026-123158 та названо SSHhole, помилка має оцінку CVSS 3.1 на рівні 8.1 і в першу чергу впливає на середовища Linux, де sshd пов’язаний із musl libc і працює без PAM. Alpine Linux є найпомітнішою постраждалою платформою, оскільки її стандартний пакет openssh-server за замовчуванням використовує цю конфігурацію.

Вразливість виникає в результаті несподіваної взаємодії між перевіркою паролів OpenSSH і реалізацією musl libc crypt(). Коли вводиться надзвичайно довгий пароль, crypt() може повернути рядок *, щоб вказати на помилку. Деякі облікові записи Linux, які налаштовані без звичайного пароля, також зберігають * у полі пароля /etc/shadow. За вразливих умов sshd може неправильно інтерпретувати відповідні значення як успішну автентифікацію.

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

Зв’язатися з продажами

OpenSSH вирішив цю проблему в Portable OpenSSH 10.6p2, випущеному 5 листопада 2026 року. Alpine Linux одночасно випустила виправлені пакети OpenSSH для всіх підтримуваних гілок та кількох старих гілок. Команда OpenSSH описує випуск як такий, що містить критичний захисний обхідний шлях для систем Linux, які використовують musl libc з вимкненим PAM.

Громадські середовища для відтворення та матеріали для доказу концепції вже доступні. Однак, станом на 6 листопада 2026 року перевірені джерела не повідомляють про підтверджене використання вразливості в реальних атак і цю помилку ще не додано до каталогу відомих експлуатованих вразливостей CISA.

Організації можуть посилити захист від нових вразливостей обходу автентифікації за допомогою AI-Рідної Платформи Виявлення Інтелекту SOC Prime, пришвидшуючи пошук загроз та інженерію виявлення у середовищах SIEM, EDR, XDR та Data Lake.

Команди безпеки також можуть використовувати Prime Architect для перетворення інтелекту про вразливості в запити пошуку та логіку виявлення, пристосовані до їх доступної телеметрії SSH, автентифікації, кінцевих точок і мереж.

Виявити CVE-2026-123158, відстежуючи успішні входи на основі паролів у облікові записи, які зазвичай використовують тільки автентифікацію ключами, незвичайні спроби автентифікації, що містять аномально довгі паролі, несподіваний віддалений доступ до облікових записів служби та поведінку після автентифікації, що не відповідає нормальній поведінці облікового запису.

Зміст виявлення може бути недоступним для кожного CVE. Перевіряйте платформу SOC Prime для поточного покриття. Якщо відповідні виявлення ще не доступні, перевірте знову, оскільки нові інтелекти про загрози та зміст для виявлення постійно додаються.

Аналіз CVE-2026-123158

CVE-2026-123158 впливає на OpenSSH sshd до Portable OpenSSH 10.6p2, коли він працює на Linux з musl libc, і автентифікація за паролем відбувається без PAM. CVE несе оцінку CVSS 3.1 на рівні 8.1 з вектором AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, що відображає віддалену експлуатацію без привілеїв або взаємодії користувача, але вимагає специфічної конфігурації системи та облікового запису.

Корінь проблеми полягає у взаємодії між OpenSSH та функцією хешування паролів, наданою musl libc.

На системах, де PAM вимкнуто, sshd виконує перевірку паролів, використовуючи системну функціональність crypt(). Для звичайного облікового запису /etc/shadow містить криптографічний хеш пароля, і значення, згенероване з наданого користувачем пароля, порівнюється із збереженим хешем.

musl libc поводиться по-іншому, коли наданий пароль перевищує допустиму довжину вводу. Для паролів довше ніж 256 байтів crypt() повертає * як значення помилки, а не звичайний хеш пароля.

Проблема виникає, оскільки * також зазвичай використовується в /etc/shadow для облікових записів, які не мають традиційно налаштованого пароля.

Якщо вразливий sshd отримує занадто довгий пароль для одного з цих облікових записів, процес автентифікації може фактично порівняти * повернене crypt() зі * збереженим у тіньовій записі облікового запису. Значення збігаються, і автентифікація може бути неправильно успішною.

Опис CVE вказує, що для вразливих конфігурацій облікових записів паролі від 256 до 1024 символів можуть призвести до успішної автентифікації. Незалежні відтворення описують паролі, що перевищують звичайний межу в 256 байтів, як достатні для спровокування вразливого стану.

Така помилка, таким чином, не є універсальним обходом паролів, що впливає на кожне розгортання OpenSSH.

Потрібно, щоб склалося кілька специфічних умов.

По-перше, сервер повинен використовувати musl libc. Alpine Linux є основним прикладом, хоча інші вбудовані чи мінімальні середовища Linux також можуть використовувати musl.

По-друге, sshd повинен виконувати автентифікацію користувачів без PAM. Стандартний пакет openssh-server Alpine побудовано без PAM, тоді як альтернативна конфігурація openssh-server-pam захищена, коли UsePAM yes включено.

По-третє, автентифікація за паролем повинна бути ввімкнена. PasswordAuthentication yes є відповідною конфігурацією. Системи, налаштовані тільки для автентифікації за публічним ключем з PasswordAuthentication no, не піддаються задокументованому шляху атаки.

І нарешті, зловмиснику потрібен обліковий запис, поле пароля якого містить *. Це можуть бути лише користувачі, облікові записи, створені без паролів, деякі ідентичності, надані через сервіси директорій, і певні користувачі хмари.

Alpine також зазначає додаткову умову: принаймні один локальний обліковий запис має містити хеш пароля стилю $5$ або $6$, щоб вразливий шлях автентифікації міг працювати, як описано.

Обліковий запис root заслуговує на особливу увагу. Alpine зазвичай зберігає root:*, але заборона автентифікації паролем PermitRootLogin у OpenSSH запобігає прямій автентифікації паролем для root. У результаті стандартна установка Alpine автоматично не відкриває пряму автентифікацію root через цю помилку.

Цей захист не усуває ширшу загрозу. Якщо інший обліковий запис з * у полі пароля є віддалено доступним і має адміністративні права через doas, sudo, можливості контейнерів або інші привілейовані механізми, успішна автентифікація все ще може надати шлях до повного компромісу системи.

Офіційні образи Alpine tiny-cloud особливо релевантні. Дослідження в сфері безпеки виявило версії, де обліковий запис alpine міг відповідати вразливим умовам і також міг використовувати doas для отримання підвищених привілеїв. Це ілюструє, чому захисники повинні оцінити привілеї облікових записів, а не припускати, що вразливість забезпечує або нешкідливий доступ користувача, або автоматичний доступ root в кожному середовищі.

Дистрибутиви Linux на основі glibc, такі як Debian, Ubuntu і RHEL, не постраждали від цієї конкретної вразливості, оскільки вразливе поводження залежить від реалізації хешування паролів musl libc. Системи, що використовують PAM для перевірки паролів SSH, також не є частиною задокументованої вразливої конфігурації.

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

Ландшафт PoC CVE-2026-123158 розвивався швидко. Громадські лабораторії відтворення напряму посилаються на записи про вразливість, що демонструє, що захисники повинні припустити, що обхід автентифікації можна відтворити без доступу до приватних досліджень експлуатів. Це значно підвищує терміновість виправлення, навіть якщо про підтверджене зловмисне використання ще не повідомлялося.

Вразливість була повідомлена Озгюном Кюльтекіном з Wakefield. OpenSSH публічно випустила версію 10.6p2 з обхідним шляхом безпеки 5 листопада 2026 року. Перевірені першоджерела не уточнюють точну дату, коли дослідник вперше виявив або приватно повідомив про цю проблему.

Виправлення OpenSSH додає перевірку, призначену для запобігання прийняття помилкових значень і недійсних коротких хешів паролів під час автентифікації за паролем. OpenSSH зазначає, що вважає, що основна причина існує поза sshd, але оскільки умова може бути використана через сервер SSH, проект реалізував захисний обхідний шлях у самому OpenSSH.

Alpine Linux переніс корекцію в кількох гілках:

Гілка Alpine	Виправлений пакет OpenSSH
edge	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

Адміністратори повинні покладатися на статус пакета дистрибуції, а не лише на банер версії SSH. Дистрибуції Linux часто впроваджують виправлення безпеки без зміни відображеної на момент виконання версії OpenSSH під час рукостискання SSH. Сервер, що відображає старий рядок версії, може вже містити виправлення постачальника.

Для виявлення CVE-2026-123158 захисники повинні приділяти пріоритет телеметрії автентифікації SSH. Дуже сильний сигнал для пошуку – це успішна автентификація паролем у обліковий запис, який призначений для використання тільки з публічним ключем або не має налаштованого пароля.

На системах Alpine адміністратори можуть переглядати /var/log/messages, централізовані журнали автентифікації, записи SIEM або еквівалентну телеметрію на предмет Accepted password подій, що стосуються несподіваних сервісних, ключових або адміністративних облікових записів.

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

Мережева телеметрія також може допомогти виявленням відкритих систем. Послуги SSH, що рекламують автентифікацію паролем або клавіатурно-інтерактивну автентифікацію, повинні отримувати вищий пріоритет виправлення, особливо коли підлягаюча система є Alpine або іншою розподіленою системою на базі musl.

На даний момент немає специфічних для кампанії IOCs CVE-2026-123158 таких як підтверджені IP-адреси атакера, домени, хеші шкідливого ПЗ або інфраструктура командного та контрольного. Відсутність статичних індикаторів робить поведінкове відстеження автентифікацій SSH і подальшої активності сесії особливо важливим.

Міри безпеки проти CVE-2026-123158

Основним методом виправлення є встановлення OpenSSH 10.6p2 або виправленого пакета, наданого дистрибуцією Linux. Адміністратори Alpine повинні оновити всю систему, використовуючи поточні пакети репозиторіїв, і перезапустити sshd після цього. Оновлення пакета само по собі не замінює вже запущений процес демона SSH.

Організації, що використовують контейнери на базі Alpine, повинні перебудувати і повторно створити будь-який образ, який встановлює openssh-server. Просто оновлення операційної системи на хості не виправляє вразливі пакети OpenSSH, вбудовані в зображення контейнера.

Адміністратори також повинні ідентифікувати вплив, перед тим як припускати, що кожен хост Alpine є вразливим. Ключові перевірки включають:

1. Визначити, чи хост використовує musl libc.
2. Перевірити, чи sshd працює зі вимкненим PAM.
3. Перевірити, чи автентифікація за паролем увімкнена.
4. Визначити облікові записи, які можуть увійти, чиє поле пароля в /etc/shadow є *.
5. Переглянути привілеї, надані цим обліковим записам.
6. Підтвердити встановлений пакет OpenSSH з виправленою версією пакета дистрибуції.

Якщо неможливо негайно виконати виправлення, організації повинні вимкнути автентифікацію за паролем SSH.

Налаштувати:

PasswordAuthentication no

та, де це можливо:

KbdInteractiveAuthentication no

Адміністратори повинні переконатися, що автентифікація за ключем працює, перш ніж застосовувати цю конфігурацію, щоб уникнути втрати законного адміністративного доступу.

Конфігурацію SSH слід перевірити, а демон перезавантажити або перезапустити. Після цього зовнішня перевірка повинна підтвердити, що сервер пропонує тільки автентифікацію за публічним ключем.

Обмеження мережевої доступності забезпечує додатковий захист у глибину. SSH зазвичай має бути доступним лише з довірених адміністративних мереж, інфраструктури VPN, хостів-бастіонів або явних списків дозволених IP-адрес, а не бути загальнодоступним в Інтернеті.

Організації також повинні замислитись, чи потрібен SSH взагалі всередині контейнерів. Сучасні середовища унітації зазвичай надають альтернативи, такі як docker exec або kubectl exec, усуваючи непотрібний сервіс віддаленої автентифікації.

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

Якщо виявлено несподіваний успішний вхід, розгляньте обліковий запис як потенційно скомпрометований. Перегляньте журнал команд shell, де це можливо, виконання процесу, підвищення привілеїв, нові або змінені записи у authorized_keys, зміни користувачів і груп, cron-завдання, стартові скрипти, встановлення пакетів і вихідні мережеві з’єднання.

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

Громадські матеріали про доказ концепції означають, що організації не повинні чекати доказів широкомасштабних атак, перш ніж застосувати виправлення. Передумови експлуатації звужують вразливу популяцію, але системи, що відповідають цим умовам, можуть бути віддалено доступні без знання дійсного пароля.