Kısaca
- 21 Ekim 2026’da PHP’deki iki kritik açık için düzeltme yayımlandı; Securelist’in analizine göre açıklar uygulama koduyla kapatılamıyor, tek düzeltme yolu sunucudaki PHP’nin güncellenmesi.
- Habertürk’e göre bu açıkları bulan araştırmacılar yapay zeka modelleri kullanmış; Google ise yapay zeka ile geliştirildiğine inandığı bir sıfırıncı gün sömürüsü kullanan saldırganı ilk kez tespit ettiğini yazıyor.
- Temel önlemler gerekli ama her katmanı kapsamıyor; bir aksaklık durumunda işinizin ne kadar çabuk toparlanacağını, kaliteli bir yedek belirler.
Bu hafta PHP’deki iki kritik açık, ENISA ve diğer AB kurumlarının ortak açıklamasına konu oldu. Bir mağaza yöneticisinin ya da IT ekibinin bunu önceden görmesi pek mümkün değil. Temanız, eklentiniz, parolalarınız ve yetkileriniz kusursuz olsa bile düzeltmenin yapılacağı yer çoğu markada sizin yönetmediğiniz bir katman. Bu yüzden suçlu aramak yerine, açık çıktığında işin ne kadar çabuk toparlanacağına bakmak daha faydalı.
Düzeltme Sizin Katmanınızda Değildi
AB kurumlarının 21 Ekim tarihli ortak açıklamasına göre iki açık, kimlik doğrulaması olmadan uzaktan kod çalıştırmaya izin veriyor. Securelist’in analizine göre açıklar uygulama koduyla kapatılamıyor, tek düzeltme yolu sunucudaki PHP’yi güncellemek. Yani mağaza yazılımınızı güncel tutmanız tek başına yetmiyor.
Hemen güncelleme yapılamıyorsa ortak açıklama internete açık uygulamaları izole etmeyi, Securelist ise sunucu düzeyinde geçici önlemleri öneriyor. Bunlar barındırma (hosting) firmasının yapacağı işler.
Düzeltme 21 Ekim’de çıktı. Sizden beklenen açığı görmek değil, mağazanızın dayandığı katmanları yönetenlere doğru soruları sormak.
Yapay Zeka İki Tarafta da Kullanılıyor
Habertürk’e göre Calif ilk açığı OpenAI’ın GPT-5.6 Sol modelini kullanarak bulup 11 Ağustos’ta PHP geliştiricilerine bildirdi; Wiz ise yapay zeka modelleriyle ikinci açığı bağımsız olarak bulup 24 Ağustos’ta bildirdi. Yani bu açıkları bulanlar, yapay zeka modellerinden yararlanan güvenlik araştırmacılarıydı.
Karşı tarafta da yapay zeka kullanıldığına dair bir örnek var. Google Threat Intelligence Group 11 Mayıs 2026’da yayımladığı raporda, yapay zeka ile geliştirildiğine inandığı bir sıfırıncı gün (zero-day) sömürüsü kullanan bir tehdit aktörünü ilk kez tespit ettiğini yazdı. Google’a göre aktör bunu geniş çaplı bir saldırıda kullanmayı planlıyordu ve Google’ın önceden fark etmesi bunu engellemiş olabilir.
Bence bu tür haberleri önümüzdeki dönemde daha sık duyacağız. Bu benim tahminim, kaynaklarda böyle bir rakam yok. Gerekçem şu: açık aramayı hızlandıran yapay zeka araçlarını savunanlar kullandığı gibi, Google’ın tespit ettiği örnekte olduğu üzere saldırganlar da kullanabiliyor. Açığı siz bulamayacaksınız ama barındırma firmanıza yamayı ne kadar çabuk uyguladığını sorabilirsiniz. Ben bunu korku değil, hazırlık hatırlatması olarak okuyorum.
Temel Önlemler Gerekli, Ama Yetmiyor
Güncellemeleri zamanında yapmak, güçlü ve herkes için ayrı parolalar kullanmak, yetkileri sınırlamak, mümkünse iki adımlı doğrulamayı açmak işi zorlaştırır ve vazgeçilmez. Ama PHP örneği gösterdi ki önlem alınacak katmanın bir kısmı sizde değil.
Müşterinin gözünden tablo basit: açığın nerede çıktığını bilmez, PHP’nin ne olduğunu da bilmez ve haklı olarak sizi muhatap alır. Temel önlemleri bırakmayın, ama arkasına bir toparlanma planı da koyun.
Yedek Açığı Kapatmaz, Ama Toparlanma Süresini Belirler
Burada yedek devreye giriyor. Baştan söyleyeyim: yedek açığı kapatmaz, sızan veriyi de geri getirmez. Görevi, bir şey ters gittiğinde işinizin devam edebilmesini sağlamak. Her aksama da saldırıdan gelmez; yanlış bir güncelleme, barındırma tarafında bir arıza ya da yanlışlıkla silinen ürünler de aynı yedeğe ihtiyaç doğurur. Yedeğiniz bir hafta öncesine aitse, o günden sonra gelen siparişlerin kaydı ve yeni müşteri kayıtları da gider. Bu yüzden önce yedeğinizin ne sıklıkla alındığını öğrenin.
Bir E-Ticaret Yöneticisi Ne Yapmalı?
Hemen yapabileceğiniz ve alışkanlık haline gelmesi gereken beş şey:
- Barındırma firmanıza ya da altyapı sağlayıcınıza sorun: PHP sürümü güncel mi, yama uygulandı mı, yedeği kim alıyor, ne sıklıkla? ENISA’nın ortak açıklaması da barındırma ve hizmet sağlayıcılarla koordineli çalışmayı öneriyor.
- Yedek otomatik ve düzenli çalışsın, gerektiğinde en az yedi gün geriye dönebilin.
- Bir kopya ana sistemden ayrı dursun; yerinde ve uzak kopyalar birlikte kullanılsın, ayrıca çevrimdışı bir kopya da bulunsun. Sunucuyla aynı yerde duran yedek, sunucuyla birlikte gidebilir.
- Geri yüklemeyi deneyin. Yedeğin var olması yetmez, işe yaradığını görmeniz gerekir. Bir kopyayı test ortamına geri yükleyip sitenin açıldığını, siparişlerin ve ürünlerin yerinde olduğunu görün ve bunun ne kadar sürdüğünü ölçün.
- “Bir gün kapalı kalırsak” planını yazın: kimler bilgilendirilir, müşteri hizmetleri ne söyler, siparişlerin kaydı nasıl kontrol edilir. Kampanya dönemlerinden önce bir kere gözden geçirin.
Mağazanın dayandığı katmanların çoğunu (barındırma, PHP sürümü, sunucunun işletim sistemi) başkaları yönetiyor ve bu hafta gördüğümüz gibi, orada çıkan bir açığı çoğu zaman siz kapatamıyorsunuz. Güvenliği sıfır riske indirmek elimizde değil, o yüzden elimizdekine, yani toparlanma süresine odaklanmak gerekiyor.
Her açığı kapatamazsınız, ama bir açığın işinizi ne kadar sekteye uğratacağını belirleyebilirsiniz.
Yedek konusunda çoğu zaman “hosting zaten alıyordur” denir ve yedek ilk sorunda sınanır. Bunu ilk sorunu beklemeden yapın: bu hafta bir kere geri yüklemeyi deneyin, yedeğinizin gerçekten işe yarayıp yaramadığını ancak o zaman öğrenirsiniz.
E-ticaret marka yolculuğunuz üzerine konuşabilir, tanışabiliriz.
Ücretsiz randevu planlayabilirsiniz.
Kaynaklar
- Joint statement on critical PHP vulnerabilities — ENISA ve AB kurumları (21 Ekim 2026)
- Description of PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619 (PHP2Shell) — Securelist (Kaspersky)
- PHP ve dünyayı alarma geçiren ‘PHP2Shell’ açığı nedir ve durum ne kadar kritik? — Habertürk
- Read our new report on AI-powered threats and our latest defenses — Google Threat Intelligence Group (11 Mayıs 2026)
- Back Up Business Data — CISA
