Açığı Yapay Zeka Buldu, Yama Birçok Siteye Ulaşmayacak: PHP2Shell'in Türkiye'deki KOBİ'ler İçin Anlamı

21 Ekim 2026'da PHP acil bir güvenlik sürümü yayımladı. Konu, PHP2Shell adı verilen iki kritik açık: CVE-2026-109618 ve CVE-2026-109619. Resmi önem puanı 10 üzerinden 9,2. Yamalı sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. PHP 8.1 ve daha eski sürümlere resmi yeni sürüm gelmeyecek. PHP ekibi 7.4, 8.0 ve 8.1 için yalnız kaynak kod yaması yayımladı; onu uygulamak hosting firmasına kalıyor. 7.3 ve öncesi için o da yok.

Bu kadarını her teknoloji sitesi yazdı. Benim için asıl haber başka yerde. Bu açığı bulan araştırmacıların elindeki asıl araç bir yapay zeka modeliydi. Yama ile saldırı arasındaki süre son yıllarda haftalardan günlere indi. Ve baktığımız KOBİ sitelerinin önemli bir kısmı, PHP'nin artık yeni sürüm çıkarmadığı eski sürümlerde çalışıyor. Üç cümle, üç ayrı tez. Sırayla gidelim.

Yıllardır bilinen bir hata neden şimdi bulundu?

İlk hatayı güvenlik firması Calif'te çalışan bir araştırmacı, OpenAI'ın GPT-5.6 Sol modeliyle buldu. Tarih 1 Ağustos 2026. Çalışma, OpenAI'ın "Patch the Planet" programı kapsamında yürütülüyordu. Bildirim 11 Ağustos'ta PHP ekibine ulaştı. 18 gün sonra, 19 Ağustos'ta, Wiz aynı açığı yine yapay zeka araçlarıyla ve tamamen bağımsız olarak buldu.

İki ayrı ekip, aynı hata, aynı yöntem. Bu bir rastlantı değil, bir yöntem değişikliğinin işareti.

Calif CEO'su Thai Duong, Wall Street Journal'a verdiği demeçte dikkat çekici bir ayrıntı paylaştı: bu hata türü yıllar önce fark edilmişti. Sömürmesi zor diye bir kenara konmuştu. Yani sorun bilinmiyor değildi. Sorun, onu çalışır hale getirmenin bir insana pahalı gelmesiydi.

Güvenlik dünyasında bu tür bir birikim var. Herkesin bildiği ama kimsenin uğraşmadığı hatalar. Uğraşmak haftalar alır, sonuç belirsizdir, araştırmacının vakti daha kolay hedeflere gider. Bu hatalar silinmez; beklemeye alınır.

Yapay zeka tam olarak bu bekleme maliyetini düşürdü. "Zor" olan şey "ucuz" oldu. Yıllardır rafta bekleyen hatalar bir anda rafın en önüne geçti. Bu açık, bu şekilde bulunan ilk açık değil; son da olmayacak. Açıkların bulunma hızı artık araştırmacının sabrıyla değil, kullanılan modelin yetenekleriyle sınırlı.

Yama çıkınca neden daha güvende değiliz?

Sezgi şunu söyler: yama yayımlandı, tehlike azaldı. Gerçek şu: yama yayımlandı, saat başladı.

Duong aynı röportajda bunu açıkça söyledi. Yama çıktığı anda birileri, yamanın kendisinden yola çıkarak yapay zekayla saldırı kodu üretebilir. Yama bir düzeltmedir ama aynı zamanda bir haritadır. "Burası değişti" der. Neyin değiştiğini okuyan biri, neyin kırık olduğunu da anlar.

Eskiden bu okuma günler, bazen haftalar sürerdi. Şimdi saatlerle ölçülüyor. Bulma tarafında yapay zeka varsa, kullanma tarafında da var. Aynı araç, iki yön.

Bu olayda zamanlama daha da sıkıştı. Açığın haberi, 20 Ekim'de anonim bir Hacker News gönderisiyle ambargodan önce sızdı. PHP ekibi yayını bir gün öne çekmek zorunda kaldı. Ön duyuru ile yama arasında bir günden kısa süre kaldı. Yamanın kamuya açıldığı an ile saldırının mümkün olduğu an arasındaki fark bu kez neredeyse sıfırdı.

Bu pencere eskiden işletmelerin lehineydi. Yama çıkar, hosting firması birkaç hafta içinde uygular, kimse farkına varmazdı. O birkaç hafta artık yok. Yama uygulanana kadar geçen her gün, eskisinden daha pahalı.

Bir not: dolaşımdaki 'CVSS 10' iddiası doğru değil; resmi puan 10 üzerinden 9,2. 'Sitelerin yüzde 70'i' rakamı ise PHP'nin web sitelerindeki payından geliyor ve PHP ekibi web isteğine yanıt veren bütün PHP kurulumlarını risk altında sayıyor. Abartıya gerek yok, gerçek zaten yeterince ciddi.

WordPress güncel, site neden hâlâ açıkta?

Çoğu işletme sahibinin ilk refleksi WordPress panelini açıp güncellemelere bakmak olacak. Tema güncel, eklentiler güncel, çekirdek güncel. Rahatlama.

Yanlış yer.

Bu açık WordPress'te değil, WordPress'in üzerinde çalıştığı PHP'de. WordPress'i ya da eklentileri güncellemek bu açığı kapatmaz. Düzeltme sunucu tarafında, yani hostingi yöneten kişide. Panelden ne kadar güncelleme yaparsanız yapın, altta çalışan PHP sürümü aynı kalıyorsa sorun da aynı kalıyor.

Burada bir sorumluluk boşluğu var. Site sahibi "ben güncelledim" diyor. Hosting firması "sürümü müşteri seçiyor" diyor. Web tasarımcı "ben sadece temayı yaptım" diyor. Herkes haklı, kimse sorumlu. Açık ise bu üç kişinin tam ortasında duruyor.

Çoğu Antalya'dan 2.810 site ne söylüyor?

Bu yazıyı genel bir uyarı olarak bırakmak istemedim. 21 Ekim'de, çoğu Antalya'dan 2.810 işletme sitesinin kamuya açık sunucu yanıtlarına baktık. Sadece dışarıdan görünen bilgi, içeri girmeden. Bir tarayıcının her ziyarette zaten aldığı bilgi.

Sitelerin bir kısmı PHP sürümünü açıkça gösteriyor. Bu 458 sitenin 275'i, yani yüzde 60'ı, PHP 8.1 ya da daha eski bir sürümde çalışıyor. PHP bu sürümlere yeni sürüm çıkarmayacak. 275 sitenin 108'i 7.3 ve öncesinde; bunlar için PHP ekibinin kaynak kod yaması bile yok. Kalan 167 site ancak hosting firması yamayı kendisi uygularsa korunuyor ve bunu dışarıdan görmek mümkün değil.

Açılan 2.216 sitenin geri kalanı sürümünü göstermiyor; 492 site hiç açılmadı, 71'inin sertifikası bozuk, 31'i sunucu hatası verdi. Gizlemek doğru bir uygulama ama bizim için kör nokta. Sürümü gizlemek ile sürümü yükseltmek ayrı işler; gizleyen sitelerin güncel olduğunu varsaymak doğru olmaz. Ama gerçek oranı bu ölçümle bilemeyiz: sürümünü gösteren siteler bütünü temsil etmeyebilir ve bazı hosting firmaları eski sürüme yamayı numarayı değiştirmeden uyguluyor.

Bu ölçüm bir güvenlik taraması değil. Hangi sitenin açık olduğunu söylemiyor. Söylediği şey daha basit: PHP'nin artık yeni sürüm çıkarmadığı sürümlerde çalışan sitelerin oranı. O oran bölgenin tamamını ölçmüyor ama yönü gösteriyor: baktığımız sitelerin en az 275'i desteği bitmiş bir PHP sürümünde.

Bu sitelerin sahipleri kimler? En çok sağlık ve estetik işletmeleri, sağlık turizmi klinikleri, inşaat firmaları, oteller, mandıralar ve gıda toptancıları. Ciro yapan, müşterisi olan işletmeler. Hiçbiri sabah "PHP sürümü" diye bir kavramla uyanmıyor. Uyanmak zorunda da değil. Ama birinin uyanması gerekiyor.

Üç adımda ne yapmalı?

Teknik bilgi gerekmiyor. Doğru soruyu doğru kişiye sormak yetiyor.

1. Hosting firmanıza yazın: "Sitemin PHP sürümü kaç?" Tek cümle. Cevap bir sayıdır. 8.2, 8.3, 8.4 ya da 8.5 ise yamalı alt sürümde olduğunuzu teyit ettirin.
2. Cevap 8.1 ya da daha eskiyse yükseltme isteyin. Bu sürümlere PHP'den yeni sürüm gelmeyecek; hosting firmanız eski sürüme yamayı uyguladığını yazılı olarak teyit etmiyorsa bekleyerek düzelmeyecek. Yükseltme eski bir temayı ya da eklentiyi bozabilir. Bu riski yedek alarak, hosting firması ve web tasarımcınızla birlikte yönetin. Bozulma riski, açık riskinin yanında küçük kalır. Yükseltecekseniz 8.3 ya da 8.4'ü isteyin; 8.2'nin güvenlik desteği 31 Aralık 2026'da bitiyor.
3. WordPress güncellemesinin yetmediğini bilin. Panelde "her şey güncel" yazması sunucunun güncel olduğu anlamına gelmiyor. İki ayrı katman, iki ayrı sorumlu.

Açığı bulan taraf yapay zeka kullanıyor. Kullanacak taraf da. Ortada kalan tarafın elinde ise hâlâ 2021 ya da daha öncesinden kalma bir PHP sürümü var. Bu denklemin nereye gittiğini görmek için uzman olmaya gerek yok. Sorulması gereken tek soru şu: sitenizin PHP sürümünü bilen biri var mı?

Kaynaklar

1. PHP güvenlik duyurusu, 21 Ekim 2026: https://www.php.net/archive/2026.php#2026-10-21-5
2. Robert McMillan, The Wall Street Journal, 21 Ekim 2026 (Thai Duong demeci)
3. Wiz Research, PHP2Shell: https://www.wiz.io/blog/php2shell-php-rce
4. The Hacker News: https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html
5. Sansec: https://sansec.io/research/php2shell
6. CISA: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
7. Meow Apps: https://meowapps.com/php2shell-wordpress/