OpenSSH’de kapatılmış parolası bulunan bazı Linux hesaplarına erişim sağlayabilen CVE-2026-123158 kodlu kimlik doğrulama açığının saldırganlar tarafından istismar edilmeye başlandığı bildirildi. “SSHole” adıyla da anılan açık, özellikle Alpine Linux ve musl C kitaplığını kullanan diğer dağıtımlarda, PAM devre dışıyken ve SSH parola ile girişe izin verirken etkili oluyor.
İlk gözlemler, 6-8 Kasım arasında en az 20 istismar girişiminin kayda geçtiğini gösterdi. Gözlenen faaliyetlerin şimdilik botnetler ve kripto para madenciliği odaklı aktörlerle sınırlı olduğu bildirildi. Açık duyurulduğunda doğrulanmış saldırı bilgisi bulunmuyordu; sonraki günlerde yayımlanan veriler aktif tarama ve istismar girişimlerinin başladığını ortaya koydu.
Açık hangi sistemlerde ve hesaplarda etkili oluyor?
CVE-2026-123158, OpenSSH sunucusunun parolayı PAM üzerinden değil, doğrudan sistemin crypt() işleviyle denetlediği belirli kurulumları etkiliyor. Alpine Linux’un standart openssh-server paketi PAM olmadan derlendiği için riskli yapılandırmalar arasında yer alıyor.
İstismarın başarılı olması için sunucuda parola ile SSH girişinin açık olması, hedef hesabın parola alanında * işaretinin bulunması ve makinede $5$ ya da $6$ ile başlayan geçerli parola özeti taşıyan en az bir başka hesabın yer alması gerekiyor. Saldırganın ayrıca parolasız hedef hesabın kullanıcı adını bilmesi ve sunucuya ağ üzerinden erişebilmesi şart.
Etkilenebilecek hesaplar arasında parolasız oluşturulmuş yalnızca SSH anahtarı kullanan kullanıcılar, dizin hizmetlerinden gelen bazı kullanıcılar ve belirli bulut imajlarındaki varsayılan hesaplar bulunuyor. Alpine Linux’un tiny-cloud imajlarında yer alan alpine kullanıcısının parolasız doas yetkisi taşıması, başarılı giriş sonrasında yönetici yetkisine yükselme riski doğurabiliyor.
Uzun parola kimlik doğrulamasını neden geçebiliyor?
Linux’ta parolayla erişimi kapatılan hesapların parola alanında çoğunlukla * karakteri tutuluyor. Normal koşullarda hiçbir parolanın bu hesaplara erişim sağlamaması gerekiyor. Ancak OpenSSH, kullanıcı adı tahminini zorlaştırmak için 2016’da yapılan değişiklik sonrasında kullanılabilir parola özeti olmayan hesaplar için de parola özeti üretmeye çalışıyor.
musl C kitaplığındaki crypt() işlevi, 256 bayttan uzun parolaları işleyemediğinde hata göstergesi olarak * döndürüyor. OpenSSH, hedef hesabın parola alanındaki * ile işlem sonucundaki * karakterini eşleşme olarak yorumlayabiliyor. Böylece saldırgan, 257 ile 1024 karakter arasında bir parola göndererek giriş hakkı elde edebiliyor.
Açık, geçerli parola özeti bulunan hesapların parolalarını kırmıyor ve bu hesaplarda parola denetimini doğrudan atlatmıyor. Debian, Ubuntu ve Fedora gibi glibc kullanan yaygın dağıtımlar ile PAM üzerinden doğrulama yapan sistemler de aynı davranıştan etkilenmiyor.
Güncelleme ve geçici önlem nasıl uygulanmalı?
OpenSSH Projesi açığı 10.6p2 sürümüyle giderdi. Alpine Linux da desteklenen sürümler için düzeltilmiş paketler yayımladı. Alpine yöneticilerinin paketleri güncelledikten sonra çalışan SSH hizmetini ayrıca yeniden başlatması gerekiyor; yalnızca paketi yükseltmek bellekte çalışan sshd sürecini değiştirmiyor.
Alpine Linux sistemlerinde güncelleme için apk upgrade -U -a, ardından hizmeti yeniden başlatmak için rc-service sshd restart komutları kullanılabilir. Kendi OpenSSH paketini derleyen yöneticilerin 10.6p2 veya daha yeni sürüme geçmesi gerekiyor.
Güncelleme hemen yapılamıyorsa en etkili geçici önlem, SSH parola doğrulamasını PasswordAuthentication no ayarıyla kapatmak. Yöneticilerin ayarı uygulamadan önce SSH anahtarıyla girişin çalıştığını doğrulaması ve mevcut oturumu yeni giriş başarılı olana kadar açık tutması önem taşıyor. SSH hizmetini tamamen kapatmak da saldırı yüzeyini ortadan kaldırıyor.
Yöneticiler olası ihlali nasıl incelemeli?
Sistem yöneticileri SSH günlüklerinde parolası kapalı hesaplar için başarılı parola girişlerini aramalı. Alpine Linux’ta /var/log/messages dosyasındaki Accepted password for kayıtları, özellikle alpine, root veya yalnızca anahtarla giriş yapması beklenen hesap adlarıyla birlikte incelenmeli.
Parolasız bir hesap için başarılı parola girişi görülmesi, açığın istismar edildiğine işaret edebilir. Böyle bir bulgu halinde doas kullanım kayıtları, son oluşturulan kullanıcılar, yetkili SSH anahtarları ve dosya değişiklikleri gözden geçirilmeli. Yetkisiz giriş ihtimali kesin olarak dışlanamıyorsa sunucu ihlal edilmiş kabul edilmeli; erişim anahtarları yenilenmeli, hesaplar denetlenmeli ve sistem temiz bir imajdan yeniden kurulma seçeneği değerlendirilmelidir.
Bulut imajları ve kök hesap için risk değerlendirmesi
Varsayılan ayarlarda PermitRootLogin prohibit-password seçeneği, kök hesaba doğrudan parola ile giriş yapılmasını engelliyor. Ancak açık bir kullanıcı hesabının doas veya benzeri yetkilerle kök erişimine yükselmesi, bu korumayı dolaylı olarak aşabilecek bir risk oluşturuyor.
SSH hizmeti çalıştırmayan konteynerler, parola doğrulamasını kapatan sistemler, PAM etkin kurulumlar ve parola alanında ! bulunan kilitli hesaplar etkilenmiyor. cloud-init ile yapılandırılıp parola doğrulaması kapatılan bulut sistemleri de risk grubunun dışında kalıyor. Buna karşılık eski tiny-cloud imajlarından çalışan sunucuların paket sürümü ve SSH ayarları gecikmeden kontrol edilmeli.
Sıkça Sorulanlar
CVE-2026-123158 OpenSSH açığı hangi sistemleri etkiliyor?
CVE-2026-123158, musl C kitaplığını kullanan, PAM devre dışı OpenSSH sunucularını etkiliyor. Alpine Linux başta olmak üzere OpenWrt, Buildroot ve Yocto tabanlı belirli kurulumlar, SSH parola doğrulaması açıksa risk taşıyabiliyor.
SSHole açığı nasıl istismar ediliyor?
Saldırgan, parolası `*` ile kapatılmış hedef hesabın adını biliyorsa 257-1024 karakter uzunluğunda parola gönderiyor. musl'un hata durumunda `*` döndürmesi, belirli OpenSSH yapılandırmalarında başarılı parola doğrulaması gibi yorumlanabiliyor.
OpenSSH açığı için hangi güncelleme uygulanmalı?
Açık OpenSSH 10.6p2 sürümünde giderildi. Alpine Linux yöneticileri paket güncellemesinden sonra `sshd` hizmetini ayrıca yeniden başlatmalı; çalışan hizmet güncelleme sırasında otomatik değişmiyor.
Güncelleme yapılamıyorsa hangi önlem alınmalı?
SSH sunucusunda `PasswordAuthentication no` ayarıyla parola doğrulaması kapatılmalı ve SSH hizmeti yeniden başlatılmalı. Ayar öncesinde SSH anahtarıyla girişin çalıştığı doğrulanmalı.
Sunucuda istismar belirtisi nasıl aranır?
Yöneticiler SSH günlüklerinde parolası kapalı hesaplar için görünen `Accepted password for` kayıtlarını incelemeli. Şüpheli kayıt saptanırsa yetkili anahtarlar, yeni kullanıcılar, dosya değişiklikleri ve yetki yükseltme kayıtları denetlenmeli; ihlal olasılığı dışlanamıyorsa sistem ele geçirilmiş kabul edilmeli.