Sıfır gün açıkları, güvenlik dünyasının en zor senaryolarından biri. Normalde bir açık bulunur, üreticiye bildirilir, yaması hazırlanır ve kullanıcılar güncelleme yapar. Sıfır gün açıklarında ise bu sıra bozulur; üretici daha çözüm hazırlayamadan saldırganlar açığı kullanmaya başlayabilir.
Bilgisayarınızda kullandığınız Google Chrome’da, şirketteki Windows Server’da, sunucudaki Linux kernelinde, cPanel’de veya kullandığınız bir muhasebe programında da güvenlik açığı olabilir. Ortak nokta, yazılımın dışarıdan aldığı veriyi doğru ele alamadığı bir anın bulunmasıdır.
Zero-day ya da sıfır gün açığı, üreticinin henüz bilmediği veya kapatmak için elinde kullanılabilir bir yama bulunmayan güvenlik açığıdır. Açığın saldırıda kullanılması zero-day saldırısı, bunun için geliştirilen yönteme de exploit denir.
İsmi biraz dramatik gelebilir ama mantığı basit: üreticinin sorunu çözmek için sıfır günü vardır. Yama çıkana kadar geçen sürede saldırganın yöntemi çalışıyorsa, güvenlik ekibinin de kullanıcının da hareket alanı daralır.
Her kritik açık zero-day değildir
Her CVE kaydı, her yüksek önem dereceli açık veya “acil güncelleyin” denilen her sürüm zero-day değildir. Bir açık üreticiye önceden bildirilmiş, incelenmiş ve yaması hazırlandıktan sonra açıklanmış olabilir. Bu yine ciddiye alınması gereken bir sorundur; ama zero-day demek doğru olmaz.
Bu ifadeyi kullanabilmek için açığın üreticinin bilgisi dışında kaldığının veya yama çıkmadan önce saldırıda kullanıldığının doğrulanması gerekir. Duyurudaki başlığa bakıp panik yapmak yerine neyin etkilendiğine, istismar için hangi şartların gerektiğine ve yamanın hazır olup olmadığına bakmak gerekir.
Yakın dönemde dikkat çeken açıklar
cPanel kullanan sunucularda durum
cPanel tarafında her güvenlik sorunu uzaktan kod çalıştırma şeklinde ortaya çıkmıyor. Panel; hesap, e-posta, dosya, DNS ve sunucu yönetimi gibi yüksek yetkili işlemleri bir araya getirdiği için, küçük görünen bir yetki doğrulama hatası bile hesaplar arasında etkili olabilir.
Son iki aydaki 134 serisi kayıtlarında bunun birkaç net örneği var. 10 Eylül’de, REGISTER_PROCESS çağrısına sahte bir süreç kimliği verilerek süreç sahipliği kontrolünün aşılmasını engelleyen düzeltme yayımlandı. Aynı sürümde, hesap geri yükleme sırasında başka bir hesaba ait e-posta yapılandırmasının sahiplenilmesini önleyen değişiklik de yer aldı.
24 Ağustos güncellemesinde cPanel arayüzünde 2082 ve 2083 portları için HTTP Basic authentication varsayılan olarak kapatıldı. 23 Temmuz’da ise demo moddaki hesapların yapmaması gereken parola, Ruby on Rails uygulama ve dahili dosya taşıma işlemlerini gerçekleştirebilmesine yönelik yetki sorunları kapatıldı. Temmuz sonu ile ağustos ve eylülde yayımlanan bazı “Targeted Security Release” sürümlerinin ayrıntısı herkese açık paylaşılmadı. Bu da panel güncellemesini, yalnızca CVE numarası gördüğümüzde yapılacak bir iş gibi düşünmemek gerektiğini gösteriyor. cPanel 134 değişiklik kaydı bu örneklerin tamamını içeriyor.
Linux kernel tarafı
Kernel, işletim sisteminin en alt katmanında çalışıyor. Bu yüzden bir kernel açığının etkisi, sıradan bir uygulama hatasından daha farklı değerlendirilmeli. Her kernel açığı internetteki herkese uzaktan saldırı imkânı vermez; bazıları yerel kullanıcı, bazıları sanal makine içindeki kullanıcı veya belirli bir sürücüyle sınırlı olabilir.
Örneğin eylül başında duyurulan CVE-2026-80590, ağ paketlerinin parçalarının yeniden birleştirilmesiyle ilgili. Red Hat kaydında, yetkisiz yerel kullanıcının veya sanal makine içindeki kullanıcının bu durumu tetikleyebileceği belirtiliyor. Bu yüzden her sunucuda aynı risk yok; fakat etkilenen sistemde kernel güncellemesini ertelemek de doğru değil. Red Hat CVE kaydı bunun için iyi bir referans.
Kernel tarafında sürüm numarasına bakıp “benimki eski” veya “benimki yeni” sonucuna varmak yanıltıcı olabiliyor. Ubuntu, AlmaLinux ve Debian gibi dağıtımlar güvenlik düzeltmesini çoğu zaman kendi kernel paketine geri taşır. Kernel.org’daki son numarayı değil, kullandığınız dağıtımın güvenlik duyurusunu takip etmek gerekir. Yeniden başlatma ihtiyacını da güncelleme planına baştan koymak lazım.
WordPress, LiteSpeed, Windows ve Chrome
WordPress tarafında son üç ayda 7.0.2, 7.0.3, 7.0.4 ve 7.1.1 güvenlik sürümleri yayımlandı. Ağustosta duyurduğumuz CVE-2026-64638 için, kullanıcıların güncellemesini tamamlamasını beklerken bilinen saldırı yöntemlerine karşı WAF kuralını test edip devreye aldık. Bu, zamana karşı kazanılmış faydalı bir katman; fakat güncellemenin alternatifi değil.
LiteSpeed Cache for WordPress eklentisi için duyurulan CVE-2026-3129 da farklı bir senaryo. Bu, LiteSpeed Web Server açığı değildi; belirli medya ayarları açık sitelerde ve yetkili kullanıcı rolü bulunan saldırgan senaryosunda etkili olabilen bir eklenti sorunuydu. Düzeltme 7.8 sürümünde daha önce yayımlanmıştı. Duyuru yeni diye yamanın da yeni olduğunu varsaymamak gerekiyor.
Windows Server’da uzaktan erişim, Active Directory, IIS veya dosya paylaşımı; Chrome’da ise her gün açtığımız web sayfalarından gelen içerik saldırı yüzeyi oluşturur. Tarayıcı güncellemelerinin sık gelmesinin sebebi de bu. “Sadece internette geziyorum” dediğimiz uygulama bile güvenlik açısından en kritik yazılımlardan biri olabilir.
Ben açıkları nereden takip ediyorum?
İlk baktığım yer her zaman yazılımın kendi duyurusu ve sürüm notu oluyor. WordPress için resmi güvenlik duyuruları, cPanel için sürüm notları, LiteSpeed için güvenlik blogu, Microsoft için güvenlik güncelleştirmeleri, Chrome için sürüm notları ve kullandığınız Linux dağıtımının güvenlik takip sayfası temel kaynaklar.
CVE kayıtları açığın teknik kimliğini ve referanslarını bulmak için faydalı. Açığın aktif olarak saldırıda kullanıldığı doğrulanmışsa CISA’nın Known Exploited Vulnerabilities (KEV) kataloğu ayrıca bakılması gereken yerlerden biri. Gündemi hızlı takip etmek için The Hacker News ve BleepingComputer’ı da izliyorum. WordPress eklenti ve tema tarafında Wordfence ile Patchstack erken uyarı için yararlı; ama işlem yapmadan önce üreticinin duyurusuyla doğrulamak en sağlıklısı.
Hosting veya sunucu hizmeti kullanıyorsanız sağlayıcınızın duyurularını da takip edin. Veridyen’de kritik bir duyuru geldiğinde önce kimlerin etkilenebileceğini kontrol ediyor, mümkün olan durumlarda aynı gün koruyucu aksiyon veya güncelleme planı oluşturmaya çalışıyoruz. Yine de kendi sunucunuzdaki panel, işletim sistemi, uygulama ve kullanıcı hesaplarının güncel kalması sizin sorumluluğunuzda.
Yapay zekâ bu işi hızlandırıyor
Yapay zekâ büyük kod tabanlarını, sürüm değişikliklerini ve benzer hata örneklerini daha hızlı tarayabiliyor. Bu, güvenlik ekiplerinin bazı açıkları daha erken fark etmesine yardımcı oluyor. Aynı hızdan saldırganların da yararlanabildiğini unutmamak gerek.
Bu nedenle güncelleme işi “ayın sonunda bakarız” denecek bir bakım kalemi değil. Gereksiz eklenti ve servisleri kaldırın, uygun yerlerde otomatik güncellemeyi açın, yedek alın ve o yedeği gerektiğinde geri yükleyebildiğinizden emin olun.
