Bir web sitesi yazılımdır. PHP web'inin yarısı güvenlik yaması almayı bıraktı.

---

KISA CEVAP

PHP üzerine kurulu web sitelerinin yaklaşık yarısı, geliştiricilerinin artık yama yayımlamadığı bir sürümü kullanıyor ve bu oran 31 Aralık 2026'da yaklaşık üçte ikiye çıkıyor. Açıkların çoğu çekirdekte değil, eklentilerde. Bu hafta PHP sürümünüzü ve eklenti listenizi kontrol edin. Bunu her ay yapmakla görevli bir kişi yoksa sitenizin bakımını yapan kimse yok demektir.

---

2019'da yayına giren, kırk kişilik bir mühendislik firmasının web sitesini bir serbest çalışan WordPress üzerinde kurdu: bir pazaryerinden alınmış bir tema ve yirmi yedi eklentiyle. Ardından başka bir yerde tam zamanlı bir işe girdi. Site hâlâ açılıyor. İletişim formu hâlâ mesaj gönderiyor. Siteyi devralan finans direktörü, hiçbir şey ters görünmediği için iki yıldır barındırma panelinde oturum açmadı.

Hiçbir şeyin ters görünmemesi tam da sorun. Web sitesi bir kez basılıp bırakılmış bir broşür değildir. Yazılımdır; yazarları düzeltme yayımlamaya devam eden ya da bırakan parçalardan oluşur. Düzeltmeler durduğunda site çalışmaya devam eder. Yalnızca artık korunmaz.

PHP web'inin yarısı artık güvenlik düzeltmesi almayan bir sürümle çalışıyor

PHP, WordPress'i ve çoğu küçük işletme sitesini çalıştırır. W3Techs, sunucu dilini tespit edebildiği web sitelerinin %69,9'unda PHP kullanıldığını belirtiyor.

PHP projesi, her sürümün güvenlik düzeltmesi almayı tam olarak ne zaman bırakacağını yayımlıyor. php.net'e göre 7.4 sürümü 28 Kasım 2022'de, 8.0 sürümü 26 Kasım 2023'te, 8.1 sürümü ise 31 Aralık 2025'te destek sonuna (end of life) ulaştı. Bu tarihlerden sonra o sürümde yeni bulunan bir açık hiçbir zaman düzeltilmez.

Bu sürümleri hâlâ kaç sitenin kullandığını kimse yayımlamıyor, bu yüzden Elevates hesapladı. W3Techs'in 19 Eylül 2026 tarihli sürüm paylarını alın: PHP sitelerinin %28,0'ı 7. sürümde, %7,8'i 5. sürümde, %0,1'i 4. sürümde. 8. sürümü kullanan %64,1'in içinde ise W3Techs'in dökümü %16,1'ini 8.1'de ve %6,2'sini 8.0'da gösteriyor. Hepsini toplayınca PHP web sitelerinin yaklaşık %50,2'si artık güvenlik düzeltmesi almayan bir sürüm çalıştırıyor.

Bu, unutulmuş hobi sitelerinden oluşan bir kenar kesim değil. Küçük işletmelerin internete çıkmasının en yaygın yolunun yarısı.

31 Aralık 2026'da yarı, üçte ikiye dönüşüyor

Destek takvimi durmuyor. php.net, PHP 8.2 için güvenlik desteğinin 31 Aralık 2026'da sona ereceğini gösteriyor. W3Techs, PHP 8 kullanan sitelerin bugün %28,9'unu 8.2'de gösteriyor.

Kimse sürüm değiştirmezse, desteklenmeyen bir sürümdeki PHP sitelerinin payı yılbaşı günü yaklaşık %50'den yaklaşık %68,7'ye çıkıyor. Bu yine Elevates'in hesabı; kaynaklar ve tarih aynı.

Bu tarihlerin her biri yıllar öncesinden duyuruldu. Bakan herkes için hiçbiri sürpriz değildi. Bu tarihleri aşan sitelerde ise bakan kimse yoktu.

Zayıf nokta WordPress değil. Üzerine eklenenler

WordPress, tüm web sitelerinin %40,2'sini çalıştırıyor ve pek çok şey için suçlanıyor. Ancak suç yanlış yere yükleniyor.

WordPress güvenliği satan bir şirket olan Patchstack, ekosistemdeki yeni güvenlik açıklarının yıllık sayımını yayımlıyor. 2026 raporu, 2025'te 2024'e göre %42 artışla 11.334 yeni güvenlik açığı buldu. Bunların %91'i eklentilerde, %9'u temalardaydı. WordPress çekirdeğinde ise düşük öncelikli altı açık vardı.

Yani sitenin en iyi korunan parçası çekirdek. Risk eklentilerde yaşıyor ve her eklenti ayrı bir tedarikçi. İletişim formu bir geliştiriciden, kaydırıcı bir başkasından, çerez bannerı üçüncüsünden, yedekleme aracı dördüncüsünden. Her birinin kendi sürüm takvimi, kendi öncelikleri ve yazarı tarafından terk edilme ihtimali var.

Yirmi yedi eklenti, yirmi yedi tedarikçi demek. Çoğu işletme bunlardan birinin bile adını söyleyemez.

Açıkların neredeyse yarısı, düzeltme gelmeden önce herkese açık hâle geliyor

Rahatlatıcı varsayım, güncellemenin yeterli olduğu: otomatik güncellemeleri açarsınız ve sorun kendiliğinden çözülür. Veriler başka bir şey söylüyor.

Patchstack aynı raporda, güvenlik açıklarının %46'sının kamuya duyurulma anında geliştiriciden bir düzeltme almadığını buldu; bu oran bir önceki yıl %33'tü. Raporun kendi sonucu da şu: site sahipleri "güvenlik önlemi olarak eklenti güncellemelerine güvenemez."

Güncelleme, düzeltmesi olan açıkları kapatır. Yazarı sessizliğe gömülmüş bir eklenti için hiçbir şey yapmaz; bir açığın kamuya duyurulmasıyla yamanın yayımlanması arasındaki günler için de hiçbir şey yapmaz. Bunlar için birinin karar vermesi gerekir: eklentiyi devre dışı bırakmak, değiştirmek ya da riski gözü açık kabul etmek. Otomatik bir güncelleme bu kararı veremez. Bir insanın vermesi gerekir.

Saldırganlar saatler içinde harekete geçiyor. Çoğu site sahibi üç ayda bir

Açığın duyurulması ile saldırı arasındaki süre kısa. Patchstack, etkisi yüksek güvenlik açıklarının kabaca yarısının 24 saat içinde istismar edildiğini buldu. İstismarın yoğunluğuna göre ağırlıklandırıldığında, ilk istismara kadar geçen medyan süre beş saatti.

Şimdi bunu çoğu işletmenin web sitesine nasıl davrandığıyla karşılaştırın. Site, biri şikâyet ettiğinde ya da birkaç yılda bir yeniden tasarım gündeme geldiğinde gözden geçirilir. Beş saatlik bir pencere ile üç yıllık bir gözden geçirme döngüsü bir araya gelmez.

Barındırma firması da güvenlik ağı değil. Patchstack, web uygulaması güvenlik duvarları ve Cloudflare dahil yaygın savunmaları WordPress güvenlik açıklarının gerçek istismarlarına karşı test etti ve bunların WordPress'e özgü saldırıların %12'sini engellediğini bildiriyor. Bunu bir satıcının kendi testi olarak değerlendirin, çünkü Patchstack alternatifini satıyor. Bu rakama büyük bir ihtiyatla yaklaşsanız bile söylediği şey aynı: barındırma firmasının güvenlik duvarı bakım değildir.

"Hâlâ çalışıyor" ile "hâlâ bakımı yapılıyor" aynı şey değil

Eskimiş siteleri çevrimiçi tutan cümle bu. Ana sayfa açılıyor, yani site iyi olmalı.

Yamalanmamış bir site, yamalanmış bir siteyle tıpatıp aynı görünür; ta ki artık görünmediği güne kadar. İlk değişen şey görünmez: kimsenin göz atmadığı bir klasöre enjekte edilmiş bir spam sayfası, yalnızca Google'dan gelen ziyaretçiler için tetiklenen bir yönlendirme, ödeme sayfasına eklenmiş bir betik. Arama motorları ve tarayıcılar bunu site sahibinden önce fark edebilir ve ziyaretçileri uyararak sitenizden uzaklaştırır.

Bir ihlalin ardından üç maliyet gelir ve onarım bunların en küçüğüdür. Birincisi, sitenin biri fark edene kadar başkalarının amaçlarına hizmet ederek geçirdiği zaman. İkincisi güven: alan adınızda tarayıcı uyarısı gören bir müşteri açıklamanızı okumaz. Üçüncüsü hukuki. Site kişisel veri tutuyorsa bir ihlal, GDPR Madde 33 kapsamında bildirim yükümlülüklerini doğurabilir; bildirim süresi, ihlalin farkına vardığınız andan itibaren 72 saattir.

Bu maliyetlerin hiçbiri web sitesinin faturasında görünmez. Hepsini siteye sahip olan işletme öder.

Bu öğleden sonra kimseye ödeme yapmadan neleri kontrol edebilirsiniz

İlk turun çoğu ücretsiz ve kendi başınıza yapabilirsiniz.

• PHP sürümünüzü bulun. Barındırma kontrol paneliniz bunu gösterir, genellikle PHP ayarları ya da yazılım gibi bir başlığın altında. 7 ile başlıyorsa ya da 8.0 veya 8.1 ise artık güvenlik düzeltmesi almıyor. 8.2 ise 31 Aralık 2026'da duruyor.
• Eklentilerinizi sayın. WordPress yönetim panelinde eklentiler sayfasını açın. Kaç tanesinin yüklü, kaç tanesinin etkin olduğunu not edin.
• Etkin olmayanları silin. Etkin olmayan bir eklenti de sunucuda durur ve koduna yine de ulaşılabilir. Orada neden durduğunu kimse söyleyemiyorsa kaldırın.
• Her etkin eklentinin son güncellemesine bakın. Eklenti dizini, her birinin en son ne zaman güncellendiğini gösterir. Bir yıl veya daha uzun süredir dokunulmamış bir eklenti, değiştirilmesi gereken bir eklentidir.
• Bakım ve güvenlik sürümleri için otomatik güncellemeleri etkinleştirin ve yedeklerin gerçekten çalıştığını ve geri yüklenebildiğini kontrol edin. Hiç geri yüklenmemiş bir yedek, yedek değil umuttur.
• Yönetici erişimi olanları yazın. Ayrılan kişilerin hesaplarını kaldırın.

Birçok küçük site için bu bir öğleden sonralık iş ve kolay risklerin büyük bir kısmını kapatıyor. Bir ajansla hiç konuşmayacak olsanız bile bunu yapın.

Öğleden sonranın bittiği yer

Ücretsiz turun bir tavanı var ve ona çabuk ulaşılıyor.

PHP 7.4'ten 8.3'e geçmek, barındırma panelinde bir düğmeye basmak değildir. Eski sürüm için yazılmış kod yenisinde bozulabilir: yeni sürümün kaldırdığı işlevleri kullanan bir tema, bu sürüm için hiç güncellenmemiş bir eklenti. Eski bir sitede düğmeye basmak çoğu zaman boş bir sayfayla sonuçlanır. Bu yüzden yükseltme ertelenir ve site artık düzeltme almayan sürümde kalır. PHP web'inin yarısı bu noktaya böyle geldi.

İşletmenin dayandığı bir işi yapan, terk edilmiş bir eklenti için de aynısı geçerli; rezervasyon formu ya da üye alanı gibi. Onu değiştirmek, o özelliği yeniden kurmak, test etmek ve verilerini taşımak demek. Bu mühendislik işi ve hiçbir kontrol listesi bunu kapsamaz.

Üstelik kontrol listesinin gelecek ay ve ondan sonraki ay yeniden yapılması gerekir. Öğleden sonra bugünü düzeltir. Yarının sorumluluğunu kimseye yüklemez.

Bakımı yapılan bir web sitesi ay ay nasıl görünür

Bakım belirsiz geliyor ve atlanmasının nedeni de bu. Oysa belirsiz değil. Takvimi olan kısa bir rutin ve tek sayfaya sığıyor.

Her ay: çekirdeğe, temaya ve her eklentiye güncellemeleri uygulayın; güncelleme büyük bir sürümse önce sitenin bir kopyası üzerinde. Tüm ekosistemin değil, gerçekten yüklü olan eklentilerin güvenlik duyurularını okuyun. Dün geceki yedeğin mevcut ve eksiksiz olduğunu kontrol edin.

Her çeyrek: bir yedeği bir test kopyasına geri yükleyin ve sitenin ondan çalıştığını doğrulayın. Yönetici erişimi olanları gözden geçirin. Altı aydır güncellenmemiş her eklentiye yeniden bakın ve kalıp kalmayacağına karar verin.

Her yıl: PHP destek takvimini kontrol edin ve bir sonraki sürüm geçişini son tarihten önce planlayın, sonra değil. Alan adını ve sertifikaları, süresi dolmuş olabilecek bir karta değil, adı belli bir kişinin takibine bağlayarak yenileyin. Her eklentinin yerini hâlâ hak edip etmediğini sorun, çünkü güvenliğini sağlaması en ucuz eklenti, yüklü olmayandır.

Düzeltmesi olmayan her güvenlik duyurusunda: bir gün içinde devre dışı bırakma, değiştirme ya da kabul etme konusunda karar verin. Kararı tarihiyle birlikte yazın.

Bunların hiçbiri sıra dışı değil. Her işletmenin muhasebesine ya da araç filosuna zaten uyguladığı disiplinin aynısı: bir takvim, adı belli bir kişi ve bir kayıt. Çoğu sitede eksik olan bilgi değil. Görevin yanındaki isim.

Yazılımın bir lansman tarihi değil, bir sahibi olmalı

Asıl boşluk teknik değil. Sitenin işleyişinin kimsenin sorumluluğunda olmaması.

Web siteleri genellikle bir proje olarak satılır: bir tasarım, bir yapım, bir lansman, bir fatura. İşleyiş sonradan akla gelen bir şey ya da bir barındırma ücreti olarak görülür. Oysa lansman, yazılımın yaşlanmaya başladığı gündür. Ondan sonraki her ay, bir yerlerde bir tedarikçi bir düzeltme yayımlar ya da yayımlamayı bırakır ve birinin bunu fark etmesi gerekir.

Elevates bir siteyi bu şekilde fiyatlandırıyor: yapım bir kez, işleyiş aylık; güncellemelerden, yedeklerden ve erişimden sorumlu, adı belli bir kişiyle. Yapım, bakımı karşılamak için hiçbir zaman yeniden açılmıyor ve bakım hiçbir zaman yapımın içine gizlenmiyor. Kendi sitesi olan elevates.it ise hiç eklenti katmanı olmadan kurulmuş: sayfalar, Elevates'in denetlediği koddan derleniyor; yani baştan izlenecek daha az tedarikçi var.

Mühendislik firmasındaki gibi bir site için dürüst değerlendirme genellikle iki yerden birine varır. Bazen bu, bir öğleden sonralık temizlik, sorunsuz geçen bir PHP yükseltmesi ve firmanın kendisinin yürütebileceği ya da birine devredebileceği aylık bir rutindir. Bunun maliyeti dikkatten başka bir şey değildir ve umut edilecek sonuç budur. Bazen de tema ve eklentilerin yarısı yükseltmeyi kaldıramaz ve seçim, daha az hareketli parçayla yeniden kurmak ile eski bir yığını ödünç zamanda ayakta tutmak için her ay ödeme yapmak arasındadır. Hangisi olursa olsun, tarihler önünüzdeyken bilerek verilmiş bir karar olmalı.

Bu hafta sorulacak soru

Web sitenizle ilgilenen kişiye tek bir soru sorun: site hangi PHP sürümünü çalıştırıyor ve güvenlik düzeltmesi almayı ne zaman bırakıyor?

Cevap, bir tarih ve bir planla birlikte çabucak geliyorsa sitenizin bir bakımcısı var. Soru elden ele dolaşıyorsa ya da cevap "iyi, çalışıyor" ise, o sitenin bir lansman tarihi var ve ondan sonrası yok. Elevates kontrolü sizinle birlikte yapabilir ve hangi sonuçta olduğunuzu söyleyebilir.