KOD ESKİYDİ, TEHDİT YENİ

Yapay zekâ yazılımdaki güvenlik açıklarını yalnızca daha hızlı bulmuyor. Yıllardır birbirinden bağımsız görülen küçük hataları birleştirerek, daha önce uygulanması son derece zor saldırıları mümkün hâle getiriyor. PHP2Shell vakası, siber güvenliğin değişen kurallarını anlamak için önemli bir örnek.

Sorun yeni kodda değil, eski güven varsayımlarında

Yazılım dünyasında sık karşılaşılan bir düşünce var: Bir sistem yıllardır çalışıyorsa, ciddi bir problemi olsaydı şimdiye kadar ortaya çıkardı.

Bu yaklaşımın anlaşılır bir tarafı bulunuyor. Kurumlar her gün kullandıkları uygulamaları, veri tabanlarını ve altyapılarını sürekli yeniden yazamaz. Çalışan bir sistemi değiştirmek maliyetli, bazen de risklidir.

Ancak çalışıyor olmak ile güvenli olmak aynı anlama gelmiyor.

Ekim 2026'da ortaya çıkan PHP2Shell güvenlik açıkları, bu farkı çarpıcı biçimde gösterdi. PHP'nin temel bileşenlerinde bulunan iki kritik zafiyet, uygun koşullarda kimlik doğrulaması olmadan uzaktan kod çalıştırılmasına olanak verebiliyordu.

CVE-2026-109618 ve CVE-2026-109619 olarak tanımlanan açıklar için 21 Ekim'de güvenlik güncellemeleri yayımlandı. Araştırmaların dikkat çekici tarafı ise yalnızca açıkların ciddiyeti değildi. Sorunun izleri, PHP'nin çok eski sürümlerine kadar uzanıyordu.

Peki, yıllardır kullanılan bir yazılım neden şimdi böylesine büyük bir güvenlik sorununa dönüştü?

Yanıtın önemli bir bölümü, yapay zekânın yazılım güvenliğinde üstlenmeye başladığı yeni rolde yatıyor.

Yapay zekâ yalnızca hataları değil, hatalar arasındaki ilişkileri de buluyor

Geleneksel güvenlik araştırmalarında bir yazılımdaki hatanın tespit edilmesi ile o hatanın gerçek bir saldırıya dönüştürülebilmesi arasında önemli bir fark vardı.

Bir bellek yönetimi problemi, beklenmeyen bir işlem sonlandırması veya hatalı durum temizleme mekanizması tek başına kritik bir saldırı gibi görünmeyebilirdi.

Ancak bu sorunlar belirli bir sırada bir araya geldiğinde, sonuç çok daha ciddi olabiliyor.

PHP2Shell araştırmalarında yapay zekâ modelleri, karmaşık hata zincirlerinin anlaşılmasını ve istismar edilebilirliğinin gösterilmesini kolaylaştırdı. Wiz Research, araştırma sürecinde Wiz Atlas, Gemini 4 Argon ve GPT-5.6 Sol modellerinden yararlandığını açıkladı.

Buradaki değişimi doğru okumak gerekiyor.

Yapay zekâ, geçmişte hiç var olmamış bir yazılım kusuru yaratmadı. Var olan kusurlar arasındaki ilişkileri araştırmayı ve bunların hangi koşullarda tehlikeli hâle gelebileceğini göstermeyi kolaylaştırdı.

Bu, güvenlik araştırmalarının ölçeğini değiştirebilecek bir gelişme.

Çünkü artık asıl mesele yalnızca bilinen açıkları taramak değil, henüz kritik bir açık olarak sınıflandırılmamış teknik sorunların birlikte nasıl davranabileceğini de incelemek.

Dünün önemsiz hatası, yarının saldırı zincirinin kritik halkası olabilir.

Güvenlik açığının yaşı değil, onu kullanabilme kapasitesi değişti

PHP2Shell olayında dikkat çeken unsurlardan biri, sorunların geçmişinin oldukça eskiye dayanması.

PHP Foundation'ın olay değerlendirmesine göre, temel bellek yönetimi probleminin erken işaretleri 2024 yılında gerçekleştirilen güvenlik çalışmaları sırasında fark edilmişti. Ancak sorunun giderilmesi için yürütülen çalışmalar ilerleyemedi. 2026'da farklı araştırma ekiplerinin bulguları, konuyu yeniden kritik gündeme taşıdı.

Bu durum yalnızca PHP ile ilgili değil.

Bugün kurumsal sistemlerin önemli bir bölümü uzun yıllardır geliştirilen yazılım bileşenleri üzerinde çalışıyor. Web uygulamaları, açık kaynak kütüphaneleri, eski entegrasyon servisleri ve üçüncü taraf sistemler bunların başında geliyor.

Bu bileşenlerin her birini sıfırdan analiz etmek insanlar için ciddi bir zaman ve uzmanlık gerektiriyor.

Yapay zekâ destekli analiz araçları, bu işin bir bölümünü daha hızlı yürütme potansiyeline sahip.

Elbette bu araçların ürettiği her bulgu doğru değil. Yanlış pozitifler, hatalı çıkarımlar ve çalışmayan saldırı senaryoları hâlâ önemli sorunlar.

Fakat insan uzmanların değerlendirme kapasitesiyle birleştirildiklerinde, daha önce gözden kaçmış ilişkilerin keşfedilmesini sağlayabiliyorlar.

Ortaya çıkan sonuç şu:

Bir yazılımın uzun süredir saldırıya uğramamış olması, güvenli olduğunun kanıtı değildir. Yalnızca o ana kadar başarılı bir saldırının gerçekleşmediğini veya tespit edilmediğini gösterir.

Saldırı ile savunma arasındaki zaman daralıyor

PHP2SHELL | 2026 ZAMAN ÇİZELGESİ

1. 11 Ağustos: Calif ve OpenAI araştırmalarında temel bellek sorunu bağımsız olarak raporlandı.
2. 19–24 Ağustos: Wiz ekibi farklı saldırı yolları keşfetti ve bulgularını bildirdi.
3. 17 Ekim: AWS MadPot sensörleri, daha sonra geriye dönük olarak PHP2Shell ile ilişkilendirilen bir saldırı girişimi kaydetti.
4. 20 Ekim: Açıklama sürecinin gizliliği bozuldu; erken yayımlanan bilgiler riski artırdı.
5. 21 Ekim: PHP güvenlik yamaları yayımlandı. Aynı dönemde saldırı araçları ve tarama girişimleri gözlemlenmeye başladı.
6. 26 Ekim: İnternete açık, kontrollü test ortamında başarılı uzaktan kod çalıştırma kanıtı kamuoyuna yansıdı.

Kaynaklar: PHP Foundation, Wiz, AWS, Fastly ve 26 Ekim tarihli güvenlik incelemeleri.

Geleneksel güvenlik yönetiminde kurumlar çoğunlukla aylık veya belirli dönemlere bağlı güncelleme takvimleriyle çalışıyor.

Kritik bir açık yayımlanıyor, güvenlik ekipleri etkilenebilecek sistemleri belirliyor, uygulama sahipleri test yapıyor ve değişiklik yönetimi sonrasında güncelleme gerçekleştiriliyor.

Bu süreç operasyonel açıdan anlaşılabilir.

Ancak saldırı girişimleri, kurumların değişiklik takvimlerini beklemiyor.

PHP2Shell olayında Fastly tarafından yayımlanan gözlemler, saldırı araçlarının güvenlik güncellemelerinin koordineli yayımlanmasından önce kullanıldığını ortaya koydu. AWS tarafından kaydedilen daha erken girişim de güvenlik araştırmaları devam ederken istismar riskinin ortaya çıkabileceğini gösterdi.

Bütün bunlar yapay zekânın saldırıların tamamından sorumlu olduğunu kanıtlamıyor. Ancak yapay zekâ ile hızlanan güvenlik araştırmalarının, hem savunma hem de saldırı kapasitesini dönüştürebileceğini açıkça gösteriyor.

Burada kurumların yeniden değerlendirmesi gereken temel soru şu:

Bir güvenlik açığını ne kadar hızlı tespit ediyoruz değil, o açığın gerçek bir saldırıya dönüşmesinden önce ne kadar hızlı önlem alabiliyoruz?

Açık kaynak yazılımın görünmeyen maliyeti: Bakım kapasitesi

Açık kaynak yazılımlar, internetin en önemli yapı taşları arasında.

Web sunucuları, programlama dilleri, veri tabanları ve uygulama çerçeveleri küresel ölçekte bu ekosistem üzerinde çalışıyor.

Ancak kullanılan yazılımın ücretsiz olması, bakımının da maliyetsiz olduğu anlamına gelmiyor.

Özellikle küçük açık kaynak projelerinde yazılımı geliştiren, güvenlik bildirimlerini değerlendiren ve yeni sürümleri hazırlayan kişi sayısı son derece sınırlı olabiliyor.

Yapay zekâ bu dengesizliği daha da görünür hâle getiriyor.

Bir tarafta büyük miktarda kodu analiz edebilen, farklı hata kombinasyonlarını araştırabilen araçlar var. Diğer tarafta ise gelen güvenlik bildirimlerini doğrulamak, hataları yeniden üretmek ve yeni sürümleri test etmek zorunda olan insan ekipleri.

Üstelik yapay zekâyla üretilen düşük kaliteli hata bildirimleri ve kod katkıları, bakım ekiplerinin iş yükünü artırabiliyor.

Bu noktada ortaya çıkan tehlike yalnızca yeni güvenlik açıklarının bulunması değil.

Açık bulma kapasitesi büyürken, açık kapatma kapasitesinin aynı hızda büyümemesi.

Güvenlik ekosisteminin sürdürülebilirliği, yapay zekâ modellerinin ne kadar güçlü olduğundan çok, keşfedilen sorunların nasıl yönetildiğine de bağlı olacak.

Kurumsal güvenlikte en zayıf halka unutulmuş yazılımlar olabilir

Modern kurumlar genellikle yeni sistemlerin güvenliğine daha fazla odaklanıyor.

Yeni projeler için güvenlik testleri yapılıyor, erişim politikaları belirleniyor, bulut hizmetleri denetleniyor ve uygulama geliştirme süreçlerine kontroller ekleniyor.

Ancak eski bir servis, yıllardır güncellenmeyen bir web uygulaması veya yalnızca tek bir iş sürecinde kullanılan eski bir kütüphane, aynı güvenlik görünürlüğüne sahip olmayabiliyor.

Bu durum özellikle kurumların kendi geliştirdiği uygulamalar açısından önemli.

Bir uygulamanın güncel olması, altında kullanılan çalışma ortamının da güncel olduğu anlamına gelmiyor. PHP2Shell örneğinde risk, yalnızca WordPress ya da Drupal gibi uygulamaların kendi kodlarından değil, bunların çalıştığı PHP altyapısından kaynaklanıyordu.

Dolayısıyla güvenlik envanterinin yalnızca sunucuların ve uygulamaların isimlerinden oluşması yeterli değil.

Kurumların uygulamaların kullandığı çalışma ortamlarını, bağımlılıklarını, destek durumlarını ve internete açık bileşenlerini de izlemesi gerekiyor.

Burada beş öncelik öne çıkıyor:

• Gerçek yazılım envanteri: PHP, Node.js, Java, Python ve diğer çalışma ortamlarının üretimde kullanılan sürümlerinin ve bağımlılıklarının tespit edilmesi.
• Risk odaklı güncelleme: Kritik ve internete açık sistemlerin, yalnızca rutin aylık güncelleme takvimine bağlı kalmadan değerlendirilmesi.
• Yapay zekâ destekli savunma: Kod analizi ve zafiyet araştırmalarında yapay zekânın, insan doğrulamasıyla birlikte kullanılması.
• Destek dışı bileşenlerin azaltılması: Güncelleme alamayan yazılımların izole edilmesi, değiştirilmesi veya kaldırılması.
• Olaylara hazırlık: Yalnızca güvenlik açığını kapatmaya değil, olası bir istismar girişimini kayıtlarda tespit etmeye ve etkisini sınırlandırmaya odaklanılması.

Bunlar yeni güvenlik prensipleri değil. Değişen şey, bu prensiplerin uygulanmasını ertelemenin giderek daha pahalı hâle gelmesi.

Yapay zekâ siber güvenliği daha mı tehlikeli hâle getiriyor?

Bu sorunun basit bir yanıtı yok.

Yapay zekâ, geçmişte yalnızca çok deneyimli uzmanların inceleyebildiği karmaşık yazılım davranışlarının araştırılmasını kolaylaştırabilir.

Bu durum savunma ekiplerine önemli fırsatlar sunuyor.

Daha kapsamlı kod incelemeleri, daha hızlı hata doğrulama, karmaşık bağımlılıkların analizi ve güvenlik testlerinin iyileştirilmesi bunlardan bazıları.

Ancak aynı kabiliyetlerin kötü niyetli aktörler tarafından kullanılması da mümkün.

Burada belirleyici olan, yapay zekânın iyi veya kötü olması değil. Güvenlik araştırmalarında yeteneklere erişimin, savunma altyapısının ve kurumların müdahale kapasitesinin nasıl geliştiği.

Bir başka ifadeyle yapay zekâ, güvenlik açığı kavramını değiştirmiyor; güvenlik açıklarının keşfedilmesini ve kullanılabilir hâle getirilmesini etkileyen ekonomik ve teknik koşulları değiştiriyor.

Eskiden çok fazla zaman ve uzmanlık gerektiren bir araştırma, artık daha az kaynakla yürütülebiliyorsa, güvenlik dünyasının tehdit modellerini buna göre güncellemesi gerekir.

Asıl soru: Hangi kodun güvenli olduğunu gerçekten biliyoruz?

PHP2Shell, Ekim 2026'nın en dikkat çekici güvenlik olaylarından biri olarak değerlendirilebilir.

Ancak uzun vadede önemli olan yalnızca hangi PHP sürümünün güncellendiği değil.

Daha büyük mesele, yazılım güvenliğine ilişkin varsayımlarımızın değişmesi.

Bugün bir kurumun altyapısında kullanılan yazılımın kaç yıllık olduğunu bilmek kolay olabilir. Fakat o yazılımın hangi bağımlılıkları kullandığını, hangi eski kod parçalarının beklenmedik biçimde etkileşime girebileceğini ve bunlardan hangisinin istismar edilebilir olduğunu bilmek çok daha zor.

Yapay zekâ bu belirsizliği azaltabilir.

Ama belirsizliğin azalması, yalnızca savunma tarafına avantaj sağlamıyor.

Bu nedenle geleceğin güvenlik yaklaşımı yalnızca daha fazla güvenlik ürünü satın almaktan veya daha fazla tarama yapmaktan ibaret olamaz.

Uygulamaların gerçek bağımlılıklarını anlamak, eski kodların oluşturduğu riskleri yeniden değerlendirmek, bakım kapasitesini artırmak ve savunmayı daha hızlı hareket edebilir hâle getirmek gerekiyor.

Kod yaşlandı, güvenlik anlayışı da yaşlanmamalı

Yıllardır çalışan bir yazılımın güvenli olduğunu varsaymak geçmişte de doğru değildi.

Bugün ise bu varsayım daha da tehlikeli.

Çünkü değişen yalnızca saldırganların kullandığı araçlar değil; yazılımın içinde gizli kalmış problemlerin keşfedilme olasılığı ve hızı.

PHP2Shell bize tek bir yazılım dilinin ne kadar kırılgan olabileceğini değil, dijital dünyanın ne kadar büyük bir kısmının geçmişte yazılmış ve bugün yeniden incelenmesi gereken kodlara dayandığını hatırlatıyor.

Belki de bundan sonra güvenlik ekiplerinin sorması gereken soru, “Bu sistem kaç yıldır sorunsuz çalışıyor?” değil, “Bu sistemi en son ne zaman bugünün tehdit kapasitesiyle yeniden değerlendirdik?” olmalı.

Çünkü kodun eski olması başlı başına sorun değil. Asıl sorun, eski kodun hâlâ eski güvenlik varsayımlarıyla korunması.