باگ دور زدن احراز هویت در OpenSSH روی آلپاین لینوکس (CVE-2026-123158)؛ کدام نسخه‌ها آسیب‌پذیرند و چطور وصله کنیم
روز ۵ نوامبر ۲۰۲۶ تیم OpenSSH نسخه ۱۰.۶p2 را منتشر کرد تا یک باگ جدی در sshd را ببندد. این باگ حالا با نام CVE-2026-123158 و لقب غیررسمی «SSHole» شناخته می‌شود و دقیقا همان چیزی است که خیلی از مدیران سرور از آن می‌ترسند: ورود به سرور بدون داشتن هیچ رمز یا کلید معتبری. اگر سرور شما روی آلپاین لینوکس یا هر توزیع دیگری با musl libc اجرا می‌شود، این مطلب را تا آخر بخوانید. این یکی دیگر از آن مواردی است که افزایش امنیت سرور لینوکس را به یک کار مستمر تبدیل می‌کند، نه یک تنظیم یک‌باره.
این آسیب‌پذیری OpenSSH آلپاین لینوکس دقیقا چیست
ماجرا به تابع crypt() در کتابخانه musl برمی‌گردد. وقتی رمزی طولانی‌تر از ۲۵۶ کاراکتر به این تابع داده شود، musl به‌جای هش رمز، رشتهٔ خطای * را برمی‌گرداند. در sshd نسخه‌های قبل از ۱۰.۶p2، وقتی PAM غیرفعال است، این رشتهٔ خطا به اشتباه با مقدار واقعی هش رمز اشتباه گرفته می‌شود.
نتیجه در عمل: اگر یک حساب کاربری در فایل shadow رمزی نداشته باشد (فیلد آن * باشد) و همزمان حداقل یک حساب محلی دیگر روی همان سرور از هش $5$ یا $6$ استفاده کند، یک مهاجم می‌تواند هر رشتهٔ بین ۲۵۶ تا ۱۰۲۴ کاراکتر را به‌عنوان رمز بفرستد و وارد شود؛ بدون هیچ رمز یا کلید واقعی. این یک دور زدن کامل احراز هویت از راه دور است، نه یک حمله‌ی تئوری روی کاغذ.
بسته پیش‌فرض openssh-server روی آلپاین لینوکس رایج‌ترین هدف واقعی این باگ است، چون آلپاین به‌طور پیش‌فرض از musl استفاده می‌کند. هر توزیع دیگر مبتنی بر musl بدون PAM هم در همین وضعیت است. توزیع‌هایی که از glibc استفاده می‌کنند (دبیان، اوبونتو، RHEL، CentOS، AlmaLinux، Rocky) یا احراز هویت را از طریق PAM انجام می‌دهند، اصلا درگیر این باگ خاص نیستند.
کدام نسخه‌ها آسیب‌پذیرند
طبق تطبیق CPE در NVD، هر نسخهٔ OpenSSH قبل از ۱۰.۶، همچنین خود ۱۰.۶ و ۱۰.۶p1 آسیب‌پذیرند؛ رفع نهایی فقط در ۱۰.۶p2 انجام شده است. آلپاین هم در اعلامیهٔ رسمی خودش همهٔ شاخه‌ها از ۳.۱۶ تا ۳.۲۴ و شاخهٔ edge را پیش از وصلهٔ بک‌پورت‌شده آسیب‌پذیر اعلام کرده.
| شاخه آلپاین | نسخهٔ آسیب‌پذیر | نسخهٔ وصله‌شده |
|---|---|---|
| edge | قبل از وصله | 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 و قدیمی‌تر | قبل از وصله | وصله‌های نقطه‌ای زودتر، به‌ترتیب |
روی توزیع‌های دیگر مبتنی بر musl که از apk استفاده نمی‌کنند، معیار ساده‌تر است: اگر OpenSSH کمتر از ۱۰.۶p2 نصب است، سرور آسیب‌پذیر حساب می‌شود.
این باگ چقدر خطرناک است
نمره CVSS 3.1 این آسیب‌پذیری ۸.۱ از ۱۰ است (سطح بالا)، با بردار AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H طبق NVD؛ یعنی حمله از راه دور، بدون نیاز به دسترسی قبلی یا تایید کاربر، و در صورت موفقیت محرمانگی، یکپارچگی و دسترس‌پذیری سرور هر سه در خطرند. دسته‌بندی ضعف CWE-394 است (برگرداندن مقدار یا کد وضعیت نامنتظره).
مهم‌تر از نمره، وضعیت سوءاستفاده واقعی است: CISA این CVE را در تاریخ ۹ نوامبر ۲۰۲۶ به فهرست آسیب‌پذیری‌های مورد سوءاستفادهٔ فعال (KEV) اضافه کرد و برای نهادهای فدرال آمریکا مهلت رفع تا ۱۲ نوامبر ۲۰۲۶ تعیین شده. شرکت GreyNoise اولین تلاش سوءاستفاده در دنیای واقعی را در ۷ نوامبر، حدود ۴۰ ساعت پس از انتشار وصله، ثبت کرد و تا ۸ نوامبر حدود ۲۰ تلاش از ۱۳ آی‌پی متفاوت در چند کشور مختلف دیده بود. به زبان ساده: این آسیب‌پذیری همین الان هدف اسکن و حمله است، نه یک ریسک آینده. چند روز پیش از این هم آسیب‌پذیری ارتقا امتیاز Fragnesia در هسته لینوکس (CVE-2026-46300) منتشر شده بود؛ این روزها فاصلهٔ بین افشا و اولین حملهٔ واقعی روی سرورهای لینوکسی خیلی کوتاه‌تر از قبل است.
چطور بررسی کنیم سرور خودمان آسیب‌پذیر است یا نه
چند دستور ساده روی سرور کافی است:
cat /etc/os-release
ssh -V
apk info openssh-server
grep -i PasswordAuthentication /etc/ssh/sshd_config
- خط اول توزیع و نسخهٔ آن را نشان می‌دهد؛ اگر آلپاین است، یک قدم به جواب نزدیک‌تر شدید.
ssh -Vنسخهٔ نصب‌شدهٔ OpenSSH را چاپ می‌کند؛ هر چیزی قبل از ۱۰.۶p2 روی یک سیستم musl باید وصله شود.- روی آلپاین،
apk info openssh-serverنسخهٔ دقیق بستهٔ نصب‌شده را می‌دهد؛ آن را با جدول بالا مقایسه کنید. - خروجی
grepبگوید PasswordAuthentication روی yes است یا نه. اگر no است یا خطی پیدا نشد (یعنی مقدار پیش‌فرض آلپاین که no است در sshd_config صریح نیست)، این مسیر حمله روی سرور شما بسته است، حتی اگر نسخه هنوز قدیمی باشد.
اگر هر سه شرط با هم برقرار است — musl (آلپاین همیشه همین‌طور است)، نسخهٔ OpenSSH قبل از ۱۰.۶p2، و PasswordAuthentication روی yes — سرور باید همین امروز وصله شود.
چطور وصله یا رفع کنیم
روی آلپاین لینوکس کل کار در یک دستور خلاصه می‌شود:
apk upgrade -U -a
rc-service sshd restart
این دستور openssh را به نسخهٔ وصله‌شدهٔ شاخهٔ همان سرور ارتقا می‌دهد (مطابق جدول بالا) و سرویس sshd را دوباره راه می‌اندازد تا تغییر اعمال شود. روی توزیع‌های دیگر مبتنی بر musl، باید OpenSSH پورتابل را به نسخهٔ ۱۰.۶p2 یا بالاتر آپگرید یا از نو بیلد کنید، سپس sshd را ری‌استارت کنید.
اگر آپگرید فوری ممکن نیست، یک راه‌حل موقت کاملا این مسیر حمله خاص را می‌بندد: در /etc/ssh/sshd_config مقدار زیر را تنظیم کنید و سرویس را ری‌استارت کنید.
PasswordAuthentication no
با این تنظیم ورود فقط با کلید SSH ممکن می‌شود و رمز عبور اصلا در فرآیند احراز هویت دخیل نیست، یعنی باگ musl در crypt() دیگر هیچ راهی برای فعال‌شدن ندارد. با توجه به سوءاستفاده فعال، این موضوع را روی هر سرور آلپاین/musl با دسترسی اینترنتی که هنوز ورود با رمز را باز گذاشته، همین حالا جدی بگیرید. برای راه‌اندازی کامل این حالت — از ساخت کلید تا غیرفعال کردن قطعی رمز عبور — امن‌سازی دسترسی SSH به سرور لینوکس را هم ببینید.
سؤالات متداول
آیا این باگ روی اوبونتو یا دبیان هم کار می‌کند؟ نه. این دو و بقیهٔ توزیع‌های مبتنی بر glibc (RHEL، CentOS، AlmaLinux، Rocky) درگیر این باگ خاص نیستند، چون ریشهٔ مشکل در تابع crypt() کتابخانهٔ musl است.
اگر PAM فعال باشد باز هم در خطرم؟ نه، سیستم‌هایی که احراز هویت را از طریق PAM انجام می‌دهند از این مسیر حمله خارج هستند؛ باگ فقط وقتی رخ می‌دهد که PAM غیرفعال باشد.
آیا فقط تغییر رمز عبور کافی است؟ نه. این باگ به رمز خاصی وابسته نیست، به رفتار اشتباه crypt() با رمزهای بلند وابسته است. باید یا OpenSSH را به ۱۰.۶p2 ارتقا دهید یا ورود با رمز عبور را کامل غیرفعال کنید.
اگر الان فقط کلید SSH استفاده می‌کنم، باز هم باید آپگرید کنم؟ بله، به‌عنوان اقدام اصلی. تنظیم PasswordAuthentication no این حمله را می‌بندد، اما آپگرید به ۱۰.۶p2 رفع واقعی باگ است و بهتر است در اولین فرصت انجام شود.
جمع‌بندی
اگر یک سرور مجازی دارید که خودتان مدیرش هستید، این دقیقا نوع وصله‌ای است که باید بدون فاصله انجام شود: یک اسنپ‌شات قبل از آپگرید بگیرید، دستور apk upgrade -U -a را اجرا کنید، فایروال سرور را هم یک بار چک کنید که فقط پورت‌های لازم باز باشند (راهنمای فایروال nftables روی سرور لینوکس برای این کار). روی سرور مجازی آریانت کنترل کامل روی همین جزئیات دست خودتان است؛ همین چند دقیقه کافی است تا این مسیر نفوذ خاص بسته شود.
