Patch Salı Günü'nde Çifte Darbe: cPanel ve Kernel Güncellemelerini Neden Atlayamazsınız

Patch Salı Günü'nde Çifte Darbe: cPanel ve Kernel Güncellemelerini Neden Atlayamazsınız

May 13, 2026 cpanel security linux kernel dirtyfrag cve patching system administration server security vulnerability management infrastructure

Bir Sabah Uyandığınızda: İki Kritik Güvenlik Sorunu

Şunu düşünün: cPanel ile yönettiğiniz bir sunucunuz var ve sabah kalktığınızda hemen iki ayrı güvenlik krizi ile karşı karşıya bulunuyorsunuz. Birinin yaması hazır, diğerinin ise henüz yoktur—ama zaten saldırılar başlamıştır. 8 Mayıs tam olarak böyle bir gündü ve bu da şunu gösterdi: güvenlik hiç kimsenin takvimini takip etmez.

cPanel'in Karşı Karşıya Olduğu Durum: Aynı Günde Üç Açık

cPanel bu sefer daha akıllı bir yol seçti. 28 Nisan'daki kimlik doğrulama açığından (CVE-2026-41940) farklı olarak—o zaten aktif saldırılar altındayken duyurulmuştu—bu kez cPanel önceden uyarı yaptı ama teknik detayları açıklamadı. Sonra da her yazılım satıcısının yapması gereken şeyi yaptı: yama ve açığın bilgilerini aynı anda yayınladı.

Üç CVE bir anda ortaya çıktı: CVE-2026-29201, CVE-2026-29202 ve CVE-2026-29203. Her birinin neden endişe verici olduğuna bakalım:

CVE-2026-29201 (CVSS 4.3 - Orta Seviye) Bu açık, LOADFEATUREFILE adminbin çağrısında giriş doğrulamasının yanlış yapılmasından kaynaklanıyor. Sunucunuzda geçerli bir hesabı olan biri, göreceli bir yol vererek rasgele dosyaları herkesin okuyabileceği şekilde sunabilir. Girilmiş bir hesap gerekir, ama bir kez içerde olan saldırgan, hassas yapılandırma dosyalarına, yedeklere veya başka verilere ulaşabilir.

Daha Geniş Resim Üç açığın ortak noktası belli: hepsi doğrulanmış bir oturum gerektiriyor. Saldırgan zaten sisteminizde olmalıdır. Bu kontrol altına alınmış gibi görünse de, gerçek daha tatsız: 28 Nisan açığının 64 gün boyunca aktif saldırılara açık kaldığı sürede sunucunuz ele geçirildiyse, attığınız farkına varmadığınız anahtarlar zaten birilinin elinde olabilir.

DirtyFrag: Çekirdekten Gelen Beklenmedik Misafir

cPanel yamalarını yayınlarken, Linux kernel ekibi çok daha temel bir soruna çatışıyordu. 7 Mayıs'ta açığa çıkarılan DirtyFrag, 2017 yılından beri çekirdeğin içine gömülü olan bir yerel ayrıcalık yükseltme açığı. Bu zaman çizelgesini bir dakika düşünün.

En kötü kısım? Açık açıklandığında yaması henüz yoktu ve exploit kodu halka açık olarak paylaşıldı. Sunucunuzda hiç bir yetki olmayan, sıradan bir kullanıcı bile root yetkisine yükselebilir. Hizmet hesabı değil, yönetici değil—herhangi bir kullanıcı.

İyi haber kısa sürede geldi: 8 Mayıs'ta ana Linux dağıtımları kernel yamasını kararlı depolarına koydu. Fakat kernel güncellemesi yeniden başlatma demek, yeniden başlatma da kapalı kalma demek. Birden fazla kiracı veya hizmet çalıştıran üretime açık bir sistem için bu hafif alınan bir karar değildir.

Şu Anda Yapmanız Gereken İşler

Birinci Öncelik: cPanel Yama Durumunu Kontrol Edin

28 Nisan kimlik doğrulama açığı (CVE-2026-41940) haftalardır aktif olarak saldırıya uğruyor. Henüz yama yapmadıysanız, bu artık tavsiye değil—zorunluluktur. Fakat zorlu kısım şurası: ön kapıyı kapatmak iyidir, ama o 64 günün içinde birisi girmediyse, arka kapının anahtarları onların cebinde olabilir. Yapmanız gerekenler:

  • Erişim günlüklerinde şüpheli davranışlar için bakın
  • Kritik dosyalarınızın değiştirilmediğini doğrulayın
  • Eğer maruz kalma süresinden emin değilseniz tam güvenlik denetimi düşünün

İkinci Öncelik: Kernel Güncellemesini Planlayın

DirtyFrag ciddi, ama yerel erişim gerektiriyor. İlk risk, uzaktan ve kimlik doğrulamasız bir açıktan daha düşüktür, yine de kritiktir. Kernel yamasını bakım pencerenizde planlayın. Evet, kapalı kalma anlamına gelir, ama alternatifi bilinen bir ayrıcalık yükseltme açığını açık bırakmaktır.

Üçüncü Öncelik: Yamaları Doğrulayın, Sadece Dağıtmayın

Güncelle butonu basıp devam etme cazibesine kapılmak kolaydır. Bunu yapmayın. Yamaları önce test ortamında sınayın. Güvenlik yamasının başka bir şeyi çalışmaz hale getirdiği durumları gördük. Bir saat test, üç saat bozuk sunucu tamir etmekten daha iyi çıkar.

Açıklamalar Hakkında Biraz Düşünce

cPanel'in bu kez farklı yöntem seçmesi—detay vermeden ön uyarı, sonra her şeyi aynı anda açıklamak—dikkat değer. Aslında akıllıca. Yöneticilere hazırlanma zamanı verir, saldırganlara harita vermez. Bunu CVE-2026-41940 ile kıyaslayın: hiç uyarı olmadı, saldırılar zaten başlamıştı. Ders şu: açıklamanın zamanlaması çok önemlidir.

Neden Bu 8 Mayıs'tan Önemli

Bu iki eş zamanlı açık, geliştirici ve altyapı ekiplerinin içselleştirmesi gereken bir şeyi vurgularlı: güvenlik çok katmanlı bir sorunudur. Uygulamayı yamayıp güvenli olduğunuzu düşünemezsiniz. Çekirdeği güncelleyip işi bitiştiremezsiniz. Her iki katman da önemlidir, her ikisinin de ilgiyi alması gerekir.

Daha da önemlisi, DirtyFrag gibi açıklar—yıllardır gözümüzün önünde gizli olan—bize güvenliğin bir devam eden süreç olduğunu hatırlatır. "Yamadı, unut" diye bir şey yoktur. Binlerce bileşenden inşa edilmiş bir sistem çalıştırıyorsunuz, her birinin kendi bakım döngüsü ve açıklama takvimi var.

Yamalamayı Daha Az Zorlu Hale Getirmek

NameOcean ile barındırma yapıyor veya kendi cPanel altyapısını yönetiyorsanız, bunu daha iyi yama yönetim uygulamalarına doğru nazik bir işaret olarak alın:

  • Yapabildiğiniz yerleri otomatikleştirin. Çoğu sistemde kernel güncellemeleri, uygulamanız ara sıra yeniden başlatmaya toleranslı ise güvenli şekilde otomatikleştirilir.
  • Stack'inizdeki bilinen CVE'leri izleyin. Yeni açıklar gelmeden önce sizi uyaracak araçlar mevcuttur.
  • Her zaman test ortamında deneyin. Her defasında. Her tek defasında.
  • Ne yamadığınızı ve ne zaman yamadığınızı not edin. Bir olay yaşandığında bu bilgiler altın değerini taşır.

8 Mayıs'taki çifte sorun benzersiz değildir—yeni normal haline geldiği görülüyor. Birden çok kritik açık, farklı seviyeler, farklı takvimler. Bu çağda ayakta kalan altyapı, yamalamayı üç ayda bir yapılan bir görev değil, sürekli bir süreç olarak gören altyapıdır.

Uyanık kalın.

Read in other languages:

RU BG EL CS UZ SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS EN