İyi Biten Bir Kriz Hikayesi

Yaklaşık 20 yıldır web teknolojileriyle uğraşıyorum. PHP'de böyle bir açık ihtimali, yalnızca bir yazılım güncellemesi meselesi değildi. Kullandığımız altyapıyı, müşterilerimizin sitelerini, sorumluluklarımızı ve en önemlisi müşteri ile kullanıcı verilerinin güvenliğini doğrudan ilgilendiriyordu.

WhatsApp grubumuzda, işleyişimizi ve teknik altyapımızı bilen, verilerimize hakim ve erişim yetkisi olan bir yapay zeka ajanı da bulunuyor. Gerektiğinde bilgi topluyor, seçenekler sunuyor ve kendisine verilen yetkiler çerçevesinde işlem yapabiliyor. O gece hemen çalışmaya başladı:

Gece yarısına doğru sunuculardaki PHP sürümlerini, güncelleme seçeneklerini ve olası etkileri değerlendirmeye koyulduk. Saatler ilerledikçe, sosyal medyada dolaşan şüpheli bir iddia, sunucuların ve hizmetlerin tek tek ele alındığı bir kriz çalışmasına dönüştü. İlk belirsizlik, yerini gece 02.00 sularında PHP'nin resmi sitesinde yayımlanan açıklamayla doğrulanan iki kritik güvenlik açığına bıraktı. Biz de ajanın önerileri ve kendi eklediğimiz detaylarla hızlıca harekete geçtik; olası istismar denemelerinde tekil IP adreslerini değil, doğrudan şüpheli IP bloklarını engelleyen önlemler aldık.

Sabah olduğunda iş bitmemişti. PHP'nin yanı sıra Nginx ve Node.js tarafındaki güvenlik duyurularını da değerlendiriyorduk. Yedekler, geçici önlemler, güncellemeler, izleme sistemleri ve şüpheli trafik… Altı sunucuda önce risk azaltıcı önlemler aldık, ardından resmi yamaları uyguladık.

Bizim tarafımızda kayda değer bir güvenlik olayı yaşamadık. Fakat o gece boyunca gördüğüm şey yalnızca bir açığı kapatmak değildi. İnsanlarla yapay zekanın, gerçek bir kriz anında nasıl birlikte çalışabileceğini de ilk elden tecrübe ediyordum.

İnternetin “ne kadarı” aynı anda risk altındaydı?

PHP, yalnızca eski web sitelerinin kullandığı bir teknoloji değil. Laravel gibi modern uygulama çatılarından WordPress, Drupal ve Joomla gibi içerik yönetim sistemlerine kadar internetin geniş bir bölümünde karşımıza çıkıyor. Facebook da tarihinin önemli bir bölümünde PHP'yi yoğun biçimde kullandı; zamanla kendi altyapısını ve teknolojilerini geliştirdi.

W3Techs'in Ekim 2026 verileri, sunucu tarafı teknolojisi bilinen web sitelerinin yaklaşık yüzde 70'inde PHP kullanıldığını gösteriyor.²

Bu, internetin yüzde 70'inin söz konusu açıklar nedeniyle savunmasız olduğu anlamına gelmiyor. Bir sitenin PHP kullanması tek başına o açığın istismar edilebileceğini kanıtlamaz. Risk; kullanılan PHP sürümüne, çalışma biçimine, sistem yapılandırmasına ve uygulamanın internete ne ölçüde açık olduğuna bağlı.

Yine de bu yaygınlık, neden bu kadar geniş çaplı bir alarm verildiğini anlamak için yeterli.

PHP, web sunucusunda çalışan bir yazılım bileşenidir. Bir saldırgan, savunmasız bir sistemde uzaktan kod çalıştırmayı başarırsa uygulamanın ve sunucunun yetkileri dahilinde dosyalara, veritabanlarına ve diğer sistem kaynaklarına erişebilir. Aynı sunucuda birden fazla müşteri sitesi barındırılıyorsa, siteler arasındaki izolasyonun yetersiz olması diğer siteler için de risk oluşturabilir.

Bu, saldırganın otomatik olarak bütün sunucuyu ya da aynı altyapıdaki tüm siteleri ele geçireceği anlamına gelmez. Ancak bir bileşendeki güvenlik açığının etkisi, o bileşenin çevresindeki sistemlerle nasıl etkileşim kurduğuna bağlı olarak büyüyebilir. Güvenlik, yalnızca uygulamaların tek tek korunmasına değil, aralarındaki sınırların ne kadar iyi korunduğuna da bağlıdır.

Açık künyesi

Açıklar

CVE-2026-109618 ve CVE-2026-109619

Ortak ad

PHP2Shell

Derece

CVSS 9,2 (kritik)

Tür

Kimlik doğrulaması gerektirmeden uzaktan kod çalıştırma

Yamalı sürümler

8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

Açıklama

21 Ekim 2026

Bulan

Wiz Research

Dünya neden alarma geçti?

O gece bilmediğim bir şey vardı: Elimizdeki yalnızca bir söylenti değil, bir sızıntıydı. Hacker News gönderisi kısa sürede kaldırıldı ama ekran görüntüleri dolaşmaya devam etti ve güvenlik araştırmacıları birkaç saat içinde iddianın doğru olduğunu teyit etti. Açıkların koordineli duyurusu için belirlenmiş tarih delinmişti; PHP de yayın tarihini bir gün öne çekti. Yani o saatte hissettiğimiz aciliyet fazladan bir tedirginlik değildi, açıklama sürecinin kendisi bozulmuştu.³

İki ay süren süreç, bir gecede patladı

Açıkların bulunmasından yamaların yayımlanmasına kadar geçen zaman — ve o zincirin bizim gecemizle kesiştiği an.

Koordineli açıklama süreciSızıntı ve o gece

1. 19 Ağustos 2026

   Wiz Research, PHP çekirdeğinde açık aramaya başlıyor.

2. 24 Ağustos

   Bulgular PHP güvenlik ekibine bildiriliyor.

3. 21 Eylül

   PHP güvenlik ekibi bildirimi teyit ediyor.Yama çalışması ve ambargo takvimi başlıyor.

4. 20 Ekim, sabah

   Hacker News'e bir gönderi düşüyor; ambargo deliniyor.Gönderi kaldırılıyor ama ekran görüntüleri yayılıyor.

5. 20 Ekim, 23.35

   Tweet, yönetim kurulu WhatsApp grubuna düşüyor.

6. 21 Ekim, 02.00 sularında

   PHP'nin resmi açıklaması yayımlanıyor; söylenti doğrulanıyor.

7. 21 Ekim

   Yamalar yayımlanıyor. Avrupa kurumları ortak açıklama yapıyor; Birleşik Krallık ve Türkiye'den uyarılar geliyor.

21 Ekim'de güncellemeler yayımlandı. PHP'nin resmi açıklamasına göre açıklar, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırılmasına yol açabiliyordu; ikisi de CVSS ölçeğinde 9,2 ile derecelendirildi. Düzeltilmiş sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 olarak duyuruldu.⁴

Avrupa Komisyonu, Avrupa Birliği Siber Güvenlik Ajansı ENISA, CERT-EU, Europol'ün siber suç birimi ve ulusal olay müdahale ekipleri de ortak bir açıklamayla kuruluşları acil önlem almaya çağırdı. Birleşik Krallık Ulusal Siber Güvenlik Merkezi benzer biçimde, kuruluşların PHP kullanan sistemlerini belirlemesini, internete açık olanlara öncelik vermesini ve güncelleme hemen yapılamıyorsa sistemleri geçici olarak çevrim dışına almayı değerlendirmesini önerdi.⁵

T.C. Siber Güvenlik Başkanlığı da PHP2Shell olarak adlandırılan kritik güvenlik açıklarıyla ilgili bir güvenlik bildirimi yayımladı. Başkanlık, kurum ve kuruluşlara PHP tabanlı sistemlerini kontrol etmeleri, güvenlik güncellemelerini gecikmeden uygulamaları ve gerekli durumlarda dış erişimleri sınırlandırmaları çağrısında bulundu.⁶

Bu çağrılar, her sistemin saldırıya uğradığı anlamına gelmiyordu. Tam tersine, güvenlik ekipleri saldırı gerçekleşmeden önce riskleri azaltmak için harekete geçiyordu. Bazı hizmetlerin geçici olarak kapatılması da bu önleyici yaklaşımın bir parçası olabiliyordu.

Böyle bir durumda iki yanlış varsayımdan kaçınmak gerekiyor. Birincisi, “Henüz saldırıya uğramadık, o halde güvendeyiz” düşüncesi. İkincisi ise “Açık duyuruldu, demek ki bütün sistemler ele geçirildi” paniği.

Gerçek, çoğu zaman bu iki uç arasında: ciddi bir risk var ve bu riskin etkisi, ne kadar hızlı ve doğru hareket edildiğine bağlı.

Açığı bulan yöntem, savunmayı da hızlandırabilir mi?

Bu olayın benim açımdan en dikkat çekici tarafı burada başlıyor.

Açıkları, güvenlik şirketi Wiz'in araştırma ekibi buldu; istismar yöntemini geliştirip PHP güvenlik ekibine bildiren de onlar oldu. Wiz'in aktardığına göre bu çalışmanın içinde yapay zeka modelleri de vardı: Gemini 4 Argon'un açığın bulunması, istismar yöntemlerinin geliştirilmesi, saldırıların tespit edilmesi ve yamanın doğrulanması aşamalarına katkı sunduğu belirtiliyor. Google DeepMind'da Gemini güvenliğinden sorumlu Raluca Ada Popa da çalışmayı, sınır modellerin siber savunma açısından ne anlama geldiğinin bir göstergesi olarak değerlendirdi.⁷

Bu ayrıntı, yapay zekanın siber güvenlikteki rolüne ilişkin daha geniş bir değişimi gösteriyor. Büyük kod tabanlarını incelemek, karmaşık bellek hatalarını anlamak ve bir kusurun hangi koşullarda istismar edilebileceğini araştırmak zaman alıyor. Yapay zeka, bu çalışmaların bazılarını hızlandırabiliyor.

Ancak aynı yeteneklerin saldırganlar tarafından da kullanılabilmesi, meselenin diğer yüzünü oluşturuyor. Bir güvenlik açığını bulmak ve anlamak kolaylaştıkça, onu istismar etmeye yönelik araştırmalar da hızlanabilir. Bu da savunma ekiplerinin karşısındaki zaman baskısını artırabilir.

Öte yandan savunma tarafında da aynı teknolojilerden yararlanmak mümkün. Hangi sunucuda hangi yazılım sürümünün çalıştığını belirlemek, güvenlik duyurularını ilgili sistemlerle eşleştirmek, güncelleme sırasını planlamak, işlemlerin sonucunu kontrol etmek ve şüpheli hareketleri araştırmak otomasyon sayesinde hızlanabiliyor.

Bizim gecemizde de bu farkı gördüm. Yapay zeka ajanımız altyapı hakkında bilgi topladı, farklı sürümleri karşılaştırdı, riskleri sıraladı ve uygulanabilecek adımları önerdi. Yetkileri dahilinde bazı işlemleri gerçekleştirdi. İnsanların farklı panellerde ve komut satırlarında saatlerce yapabileceği işlerin bir bölümünü, WhatsApp üzerinden yürüttüğümüz konuşmalar ve aldığımız kararlarla çok daha kısa sürede tamamlayabildik.

Burada önemli olan, yapay zekanın bir komut satırına bağlanmış olması değil. Sistemin neyi yönettiğini bilmesi, doğru bilgiyi zamanında toplaması, seçenekleri anlaşılır biçimde sunması ve insanlarla birlikte hareket edebilmesiydi.

Yine de bunu “Yapay zeka geldi, güvenlik sorunu çözüldü” diye okumamak gerekiyor.

Otomasyon, yanlış kararı da hızlandırabilir.

Yetkileri yanlış tanımlanmış bir ajan, hatalı bir işlemle hizmeti durdurabilir veya sorunu büyütebilir. Bir yamayı kurmak da sistemin daha önce ele geçirilmediğini kanıtlamaz. Günlüklerin incelenmesi, şüpheli hareketlerin araştırılması ve hizmetlerin yeniden doğrulanması hala gerekli.

Yapay zeka iyi hazırlanmış bir altyapının yerine geçmiyor. İyi hazırlanmış altyapının daha hızlı ve verimli kullanılmasını sağlayabiliyor.

Yama yayımlandığında risk sona ermiyor

Güvenlik açıklarının hikayesi, duyurunun yayımlandığı gün başlamıyor. Bir kusurun keşfedilmesi, üreticiye bildirilmesi, doğrulanması, giderilmesi ve kullanıcıların sistemlerini güncellemesi arasında zaman geçiyor. Bu süreç boyunca farklı aktörler aynı bilgiye farklı zamanlarda erişebiliyor.

Açık kamuoyuna duyurulduğunda savunma ekipleri ne yapmaları gerektiğini öğreniyor. Ancak saldırganlar da aynı bilgiye erişebiliyor. Yama yayımlandığında savunma için somut bir çözüm ortaya çıkıyor; buna rağmen eski sürümlerle çalışmaya devam eden, güncellenemeyen veya hangi bileşenleri kullandığını bilmeyen sistemler risk altında kalabiliyor.

Üstelik bir sistem, yama uygulanmadan önce ele geçirilmişse yalnızca güncelleme yapmak yeterli olmayabilir. Saldırganın bıraktığı dosyalar, açtığı hesaplar veya oluşturduğu kalıcı erişim yolları ayrıca araştırılmalı. Bu nedenle güvenlik güncellemesi, olay müdahalesinin önemli bir parçası olsa da her zaman son adım değil.

Eski yazılımların oluşturduğu sorun da burada belirginleşiyor. Ana proje tarafından artık desteklenmeyen PHP sürümleri için yeni yamalar yayımlanmayabilir. Bazı işletim sistemi dağıtımları veya uzun süreli destek sağlayıcıları, güvenlik düzeltmelerini eski sürümlere uyarlayabilir. Ancak bunun her kurulum için geçerli olduğunu varsaymak doğru olmaz. Kurumların kullandıkları yazılımların envanterini ve destek durumlarını bilmeleri gerekiyor.

Kısacası, “Açık bulundu, yama çıktı, mesele kapandı” diyemiyoruz. Yama uygulamak, atılması gereken en acil adımlardan biri. Sonrasında sistemin gerçekten güvenli hale geldiğini ve şüpheli bir etkinlik yaşanmadığını kontrol etmek gerekiyor.

Kriz anında hız kadar hazırlık da önemli

O gece, arkadaşlarımla birlikte çalışırken yapay zeka desteğinin farkını net biçimde hissettim. Bir tarafta çok sayıda sistemi ilgilendiren belirsiz bir tehdit, diğer tarafta hızla karar vermeyi gerektiren teknik işler vardı. Yapay zeka, dağınık bilgiyi toparlayıp uygulanabilir adımlara dönüştürmemize yardımcı oldu.

Ancak bu deneyimin tek başına yapay zekaya ait bir başarı hikayesi olduğunu düşünmüyorum. Önceden tanımlanmış yetkiler, izlenebilir işlemler, yedekler, güncelleme yolları ve sistemler hakkında güncel bilgi bulunmasaydı, bir ajan ne kadar yetenekli olursa olsun sınırlı kalırdı.

Kurumlar açısından farkı belirleyecek şeylerden biri de bu olacak. Bir güvenlik duyurusu yayımlandığında hangi sistemlerin etkilendiğini günlerce araştıran yapılarla, envanterini hazır tutup birkaç saat içinde harekete geçebilen yapılar aynı durumda değil. Bürokratik süreçler, sorumluluğun belirsizliği ve güncelleme yapmaya elverişsiz altyapılar, teknik bir açığın etkisini büyütebilir.

Yapay zeka çağında güvenlik açıklarının bulunması ve istismar edilmesi hızlanabilir. Aynı zamanda savunma ekiplerinin bilgi toplama, önceliklendirme ve müdahale etme kapasitesi de artabilir. Hangisinin daha hızlı ilerleyeceğini bugün kesin olarak söylemek zor.

Ancak bir şey açık: Bu yarışta yalnızca en iyi teknolojiye sahip olmak yetmeyecek. Onu doğru yetkilerle, sağlam süreçlerle ve zamanında kullanabilmek de gerekecek.

Ben o gece PHP açığını —bizim memleketin meşhur kriz klişesindeki gibi bir enişteden olmasa da— ortağım Hakan'ın gece yarısı gönderdiği bir bağlantıdan öğrendim. Başlangıçta ortada yalnızca bir iddia, birkaç CVE numarası ve konunun ciddiyetini anlatan bir GIF vardı. Saatler sonra elimizde resmi yamalar, kontrol edilmiş sunucular ve tamamlanmış güncellemeler bulunuyordu.

Belki de yapay zeka çağının siber güvenlik açısından asıl sorusu, açıkların daha hızlı bulunup bulunmayacağı değil. Bir açık bulunduğunda, bunu öğrenen bir insanın veya kurumun ne kadar hızlı ve doğru hareket edebileceği.

Çünkü bazen güvenlik, açıkların hiç ortaya çıkmaması değil, bir açık ortaya çıktığında ne yapacağını bilmektir.

Notlar

1. CVE, güvenlik açıklarını dünya çapında kataloglamak için kullanılan standart sistem.
2. W3Techs — PHP kullanım istatistikleri. Veri günlük güncelleniyor. w3techs.com ↩
3. Sızıntının kronolojisi için: Huntress, “php2shell: Leaked Critical PHP Vulnerabilities”. huntress.com ↩
4. PHP — 2026 Güvenlik Duyuruları, php.net. Ayrıca CERT-EU güvenlik duyurusu 2026-018: cert.europa.eu ↩
5. ENISA — “Joint statement on critical PHP vulnerabilities”, 21 Ekim 2026: enisa.europa.eu. Birleşik Krallık Ulusal Siber Güvenlik Merkezi duyurusu. ↩
6. T.C. Siber Güvenlik Başkanlığı — PHP Programlama Dili Güvenlik Bildirimi. ↩
7. Wiz Research — “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”: wiz.io ↩