Portable OpenSSH 10.6p2, 5 Kasım 2026'da yayımlandı ve sürüm notlarındaki yirmi satırdan biri diğerlerinden çok daha önemli: sshd(8), musl C kütüphanesine karşı derlenmiş ve PAM desteği kapalı Linux sistemlerinde artık şifreyle kimlik doğrulamanın atlatılmasına izin vermiyor.
Proje buna "kritik bir güvenlik geçici çözümü" diyor ve ifade dikkatle seçilmiş. OpenSSH'nin kendi okumasına göre kusur OpenSSH'ye ait değil: "Bu hatanın kök nedeninin sshd'nin dışında olduğunu düşünüyoruz; ancak sshd üzerinden sömürülebiliyor ve orada da önlenebiliyor." Bildirim, bir yapay zekâ güvenlik şirketi olan Wakefield'dan (wakefield.co) Özgün Kültekin'e atfediliyor.
KİMLER ETKİLENİYOR
Etkilenen küme dar ve net; projenin hatayı "niş" olarak nitelemesinin nedeni de bu, "ağır" olarak nitelemesinin nedeni de. Bir makine, sshd'yi musl libc üzerinde çalıştırıyor ve şifreyle kimlik doğrulamayı PAM üzerinden yönlendirmiyorsa kapsam içinde. En bilinen örnek Alpine Linux; geliştiricileri OpenSSH'nin uyarısıyla birlikte kendi uyarılarını da yayımladı. glibc dağıtımları — Debian, Ubuntu, RHEL, Fedora, SUSE ve türevleri — tarif edilen kapsamın dışında. PAM etkin derlemeler de dışında.
Kapsam içinde kalanlar toplamda küçük değil. Alpine, konteyner imajlarının çok büyük bir bölümünün varsayılan tabanı, yönlendirici ve gömülü cihazların tercih ettiği işletim sistemi ve pek çok küçük sunucunun ana sistemi. Bunlardan şifreyle kimlik doğrulaması açık sshd çalıştıran her makine aday. Yalnızca anahtarla kimlik doğrulayan sistemler bu yoldan etkilenmiyor.
NE YAPMALI
OpenSSH geliştiricisi Damien Miller'ın heise online'a aktarılan tavsiyesi net: etkilenen kullanıcılar "DERHAL" şifreyle kimlik doğrulamayı kapatmalı — sshd_config içinde PasswordAuthentication=no ayarlayıp sshd'yi yeniden başlatmalı — ya da yamalanana kadar SSH'yi tamamen devre dışı bırakmalı. Düzeltmenin kendisi 10.6p2. Güncelleme Alpine'de şu anda mevcut; heise, diğer dağıtımların ve pek çok OpenSSH indirme sunucusunun yazı sırasında hâlâ 10.6p1 dağıttığını aktarıyor. Yani sürüm dizinine değil, gerçekten indirdiğiniz ikiliye bakın.
Şüpheli her makinede kısa bir triyaj dizisi:
sshd -V # gerçekten kurulu olan sshd -T | grep -i passwordauthentication # şifre doğrulaması açık mı ldd /usr/sbin/sshd | grep -i musl # hangi libc'ye bağlı
Şifre doğrulaması açıksa ve ikili musl'a bağlıysa sonuç değişmiyor: önce şifre doğrulamasını kapatın, sonra yamalayın.
BU NE KADAR HIZLI OLDU
heise'ye göre OpenSSH projesi sorunu ancak sürümden bir gün önce, bir Wakefield çalışanı bildirdiğinde öğrendi — ve sürümü bu kadar hızlı çıkarmasının nedeni, başka ve kötü niyetli aktörlerin aynı açığı yapay zekâ desteğiyle hızla bulmasından korkmalarıydı. Bu ölçekte kritik bir altyapı için olağanüstü bir süre: OpenSSH 10.6, 6 Ekim 2026'da çıkmıştı; 10.6p2 otuz gün sonra plan dışı bir yama olarak geldi.
ASIL KALICI OLAN KISIM
Sürüm notlarının giriş bölümü, hatanın kendisinden daha önemli. OpenSSH şöyle yazıyor:
"Son dönemde OpenSSH ekibi çok sayıda güvenlik hatası bildirimi aldı; bunların çoğu yapay zekâ modellerinin bulguları ya da yapay zekâ yardımıyla hazırlanmış. Pek çok yapay zekâ raporunun gerçekçi bir tehdit modeli bağlamında güvenlik etkisi taşımadığı görülse de bu raporları memnuniyetle karşılıyoruz; özellikle insan triyajı, analiz, test senaryoları ve hele de önerilen düzeltmelerle birlikte geldiklerinde."
Ardından, projenin yayın biçimini değiştiren paragraf geliyor:
"Yapay zekâ araçlarının tespit ettiği bir güvenlik hatasının ardından bağımsız olarak başka bir araştırmacı tarafından da bulunduğu birkaç durum gördük. Bu, hataları açık kaynak projelere bildirmeyen saldırganların da bu hataları bulabileceğini gösteriyor. Bu nedenle OpenSSH ekibi, şimdilik, düzeltmeleri bir sonraki planlı sürüme kadar biriktirmek yerine daha sık sürüm çıkararak kullanıcılara daha hızlı ulaştıracak."
Düz okunduğunda bu, bakımcı ekibin "ambargo modeli öldü" demesi. Eski hesap — düzeltmeleri biriktir, takvimle yayımla, dağıtımlara paketleme zamanı ver — bir hatanın varlığının açıklanana kadar sessiz kaldığını varsayıyordu. Bir model buluyorsa ve bir yabancı bağımsız olarak buluyorsa, sessizlik artık mevcut değil. OpenSSH'nin cevabı gizlilik yerine hız; bu da gerçek işi dağıtımlara ve artık "yama günü"nün her gün olabileceğini kabul etmesi gereken sistem yöneticilerine kaydırıyor.
10.6p2 değişiklik listesi bu politikayı küçük ölçekte gösteriyor: atlatma düzeltmesinin yanında post-kuantum hibrit imza şeması ssh-mldsa44-ed25519'u izin verilen CA imza algoritması olarak etkinleştiriyor, ChannelTimeout kullanıldığında oluşan bir saniyeden kısa CPU dönmesini gideriyor ve seccomp kum havuzunda restart_syscall(2)'ye izin veriyor (bz4036). Bunların hiçbiri acil değil. Hepsi erken yayımlandı.
AÇIK SORULAR
Yazı sırasında 10.6p2 notlarında bir CVE numarası görünmüyor ve kök nedeni — PAM'siz musl yolunda tam olarak neyin kimlik doğrulamamış bir istemciyi içeri aldığı — kamuya açıklanmadı. Alpine dışındaki musl dağıtımlarının etkilenip etkilenmediği de belirtilmiyor; tarif edilen mekanizma göz önüne alındığında varsaymak yerine kontrol etmek gerekiyor. Bu boşlukların hepsi "henüz belgelenmedi" diye okunmalı, "gerçek değil" diye değil.
DOĞRULAMA
sshd çalıştıran her makinede:
sshd -V sshd -T | grep -i passwordauthentication ldd /usr/sbin/sshd | grep -i musl
Özellikle Alpine'de: apk info -v openssh, ardından apk upgrade openssh, sonra sshd -V ile p2 derlemesini doğrulayın. Yamadan önce şifre doğrulamasının kapalı olduğunu, yeniden başlatmadan sonra da kapalı kaldığını teyit edin. Bugün yamalayamıyorsanız, geçici çözüm tek satır ve tek servis yeniden başlatması.
