PHP Açığı Sonrası Analizi: Hata İki Yıl Önce Biliniyordu — Bakımcıların Küçük Ekibi Açıklamadan Önce Konudan Haberdardi; Yeni PHP2Shell Zincirli Saldırısı Sunucuları Yıkım Üzere.

(Görsel kaynağı: Getty Images)

“Yağmur yağınca doluya tutulmak” deyimi ne hava durumuna ne de bilgisayar güvenliğine uygulanabilir; bu, 19 Ekim 2026 haftasında OpenAI‘ın GPT 5.6-Sol’un açık kaynaklı PHP programlama dilinde kritik açıklar bulmasıyla kanıtlandı. Bir post-mortem’de yayınlandığı gibi, az sayıdaki bakımcı ekibi bu sorunu iki yıl önce biliyordu. Güvenlik uzmanları, ajan tabanlı yapay zekânın açıklar taramasını katlanarak hızlandırmasıyla, güvenlik açıkları için geleneksel 90 günlük ifşa penceresinin anlamsız hale gelmesi üzerine yıllardır biriken teknik borçlanmadan uyarıyordu. İnternetin yaygın yazılım paketlerinden biri olan PHP, havucuyu avlayan ajanların hedefine takılmaya yeterince şanssızdı.

PHP, internetteki web sitelerinin yaklaşık %70’ini barındırıyor ve açıklar, yeterli saldırıcı bilgisiyle uzaktan kod çalıştırmasına olanak tanıyor. Bu kombinasyon alarmı çalmaya yeterliydi, ancak durum, o sırada internetteki PHP kurulumlarının %73’ünün aktif desteği olmayan, ömrü bitmiş sürümler çalıştırdığı ortayaınca daha da kötüleşti — birçok teknoloji meraklısından yüz tutma, ekosisteme aşina olanlardan ise (benim de dahilimle) sabırsızca bir iç çekme uyandırdı. Sonuç olarak asıl sorun açıklar değil, genel bir rehavetti.

Saldırı nasıl oluştu

Açığın kök nedeni, PHP motorunun hata işleme mekanizmasındaki kadim mimari bir karardı. Bir PHP süreci belleği doldurduğunda, longjmp() C fonksiyonunu çağırır; bu, “sorunsuzca anında yürütmeyi başka bir yere atlamak” anlamına gelir. longjmp()’yu çok iyi bir sebep olmadan kullanmak genellikle önerilmez, ancak bu baş başına sorundu.

Son Videolar

Tom’s Hardware

Asıl sorun, o atılmanın bir veri yapısı oluşturulurken (bir dizi elemanı eklemek ya da bir nesneyi başlatmak gibi) gerçekleşmesi; bu, yarı mamul verinin bellek yığınında kalmasına yol açar. PHP motoru yürütmeyi temizleme-sonlandırma-çıkış mekanizmasına yönlendirdiğinde, bu kod iyi ve tam veri bekler, ancak tutarsız arta kalan baytlar üzerinde işlem yapar.

Bir web isteğine doğru içeriğin zekice enjekte edilmesiyle bu mekanizma, devam eden PHP2Shell sömürüsüyle de görüldüğü gibi, PHP’nin izinleriyle herhangi bir kodu çalıştırmak için sömürülebilir.

Uzak masaüstü kabuğuna erişmek, saldırganın kullanılan PHP’nin tam sürümünü ve yapım numarasını bilmesini gerektirir; bu nedenle yalnızca “Hack” düğmesine basmak kadar kolay değildir. Yine de, on milyonlarca savunmasız sunucuda, çoğu aynı tam sürümü çalıştırdığından, geniş patlama yarıçapı herkesi durdurmaya yeter. Açıklandıktan sonra birçok sistem yöneticisi, olası saldıranlara yol açmamak için PHP kurulumlarında sürüm numarası raporlamayı devre dışı bıraktı.

PHP Vakfı’nın olay sonrası analizi, ekibin sorunla iki yıldır haberdar olduğunu, ancak bunu başlangıçta ciddi bir tehlike olarak görmediğini ve üçüncü taraf eklentilerle uyumluluğu korurken sorunu çözmenin en iyi yolu konusunda birkaç kez kararsız kaldığını gösteriyor.

Ekip, yönetim hataları yaptığını kabul etti; ancak internet üzerindeki en yaygın yazılımlardan birini sürdürme göreviyle tek tam zamanlı çalışanı ve 14 yarı zamanlı müteahhidi olan küçük bir ekip bu. Bu, modern bilişim için kritik öneme sahip ancak yeterli insan kaynağı veya finansmanıyla eksik, ya da her ikisiyle de eksik açık kaynaklı yazılımlarda sık karşılaşılan bir örüntü.

Sömürü, sorunun yalnızca yarısı

Standart yama süreci makul derecede basittir; yalnızca bir nokta güncellemesi ve belki bazı hizmetlerin yeniden başlatılması yeterlidir. PHP’nin şu an sürdürülen dalları 8.1’den güncel 8.5’e kadar. Yine de sistem yöneticileri PHP’yi nadiren doğrudan kurar; bunun yerine tercih ettikleri Linux dağıtımını veya güncel paketler için topluluk depolarını kullanırlar.

Bu %73’lük sitenin PHP 7 ile hâlâ başa çıkamayan kısmı, şimdi iki ateş arasına sıkışmış durumda. PHP, 2020’nin sonunda 7.4’ten 8.0’a geçtiğinde dilde bir dizi değişiklik oldu; çoğu küçük olsa da, yine de gözden geçirme çalışmaları gerekiyordu. Birçok kişinin, dağıtımının düzeltmeleri geriye dönük olarak (backport) sağlamaya devam edeceğini, özellikle de destek döneminde olan LTS (Uzun Süreli Destek) varyantlarında, PHP 7.4 ile birlikte olacağını beklediği söylenebilir. Bu bahane, kuşkusuz her zaman biraz zayıftır; çünkü yapay zekâ çağından önce bile, mevcut PHP kodunu nispeten az bir emekle yükseltebilecek otomatik araçlar zaten mevcuttu.

Şimdi, belirli durumlarına bağlı olarak, 7.3 veya daha eski sürümlere güvenenler, tüm dağıtımların geriye dönük düzeltme yapmak zorunda olmayacağı için web sitelerinin kodunu güncel seviyeye çıkarmaya zorlanabilir. Kaynak olarak, PHP 7.3’ün 2018’de yayımlandığını belirtmek yeterli. Durumu daha da kötüleştiren, PHP kurulumlarının neredeyse %8’inin 5.x sürümünde olması; bu sürüm de . Ayrıca, bir dizi ağ cihazı, NAS kutusu ve benzeri donanımın içinde PHP taşımakta ve bunların da güncellenmesi gerekecek. Örneğin Palo Alto Networks, PanOS sistemiyle çalışan ürünler için bir uyarı yayımladı.

Ancak durum tamamen karanlık ve umutsuz değil. PHP Foundation, 7.4’ten 8.1’e kadar kaynak kodu yamalarını yayımladığı için, neredeyse herkes eski sürümler için bir yama geliştirebilir. Birçok kuruluş böyle yaptı ve Ondřej Surý (Debian geliştiricisi) tarafından Debian/Ubuntu varyantları için PHP 5.6’dan 8.1’e kadar kapsayan paketler mevcut. CloudLinux ve AlmaLinux da benzer şekilde geriye dönük düzeltmeler üretti.

Bu, genişletilmiş destek için ödeme yapmanın işe yaradığı bir fırsat; Ubuntu Pro ve Zend gibi ticari nhà üreticiler, 5.5’e kadar inen, son derece eski PHP sürümleri için paketler yayımladı. Eski web sitesi kodunun, PHP motoruna ek olarak muhtemelen başka açıkları da vardır, bu yüzden köklü bir güncelleme ve yükseltme çok daha uygun olur; ancak çok az CTO bu şarkıyı dinlemeye razı olur.

Diğer seçenekler

Sorunun bu kadar yaygın olması ve her makinenin korunmasının bir süre alacağı göz önüne alındığında, sorunu azaltmanın bir dizi başka yolu da var — ancak doğru çözüm, yamalı bir PHP sürümüne güncellemektir. Immunify360 gibi uygulama güvenlik duvarları (WAF’ler), kötü amaçlı isteklerin sunucuya ilk başta bile ulaşmasını engelleyebilir.

Cloudflare veya Fastly gibi içerik dağıtım ağları (CDN’ler), kurulumlarına bir WAF eklemek için evrensel olarak seçenekler sunar. Her iki firma da kendi bildirimlerini derhal yayımladı ve PHP2Shell algılamasını kendi kurallarına ekledi. Son olarak, CrowdStrike gibi sunucu düzeyinde güvenlik paketleri, bir saldırgan tuhaf bir şey denediğinde PHP ikili dosyasının kendisinin kötü amaçlı faaliyetlerini de algılayıp engelleyebilir. Bu korumaların sömürü çabalarını yavaşlatmış olması muhtemeldir.

Şimdi nerede?

Şu anda, PHP2Shell sömürüsü dolaşımda; en az bir yüksek profilli vaka, PHP açığını Fragnesia (diğer adıyla Dirty Frag) ile zincirleyerek son olarak ABD hükümetiyle bağlantılı olduğu anlaşılan 25 sunucuda kernel düzeyinde erişim elde etmeyi hedefleyen bir kampanyayı içeriyor. 29 Ekim itibarıyla, güvenlik firması BitSight, PHP2Shell girişimlerini çok sayıda farklı kaynaktan, izleme filosunda kaydetmişti.

BitSight’ın karanlık web forumu araştırmacıları, o tarihte her şeye uyan tek bir sömürü paketinin mevcut olmadığını gösteriyor. Bu, şu anda sızdırma kampanyalarının muhtemelen belirli hedeflere yönelik olabileceğini işaret ediyor; ancak bir atasözüdeki tek tuşla kırmızı düğme biçimindeki sömürünün bir noktada ortaya çıkması kaçınılmaz, muhtemelen Fragnesia örneğinde olduğu gibi daha derin bir sömürüyle birlikte.

Bu arada, birkaç siber güvenlik firması 19 Ekim’deki açığa çıkarmadan bu yana yamalama ilerlemesini yakından takip ediyor. Censys, saatlik olarak güncellenen gerçek zamanlı bir görünüm sunuyor ve şunu söylemek yeterli ki durum çok daha iyi gidebilirdi. İlk tahmin, savunmasız PHP kurulumlarının sayısının 119 milyon toplam içinden yaklaşık 45,7 milyon olduğunu hesapladı.

Yamalanmamış hizmet sayısı, bu yazı yazıldığı anda merhametlice yaklaşık 29 milyona geriledi; sayım yöntemine bağlı olarak saniyesinde günde yaklaşık 1 milyonluk bir yamalama hızına işaret ediyor gibi görünüyor. Buraya dikkat çekmek gerekiyor: düzeltme geri beslemeleri (backport) sürüm numarasını değiştirmeyebilir, dolayısıyla bu tür örnekler hâlâ yamalanmamış sayılabilir.

Ama herkesin sunucusunun PHP sürüm numarası raporlamayı neredeyse kapatmayı nasıl seçtiğini unutmayın. Censys’e göre, incelediği PHP sunucularının %62’si bu veriyi hiç raporlamıyor; dolayısıyla gerçek toplamların ne olabileceğini öngörmek mümkün değil. Tarih ne kadar bir göstergeyse, makinelerin önemli bir yüzdesinin bugün hâlâ yamalanmamış olması muhtemel.