Artık Resmen PHP'siziz. İşte Ekim'in Bize (Şimdilik) Öğrettikleri
19-24 Ekim 2026 haftası, Pazartesi'den Cumartesi'ye, sektör genelinde art arda ciddi güvenlik haberleri getirdi. Kaçırdıysanız, o haftaya ilişkin değerlendirmemiz ayrıntıları içeriyor. Kısa özet: birkaç vakada saldırganlar düzeltmelerden önce harekete geçti.
Böyle bir hafta bizi çizim masasına geri göndermez, ama masada zaten duran çizgileri keskinleştirir. Bir ilkeyi savunmak başka şeydir, o ilkenin eksik olduğu yerlerde neler yaşandığını vaka vaka izlemek başka. Bu yüzden teknik adımları sıralamak yerine, çalışırken bağlı kaldığımız ilkeleri açıklamak istiyoruz; çünkü bir müşteri olarak sizin için yaklaşım, herhangi bir tekil güncellemeden daha önemlidir. Bu ilkelerden biri de az önce dönüm noktasına ulaştı: artık resmen PHP'siziz.
Olay sonrası yama uygulamak neden kaybedilen bir yarıştır?
Yıllarca standart tavsiye basitti: hızlı yama yapın, sorun yaşamazsınız. Eğilim bu tavsiyenin aleyhine zaten işliyordu. Google'ın Mandiant ekibi, bir güvenlik açığının bilinir hale gelmesi ile istismar edilmesi arasındaki ortalama süreyi ölçtü: 2018-2019 döneminde 63 gün, 2021 ve 2022 boyunca 32 gün, 2023'te ise beş gün; aykırı değerler çıkarılarak alınan ortalamalar.
Beş gün, yapay zeka araçlarının günlük yazılım işinin parçası haline gelmesinden önceki 2023 rakamıdır. Bu ay ise bize, 21 Ekim 2026 tarihli PHP2Shell açıklaması etrafında üç farklı gözlem noktasından alınmış taze bir yarış ölçümü verdi.
Amazon'un tehdit istihbaratı ekibi 17 Ekim'de, yani kamuoyuna açıklanmadan dört gün önce bir PHP2Shell istismar girişimi gördü ve ambargo kalkıp yama yayımlandığında saatler içinde daha fazla kavram kanıtı istismarın ortaya çıktığını söylüyor. F5 Labs, ilk PHP2Shell taramasını iki CVE (yaygın güvenlik açığı kaydı) yayımlanmadan beş saatten fazla önce gördü ve açıklamadan saatler sonra sensörleri binlerce istismar girişimi kaydediyordu. Cloudflare'in CEO'su Matthew Prince 22 Ekim'de, Cloudflare'in duyurudan önce binlerce, duyuruyu izleyen 45 dakikada on binlerce, iki saat içinde yüz binlerce ve kendisi paylaşımı yaptığı sırada milyonlarca girişim gördüğünü söyledi. Bunlar doğrulanmış sızmalar değil girişimlerdi, ama kapıların ne kadar hızlı yoklandığını gösteriyorlar: pencere artık dakikalar ve saatlerle ölçülüyor ve kimileri için bu pencere yama daha ortaya çıkmadan kapandı.
İstismarın ortada hiçbir düzeltme yokken başlaması da bir istisna değil. 2023'te Mandiant'ın izlediği istismar edilmiş güvenlik açıklarının %70'i, 138'in 97'si, sıfırıncı gün (zero-day) açığı olarak istismar edildi, yani henüz hiçbir düzeltme yokken.
İstismar bir yama hazır olmadan başlayabiliyorsa ve bir yamadan dakikalar sonra kitlesel olarak gelebiliyorsa, yama uygulamak, ne kadar disiplinli yapılırsa yapılsın, planın tamamı olamaz. Yalnızca buna güvenen bir savunmacı, çoğu zaman daha başlamadan kararı verilmiş bir yarışa girmiş olur. Bu yüzden yarışın bazen kaybedileceğini varsayıyor ve kaybetme ihtimaline göre tasarlıyoruz. Bu varsayım üç soruya dönüşür. Bir açık ortadayken sistemlerimizin ne kadarı vurulabilir? Bir şey vurulursa ne kadarı kaybedilebilir? Ve bir düzeltme ortaya çıktığında ne kadar hızlı toparlanıp boşluğu kapatabiliriz? Bağlı kaldığımız her ilke bu sorulardan birini yanıtlar ve aşağıdaki her şey bu sorular etrafında düzenlenmiştir.
Yazılımın etrafından yama geçmek yerine onu neden kaldırıyoruz?
İlk sorudan başlayalım: ne kadarı vurulabilir. Her kuruluş kötü yaşlanmış yazılım biriktirir: bakımcıları başka işlere geçmiş araçlar, başka bir şey onlara bağımlı olduğu için eski sürümlerde takılı kalmış bileşenler, kimsenin dokunmak istemediği kod. Yaygın tepki, bu tür yazılımları geçici çözümlere ve güvenlik duvarı kurallarına sarıp en iyisini ummaktır.
Biz farklı bakıyoruz. Güncel tutulamayan yazılım, etrafından yama geçilerek değil, kaldırılarak çözülür. Onu geçici düzeltmelerle yaşatmayız, çünkü bakımı yapılmayan kod üzerindeki geçici bir düzeltme, eninde sonunda tutulamayacak bir sözdür. Bir bileşen ya biz onu çalıştırdığımız sürece güncellenebilir ya da hiç çalışmaz.
Geçici çözümler neden başarısız olur? Çünkü bir geçici çözüm yalnızca zaten bilinen açıkları engeller. Bakımı yapılmayan yazılım, bakımcılarının çekip gittiği gün zayıflık barındırmayı bırakmaz. Araştırmacılar ve saldırganlar yıldan yıla yenilerini bulmaya devam eder ve artık düzeltmeleri yazacak kimse kalmamıştır. Her keşif bir kural daha, bir filtre daha, bir öncekinin üstüne cıvatalanmış bir katman daha gerektirir ve yığın her eklemeyle biraz daha kırılganlaşır. Er ya da geç hiçbir dış katmanın süzemeyeceği bir açık ortaya çıkar veya iki katman birbirine karışır ve koruma sessizce çöker. Geçici çözüm zaman kazandırır; terk edilmiş kodda ise o zamanı harcayacak yararlı bir iş yoktur, çünkü altta yatan sorun asla düzeltilmeyecektir.
Yukarıda anlattığımız, artık dakikalar ve saatlerle koşulan yarışı hatırlayın. Bakımı yapılan yazılıma karşı yarış acımasızca kısadır, ama en azından koşulabilir. Terk edilmiş yazılıma karşı ise ortada yarış yoktur, çünkü yarışı bitirmesi gereken düzeltme asla gelmeyecektir. Yazıya dökülünce bu apaçık görünüyor. Pratikte ise daha zor olan yoldur, çünkü bir şeyi kaldırmak genellikle ona dayanan şeyleri yeniden inşa etmek anlamına gelir. Bu bedeli ödemeye değer buluyoruz. Bir saldırgan, artık var olmayan bir sistemdeki zayıflığı istismar edemez.
Küçük bir saldırı yüzeyi gerçekte neye benzer?
Kaldırmak, vurulabilecek alanı küçültmenin en kestirme yoludur. Bunun arkasındaki daha geniş alışkanlığın teknik bir adı var: saldırı yüzeyini küçük tutmak. Saldırı yüzeyi yalın bir fikirdir: bir saldırganın kilitte anahtar deneyebileceği her yerin toplamı. Dışa açık her hizmet, her üçüncü taraf kütüphane, her eklenti savunulması gereken bir kilit daha demektir. İyi güvenlik tanımımız buradan başlar: en güçlü kod çalıştırmadığınız koddur, en güvenli veri de hiç saklamadığınız veridir.
Bir üçüncü taraf kütüphanenin veya eklentinin gerçekte ne olduğunu düşünün. Bir geliştirici onu projesine aldığında, çoğu zaman ücret almayan bir gönüllü olan bir yabancıya, o kod çalıştığı sürece onu güvende tutması için güvenmiş olur. Kütüphanenin kendi güncellemelerine, kendi güvenlik düzeltmelerine, dikkatini ona vermiş kendi bakımcısına ihtiyacı vardır. O bakımcı ilgisini kaybederse, iş değiştirirse ya da yanıt vermeyi bırakırsa kod çalışmaya devam eder, ama artık kimse onu izlemiyordur. O noktadan sonra bulunan bir açık temelli açık kalır; bu da önceki bölümdeki terk edilmişlik sorununun yan kapıdan içeri girmesidir. Bunu tipik bir uygulamanın bağımlı olduğu çok sayıda bileşenle çarpın, tablo netleşir. Her bağımlılık, hiç tanışmadığınız birinin verdiği küçük bir sözdür ve bu sözlerin bir kısmı sessizce geçerliliğini yitirir. Daha az bağımlılık çalıştırmak, güvenliğinizi daha az yabancıya borçlu olmak demektir.
Oturum açtığınız, ödeme yaptığınız ve uygulamalarımızın konuştuğu sistemler Go ile yazılmıştır. PHP artık yok; PHP uygulamalarının peşlerinden sürükleme eğiliminde olduğu uzun kütüphane, eklenti ve bağımlılık kuyruğu da onunla birlikte gitti.
En kritik sistemlerimiz için Go'yu seçtik, çünkü bağımlılık sorununu dil düzeyinde yanıtlıyor. Go bellek güvenlidir: dil, belleği programcının yerine yönetir ve bu, arabellek taşmaları gibi koca bir hata sınıfını devre dışı bırakır; CISA (ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı), The Case for Memory Safe Roadmaps belgesinde Go'yu bellek güvenli diller arasında sayar. Bu sınıf sanıldığından daha büyüktür: Chromium projesi, ciddi güvenlik hatalarının yaklaşık %70'inin bellek güvenliği sorunları olduğunu tespit ediyor. Go'nun standart kütüphanesi, kriptografi dahil, bir web hizmetinin ihtiyaç duyduğu şeylerin çoğunu kapsar; dolayısıyla bir Go hizmeti daha az üçüncü taraf pakete, yani yabancılardan alınmış daha az söze ihtiyaç duyar. Kriptografi öylesine ciddiye alınır ki Go'nun kendi kriptografi modülü ABD hükümetinin FIPS 140-3 standardına göre doğrulanmıştır, CMVP sertifika no. 5247. Ve daha geniş ekosistemde bir açık ortaya çıktığında, Go güvenlik ekibi bir güvenlik açığı veritabanını derleyip yönetir ve govulncheck aracı yalnızca bir programın gerçekten çağırdığı koddaki güvenlik açıklarını bildirir; bu da uyarıları düşük gürültülü ve eyleme dönük tutar.
Bunun önemi, PHP kurulumlarının ne kadar yaygın ve ne kadar eski olduğundan geliyor. W3Techs, sunucu tarafı dilini bildiği tüm web sitelerinin %69,2'sinin PHP kullandığını, PHP sitelerinin %26,6'sının hâlâ PHP 7'de, %7,7'sinin ise PHP 5'te olduğunu bildiriyor; ölçüm 27 Ekim 2026 tarihli. PHP projesinin kendisi her sürüm dalını iki yıl boyunca hata ve güvenlik düzeltmeleriyle, ardından iki yıl daha yalnızca kritik güvenlik düzeltmeleriyle destekler. PHP 7 ve PHP 5 bu sürelerin tamamını geride bıraktı. Web'in büyük bir bölümü, kendi yapımcılarının artık korumadığı kodla çalışıyor; bu da ilk bölümdeki kaybedilen yarışa gönüllü olarak girmek demektir.
Web sitemiz önceden oluşturulmuş statik sayfalardan ibarettir; siz ziyaret ettiğinizde onları üreten sunucu tarafı kod yoktur. Yalnızca bir dosyadan ibaret bir sayfada saldırılacak pek az şey vardır. Ne kadarı vurulabilir sorusuna yanıtımız budur: elimizden geldiğince azı.
Hakkınızda hangi verileri tutuyoruz?
Küçük bir yüzey, bir saldırganın içeri nasıl girebileceğini sınırlar. İkinci soru ise, günün birinde biri yine de içeri girerse ne bulacağını sorar. Yanıtımız, bulunacak olanı olabildiğince sıkıcı kılmaktır: daha az veri, daha kısa süre tutulan.
Yalnızca bir hesabı çalıştırmak için gerekeni isteriz. Gizlilik politikamız (İngilizce) bunu açıkça sıralar: bir kullanıcı adı, bir e-posta adresi, şifrelenmiş bir parola ve kayıt sırasında kullanılan IP adresi. Ödemeler üçüncü taraf ödeme işlemcileri üzerinden geçer; dolayısıyla kart bilgileriniz bizde değil, bütün işi onları korumak olan uzmanlarda durur.
Zaman içinde olup biteni de sıkılaştırıyoruz. Eski, kullanılmayan hesaplar otomatik olarak silinecek. Var olmayan veri sızamaz, çalınamaz ve talep edilemez. Yıllar önce terk ettiğiniz bir hesap, üzerinde adınız yazılı bir risk olarak ortalıkta durmamalı. Yarış bir gün çitin bizim tarafımızda kaybedilirse, masadaki ödül yapabildiğimiz kadar küçük olmalı.
Aynı mantık bizim dışımızda da geçerli, çünkü başka şirketler de yarışlar kaybediyor. İnsanların başına gelen sızıntıların çoğu, uzun zaman önce üye oldukları mağazalarda, forumlarda ve hizmetlerde gerçekleşiyor. Bu yüzden veri ihlali uyarıları sunuyoruz: Data Breach Scanner, bilinen veri sızıntılarında e-posta adresinizi kontrol eder ve adresiniz ortaya çıkarsa size e-posta gönderir; böylece sızıntı kötüye kullanılmadan parolalarınızı değiştirebilirsiniz.
Yine de bir şey bozulursa ne olur?
Üçüncü sorunun iki yarısı var: toparlanmak ve boşluğu kapatmak. Önce toparlanma. İyi güvenlik planlaması kötü günleri varsayar. Donanım bozulur, tedarikçiler değişir ve bazen doğru hamle, bir altyapı parçasından çekip gitmektir.
Sistemlerimiz, gerektiğinde yeniden kurulabilecek veya başka bir yere taşınabilecek şekilde inşa edilmiştir. Sizin için bu şu anlama gelir: bir arıza ya da standartlarımızı artık karşılamayan bir konum, uzun bir kesintiye dönüşmek zorunda değildir, çünkü etkilenen sistem yeniden kurulabilir veya taşınabilir. Bir ortamın artık yeterince iyi olmadığına karar verirsek, onunla pazarlık etmek yerine onu terk edebiliriz.
Dayanıklılık gösterişli bir nitelik değildir. Çoğunlukla işlerin çalışmaya devam etmesi biçiminde kendini gösterir ve bu çerçevede, kaybedilen bir raundun kaybedilen bir sezona dönüşmesini engelleyen şeydir.
Düzeltmeler sistemlerimize ne kadar hızlı ulaşır?
Üçüncü sorunun diğer yarısı hızdır. Yukarıdakilerin hiçbiri yama ihtiyacını ortadan kaldırmaz; yamanın taşımak zorunda olduğu yükü değiştirir. Küçük bir yüzey ve güncel yazılımla, bir düzeltmeyi uygulamak bir proje değil, rutin bir iştir.
Kuralımız basit: güncellemeler, düzeltmeler ortaya çıkar çıkmaz yayımlanır. Ekim ölçümleri nedenini açıklıyor. İstismar girişimleri bir düzeltmenin yayımlanmasından dakikalar ve saatler sonra, bazen de henüz ortada düzeltme yokken geliyorsa, bekleyen bir düzeltme kimseyi korumaz. Yayımlanmış bir yamayı başlangıç tabancası sayarız. Bir düzeltmenin var olması ile uygulanması arasındaki aralık, yarışın bir savunmacının tamamen kontrol ettiği tek bölümüdür; bu yüzden teslim etmeyi reddettiğimiz bölüm de budur.
Ve yığınımız küçük olduğu için yamalanacak şey de basbayağı azdır; üç sorunun buluştuğu nokta burasıdır: vurulacak ne kadar az şey varsa, boşluk o kadar hızlı kapanır.
Yan yana koyduğumuzda, sorular ve onları yanıtlayan ilkeler şöyle görünüyor:
| Soru | İlkemiz | Sizi neden korur |
|---|---|---|
| Ne kadarı vurulabilir? | Güncel tutulamayan yazılım kaldırılır | Artık var olmayan bir bileşende hiçbir zayıflık hayatta kalamaz |
| Ne kadarı vurulabilir? | Küçük bir saldırı yüzeyi | Daha az hizmet, kütüphane ve eklenti, saldırganın deneyeceği daha az kapı demektir |
| Ne kadarı kaybedilebilir? | Daha az veri, daha kısa süre tutulan | Hiç toplamadığımız ve artık elimizde tutmadığımız şey asla ifşa olamaz |
| Ne kadar hızlı toparlanabiliriz? | Yeniden kurulabilen veya taşınabilen sistemler | Bir arıza ya da kötü bir konum, yamanmaya çalışılmak yerine geride bırakılabilir |
| Boşluğu ne kadar hızlı kapatabiliriz? | Düzeltmeler ortaya çıkar çıkmaz uygulanır | Yayımlanan açıklara istismar edilmeleri için rahat bir pencere tanınmaz |
Tüm bunlar sizin için ne anlama geliyor?
Üç sorunun, hissedebileceğiniz yanıtları olduğu anlamına geliyor. Sizinle hesabınız arasında daha az kod duruyor, dolayısıyla bir şeylerin ters gidebileceği daha az yer var. Verinizin daha azı var oluyor, dolayısıyla en kötü durum bile çok az şey açığa çıkarır. Ve sistemlerimiz yeniden kurulabiliyor, dolayısıyla bizim için kötü bir günün sizin için uzun bir kesintiye dönüşmesi gerekmiyor.
Tüm bunların sınırı konusunda dürüst olacağız. Başta sözünü ettiğimiz yarış, ne bizim ne de bir başkası tarafından güvenilir biçimde kazanılabilir, çünkü açıklar bazen daha varlıkları bilinmeden istismar edilir ve hiçbir mimari bunu değiştirmez. Hiçbir sağlayıcı sıfır risk vadedemez; vadeden, güvenlik değil özgüven satıyordur. Vadedebileceğimiz şey, bir kaybın alacağı biçimdir: az giriş yolu, alınacak az şey ve hızlı bir dönüş yolu. Yarışın her raundunu kazanacağımızı garanti edemeyiz. Bir raundu kaybetmenin size olabildiğince az şeye mal olması için inşa ettik ve tutarlı biçimde tutulan bu sözün, tutulamayacak cüretkâr bir sözden daha değerli olduğunu düşünüyoruz.
Güvenlik aynı zamanda ortak bir çabadır. Kurabileceğimiz en güçlü düzen bile sizin tarafınızdaki iyi alışkanlıklardan güç alır; pratik adımlar istiyorsanız, çevrimiçi güvenliğinizi nasıl artırırsınız (İngilizce) konulu rehberimizle başlayın. Ve ister bizden ister bir başkasından, bir VPN seçiyorsanız sağlayıcıya yalnızca ne sattığını değil, nasıl düşündüğünü de sorun. Alacağınız yanıt, sakin haftalarınızın da gürültülü olanların da nasıl geçeceği hakkında size çok şey söyler.
Yazar hakkında
Le VPN Uygulamaları ve Ürün
Le VPN Product Team; iPhone, iPad, Mac, Windows, Linux, Android, Apple TV, Apple Vision Pro ve Fire TV için Le VPN uygulamalarını geliştirir. Ekip bir şey yayınlandığında burada yazar: yeni bir uygulama, yeni bir platform, yeni bir özellik ve zaman zaman bir işin neden beklenenden uzun sürdüğüne dair bir not. Ürün yazıları, yayımlanmadan önce yayınlanan sürüm ve uygulamanın sürüm notlarıyla karşılaştırılarak doğrulanır.
Le VPN Product Team tarafından yazılan makaleler →