Symlink Sorunları Neden Eski Ama Hâlâ Tehlikeli?
CVE-2026-29203, unsafe symlink handling başlığı altında değerlendirilen bir cPanel güvenlik riskidir. Symlink, Linux sistemlerde bir dosya veya dizine işaret eden bağlantıdır. Normal kullanımda faydalıdır; fakat paylaşımlı hosting ortamlarında yanlış ele alındığında kullanıcı izolasyonunu zayıflatabilir. Bir kullanıcının kendi alanından çıkıp başka bir dosyanın izinlerini etkilemesi, beklenmeyen dosya üzerinde chmod davranışı oluşturması veya servisleri zor durumda bırakması ciddi sonuçlar doğurur. Bu tip açıklar bazen doğrudan veri çalma gibi görünmez; ancak denial of service, bilgi sızıntısı veya yetki yükseltme zincirlerinin parçası olabilir.
Paylaşımlı hostingin temel güvenlik vaadi şudur: aynı fiziksel veya sanal sunucuda yüzlerce müşteri yaşar ama her müşteri kendi sınırında kalır. Symlink davranışı bu sınırı zorlayabilecek klasik alanlardan biridir. Web uygulamaları, cache dizinleri, geçici upload klasörleri, yedekler ve kullanıcı home dizinleri bir araya geldiğinde yanlış izin veya yanlış path takibi büyük problem yaratabilir. Bu nedenle symlink güvenliği, sadece eski Apache döneminden kalma bir konu değil, modern cPanel ve CloudLinux ortamlarında da düzenli kontrol edilmesi gereken bir başlıktır.
chmod Riski Ne Anlama Gelir?
Bir dosyanın chmod değeri, kimlerin okuyabileceğini, yazabileceğini veya çalıştırabileceğini belirler. Eğer bir kullanıcı beklenmeyen bir dosya üzerinde chmod etkisi oluşturabiliyorsa, sistemin izin modeli bozulur. Bazı senaryolarda bu yalnızca bir dosyayı erişilemez hale getirip servis kesintisine yol açar; bazı senaryolarda ise normalde kapalı olması gereken bir dosya okunabilir hale gelebilir. Bu yüzden “sadece izin değişmiş” yaklaşımı doğru değildir. İzin değişikliği, Linux güvenlik modelinin doğrudan merkezine dokunur.
cPanel sunucularında bu riskin etkisi, kullanılan izolasyon katmanlarına göre değişir. CloudLinux, CageFS, hardened PHP, suEXEC, PHP-FPM havuzları ve doğru home izinleri hasarı azaltabilir. Fakat panel seviyesinde yamalanması gereken bir açık varsa, bu katmanların hiçbiri tek başına yeterli kabul edilmemelidir. En iyi güvenlik modeli katmanlıdır: üretici yaması, doğru dosya izinleri, kullanıcı izolasyonu, WAF, log izleme ve düzenli audit birlikte çalışır.
Güncelleme ve Sürüm Doğrulama
CVE-2026-29203 için yapılacak ilk iş, cPanel build seviyesini kontrol etmektir. `/usr/local/cpanel/cpanel -V` çıktısı alınmalı ve sistem yamalı dala yükseltilmelidir. Güncelleme için `/scripts/upcp --force` çalıştırılır, ardından aktif build tekrar kontrol edilir. Bu adım özellikle eski işletim sistemi kullanan sunucularda önemlidir. CentOS 7 veya CloudLinux 7 üzerinde kalan makinelerde doğru tier seçimi yapılmadıysa beklenen güncelleme gelmeyebilir. Bu yüzden update kanalı, sadece WHM ekranından değil komut satırından da doğrulanmalıdır.
Güncelleme sonrası web servislerinin, PHP handler’larının ve kullanıcı izolasyonunun bozulmadığı kontrol edilmelidir. Birkaç kritik domain üzerinde PHP çalışması, dosya yükleme, mail gönderimi, cron ve SSL erişimi test edilebilir. Bu testler müşterinin gerçek verisini değiştirmeden yapılmalıdır. Eğer sunucuda yüzlerce hesap varsa örnekleme yapılabilir; fakat root seviyesinde `/home` izinleri, public_html izinleri ve kullanıcı sahiplikleri genel olarak taranmalıdır.
Dosya İzni Audit’i
Symlink ve chmod risklerinden sonra yapılacak en faydalı işlerden biri dosya izin audit’idir. Kullanıcı home dizinlerinde world-writable klasörler, yanlış sahiplikli public_html dizinleri, root sahipliğinde kalmış kullanıcı dosyaları ve herkesin okuyabildiği config dosyaları aranmalıdır. WordPress tarafında `wp-config.php`, Laravel tarafında `.env`, özel PHP uygulamalarında config dosyaları ve eski backup arşivleri özellikle önemlidir. Bir saldırgan doğrudan symlink açığını kullanmasa bile kötü izinli dosyaları bulduğunda aynı sonuca yaklaşabilir.
Audit yaparken kör şekilde chmod -R uygulamak tehlikelidir. Her uygulamanın ihtiyacı farklıdır. WordPress upload dizini yazılabilir olmalıdır, fakat config dosyasının herkes tarafından yazılabilir olması kabul edilemez. Bu yüzden otomatik düzeltme komutları dikkatli kullanılmalı, önce rapor alınmalı, sonra riskli alanlar sınıflandırılmalıdır. Gerekiyorsa müşteriye bilgi verilerek uygulama bazlı düzeltme yapılmalıdır.
CloudLinux ve CageFS Kullanımı
CloudLinux kullanan sunucularda CageFS aktifliği ve kullanıcıların cage içine alınma durumu kontrol edilmelidir. CageFS kapalı kullanıcılar varsa neden kapalı oldukları bilinmelidir. Bazı eski uygulamalar uyumluluk bahanesiyle cage dışına çıkarılır ve zamanla unutulur. Bu, paylaşımlı hosting güvenliğini zayıflatır. LVE limitleri, PHP Selector, alt-php paketleri ve CageFS skeleton güncelliği de genel kontrolün parçasıdır. Güvenlik duyurusu geldiğinde sadece cPanel değil, CloudLinux bileşenleri de güncel tutulmalıdır.
Symlink güvenliğinde web server konfigürasyonu da önemlidir. Apache veya LiteSpeed kullanılıyorsa symlink takip davranışları, kullanıcı izolasyonu ve vhost ayarları gözden geçirilmelidir. Nginx reverse proxy veya özel cache katmanı varsa statik dosya servisinin kullanıcı sınırlarını aşmadığından emin olunmalıdır. Performans için yapılan agresif ayarlar, yanlış yapılandırıldığında güvenlik sınırlarını gevşetebilir. Hız optimizasyonu ile izolasyon arasında bilinçli denge kurulmalıdır.
Yedekler ve Geri Dönüş Planı
Dosya izinleriyle ilişkili bir olayda yedeklerin kalitesi çok önemlidir. Sadece yedek dosyasının var olması yeterli değildir; yedekten dönen dosya izinleri, sahiplikleri ve tarihleri de doğru olmalıdır. Bazı yedek sistemleri restore sırasında izinleri değiştirebilir veya eski hatalı izinleri aynen geri getirebilir. Bu nedenle kritik bir CVE sonrasında yedek restore prosedürü küçük bir test hesabında denenmelidir. Amaç, olay anında panikle ilk kez restore yapmak zorunda kalmamaktır.
JetBackup veya benzeri sistemler kullanılıyorsa admin erişimi, müşteri self-service restore yetkileri ve yedek dizin izinleri kontrol edilmelidir. Yedek arşivlerinin public_html altında veya web’den erişilebilir bir klasörde durması kabul edilemez. Eski migration arşivleri, cpmove dosyaları ve manuel alınmış zipler sıkça unutulur. Güvenlik audit’i sırasında bunlar da kaldırılmalı veya güvenli offsite depoya taşınmalıdır.
Saldırı Sonrası İzolasyon Kontrolü
Symlink ve izin sorunlarından sonra sadece güncelleme yapmak yetmez; hesaplar arası izolasyonun gerçekten çalıştığı küçük testlerle doğrulanmalıdır. Standart bir kullanıcı hesabından başka bir kullanıcının home dizini okunabiliyor mu, sembolik link ile beklenmeyen path takip edilebiliyor mu, geçici dizinlerde başka kullanıcıya ait dosya görülebiliyor mu? Bu testler kontrollü ve izinli şekilde yapılmalıdır. Amaç saldırı yapmak değil, izolasyon iddiasının sahada doğru çalıştığını görmek olmalıdır.
Eğer sunucuda eski hesap taşıma kalıntıları varsa bunlar da kontrol edilmelidir. cPanel migration sonrası `/home/cpmove-*`, kullanıcı dizinlerinde eski `backup-*.tar.gz` dosyaları veya public_html altında “old”, “yedek”, “backup” gibi klasörler kalabilir. Bu dosyalar yanlış sahiplik veya izinle duruyorsa symlink sınıfındaki risklerden bağımsız olarak veri sızıntısına yol açar. Disk temizliği bu yüzden yalnızca performans işi değildir; güvenlik işidir.
Sunucu yöneticileri ayrıca kullanıcı destek taleplerini de izlemelidir. Bir güvenlik güncellemesinden sonra “dosya izinleri değişti”, “site 403 veriyor”, “upload çalışmıyor” gibi talepler artarsa bu durum yapılan düzeltmenin yan etkisini gösterebilir. Bu talepler tek tek değil, ortak kök sebep arayarak incelenmelidir. İyi bir bakım süreci teknik çıktı ile müşteri geri bildirimini birlikte değerlendirir.
İzolasyon kontrolünde otomatik araçlardan faydalanılabilir, fakat sonuçlar körlemesine uygulanmamalıdır. Yanlış sahiplikli dosyaları raporlayan bir script, bazı özel uygulamaların bilinçli ayarlarını da risk gibi gösterebilir. Bu yüzden rapor önce sınıflandırılmalı, yüksek riskli public dosyalar ve kullanıcılar arası okunabilir alanlar öne alınmalıdır. Düşük riskli düzenlemeler bakım penceresine bırakılabilir. Bu yaklaşım hem güvenliği artırır hem de gereksiz kesinti ihtimalini azaltır.
Özellikle ajans ve geliştirici hesaplarında çok sayıda eski proje kalır. Kullanılmayan staging kopyaları, eski domain klasörleri ve unutulmuş test panelleri saldırgan için hazır keşif alanıdır. Symlink başlığı gündeme geldiğinde bu kalıntıları temizlemek de aynı bakımın doğal parçası olmalıdır.
Bu temizlik yapılırken müşteriye ait aktif veriyle arşiv kalıntısı karıştırılmamalıdır. Silmeden önce dosya tarihi, domain eşleşmesi ve son erişim bilgisi kontrol edilir. Gerekirse arşiv müşteriye kapalı bir yedek alanına taşınır. Güvenlik temizliği aceleyle yapılırsa veri kaybı doğurabilir; planlı yapılırsa hem disk rahatlar hem saldırı yüzeyi küçülür.
Sunucu yöneticisinin hedefi müşterinin çalışmasını bozmak değil, gereksiz riski azaltmaktır. Bu yüzden yüksek riskli dosyalar öncelikli, belirsiz dosyalar kontrollü ve not alınarak ele alınmalıdır. Aynı düzenli yaklaşım sonraki bakımlarda güven oluşturur.
Sonuç
CVE-2026-29203, paylaşımlı hosting ortamlarında dosya sistemi izolasyonunun ne kadar hassas olduğunu hatırlatır. Symlink ve chmod davranışları küçük teknik ayrıntılar gibi görünse de kullanıcı ayrımı, veri gizliliği ve servis sürekliliği açısından kritiktir. Doğru müdahale; cPanel’i yamalı sürüme almak, CloudLinux/CageFS durumunu kontrol etmek, home dizinlerinde izin audit’i yapmak, web server symlink davranışlarını gözden geçirmek ve yedek restore güvenilirliğini test etmektir. Bu adımlar düzenli yapılırsa tek bir açık çıktığında tüm operasyon panik yerine prosedürle hareket eder.