PHP’de Kritik Güvenlik Açığı: Panik Yapmayalım Ama Güncellemeyi de Ertelemeyelim!

PHP ile yıllardır uğraşan biri olarak bugün önemli bir konudan bahsetmek istiyorum. PHP ekibi, 21 Ekim 2026 tarihinde, sunucularda uzaktan kod çalıştırılmasına (Remote Code Execution – RCE) imkân verebilecek iki kritik güvenlik açığı için yeni sürümler yayımladı.

Üstelik bu açıkların istismar edilmesi için bazı senaryolarda saldırganın sisteme giriş yapmış olması bile gerekmiyor.

Evet, konu ciddi. Ama gelin, baştan başlayalım.

PHP’nin neresinde sorun var?

Öncelikle şunu netleştirelim: Burada söz konusu olan, yazdığınız Laravel uygulamasındaki bir kod hatası ya da WordPress eklentilerinden birindeki sıradan bir güvenlik problemi değil. Sorun, PHP’nin kendi çekirdeğinde; yani uygulamalarımızın çalışmasını sağlayan temel yazılım katmanında.

PHP’nin resmî güvenlik duyurusunda iki ayrı açık tanımlanıyor:

• CVE-2026-109618: Bellek yetersizliği durumunun (Out of Memory – OOM) hatalı yönetilmesi sonucunda ortaya çıkabilen bellek bozulması.
• CVE-2026-109619: Bir isteğe ait bazı dahili verilerin, bellek serbest bırakıldıktan sonra çalışan süreçte kalması ve sonraki bir istekte yeniden kullanılması.

İkisini de teknik ayrıntılara boğmadan anlatmak gerekirse, PHP’nin bazı olağan dışı durumlarda istekleri işlerken ve temizlerken belleği beklenmedik biçimde ele alması söz konusu. Uygun koşullar oluştuğunda bu durum, saldırganın sunucuda kendi kodunu çalıştırmasına kadar ilerleyebiliyor.

Özellikle Apache’nin mod_php yapılandırması için uygulama kodu çalışmaya başlamadan önce tetiklenebildiği gösterilmiş bir saldırı senaryosu bulunuyor. PHP-FPM gibi diğer çalışma biçimleri de kapsam dışında değil; risk, kullanılan yapılandırmaya ve ilgili saldırı yoluna göre değişiyor.

Dolayısıyla “Ben Laravel kullanıyorum”, “WordPress’in son sürümündeyim” ya da “Uygulamada kullanıcıların doğrudan kod çalıştırabileceği bir yer yok” demek tek başına yeterli değil.

Sorun, bu uygulamaların üzerinde çalıştığı PHP katmanında.

Hangi PHP sürümlerini kullanmalıyız?

PHP ekibi, ilgili güvenlik düzeltmelerini şu sürümlerde yayımladı:

Kullandığınız dal için uygun güvenlik sürümüne yükseltmeniz gerekiyor. Ayrıntıları PHP’nin resmî güvenlik duyurusunda, güncelleme paketlerini ise PHP’nin indirme sayfasında bulabilirsiniz.

Burada küçük ama önemli bir ayrıntı var: Sunucuda PHP 8.4 kullanıyor olmanız, otomatik olarak güvende olduğunuz anlamına gelmez. Çalışan sürümün tam olarak hangisi olduğunu kontrol edin.

Ayrıca terminalde php -v komutuyla gördüğünüz sürüm, web sitenizi çalıştıran PHP-FPM ya da Apache modülünün sürümünden farklı olabilir. Özellikle paylaşımlı hosting ortamlarında, web sunucusunun kullandığı gerçek PHP sürümünü ayrıca doğrulamak gerekiyor.

PHP 8.1 ve daha eski sürümler artık PHP projesinden doğrudan güvenlik güncellemesi almıyor. Bazı Linux dağıtımları ve uzun süreli destek sağlayan tedarikçiler düzeltmeleri geriye taşıyabiliyor. Bu nedenle eski bir sürüm kullanıyorsanız hosting sağlayıcınızdan ilgili düzeltmenin uygulanıp uygulanmadığını öğrenin ve mümkünse desteklenen bir PHP sürümüne geçiş planlayın.

Bir not daha: PHP 8.2 için verilen bu düzeltme önemli olsa da 8.2 dalının destek süresi 31 Aralık 2026 tarihinde sona eriyor. Yeni bir kurulum veya uzun vadeli bakım planında bunu da hesaba katmakta fayda var.

Güncelleme yapamıyorsak ne olacak?

Bazen kullandığımız hosting paketi, eski bir projeye ait bağımlılıklar veya uyumluluk sorunları nedeniyle PHP’yi hemen yükseltmek kolay olmayabiliyor. Bunu biliyorum; teoride tek tıkla çözülebilen işler, gerçek projelerde bazen birkaç saatlik uğraşa dönüşebiliyor.

PHP ekibinin duyurusunda, güncelleme hemen yapılamadığında belirli saldırı yollarına karşı riski azaltabilecek geçici önlemler de sıralanmış durumda. Bunlar arasında:

• İlgili oturum yükleme ilerlemesi özelliğini (session.upload_progress.enabled) sunucu düzeyinde devre dışı bırakmak.
• PHP 8.5 için fatal_error_backtraces=0 ayarını değerlendirmek.
• post_max_size ve web sunucusu düzeyindeki istek boyutu sınırlarını gözden geçirmek.
• Bellek sınırlandırması ve süreçlerin kaynak kullanımını sunucu mimarisine uygun biçimde düzenlemek.

Ancak burada çok önemli bir ayrım var: Bunlar tam bir güvenlik çözümü değil. Bazı saldırı yollarını daraltıyorlar; açıkların tamamını ortadan kaldırmıyorlar.

Örneğin memory_limit=-1 ayarı, PHP’nin denetlenebilir bellek sınırına ulaşmasından kaynaklanan belirli bir yolu etkisizleştirmek için duyuruda önerilen geçici önlemlerden biri. Fakat bu ayar, PHP’nin bellek kullanımına sınırsız izin verilmesi anlamına geldiğinden, sunucu kaynakları ve diğer koruma katmanları değerlendirilmeden gelişigüzel uygulanmamalı.

Bu tür değişiklikleri özellikle paylaşımlı hosting kullanıyorsanız kendiniz yapmaya çalışmak yerine sunucu yöneticinizle görüşün. PHP-FPM havuzu veya web sunucusu ayarlarında yapılan değişikliklerin ardından çalışan süreçlerin de yeniden başlatılması gerekebilir.

Benim yaklaşımım net: Geçici önlemleri, güvenlik güncellemesinin yerine koymayın. Mümkün olan en kısa sürede düzeltilmiş sürüme geçin.

WordPress kullanıyorsanız yalnızca eklentileri güncellemek yetmez

Bu noktayı özellikle vurgulamak istiyorum. WordPress, WooCommerce veya başka bir PHP tabanlı sistem kullanıyorsanız CMS’yi ve eklentileri güncel tutmak elbette gerekli. Fakat bu olayda sorun, uygulamanın üzerinde çalıştığı PHP sürümünde.

WordPress’in en son sürümünü kullanmak, bütün eklentileri güncellemek veya güvenlik eklentisi kurmak, savunmasız PHP sürümünü kendiliğinden düzeltmez.

Paylaşımlı hosting kullanıyorsanız kontrol panelinizden PHP sürümünü kontrol edin. Sürümün gerçekten düzeltilmiş olup olmadığından emin değilseniz hosting firmanıza şu soruyu sorun:

“Sunucumun web isteklerini işleyen PHP çalışma ortamı, 21 Ekim 2026 tarihli CVE-2026-109618 ve CVE-2026-109619 güvenlik açıkları için yamalandı mı? Kullanılan PHP sürümünün tam numarası nedir?”

Docker veya benzeri bir konteyner yapısı kullanıyorsanız ana sunucuyu güncellemek tek başına yeterli olmayabilir. PHP’nin çalıştığı imajın da düzeltilmiş sürümle yeniden oluşturulması ve ilgili konteynerlerin yenilenmesi gerekir.

Bir de şu ayrımı unutmayın: Güvenlik açığının kapatılması, daha önce bir saldırı gerçekleşmişse bunun etkilerini otomatik olarak ortadan kaldırmaz. Sunucunuzun savunmasız olduğu dönemde şüpheli bir etkinlikten kuşkulanıyorsanız erişim kayıtlarını, beklenmedik dosya değişikliklerini ve olağan dışı süreçleri de inceleyin.

Açık kaynak yazılımları desteklemek neden önemli?

Gelelim meselenin benim için başka bir boyutuna.

Ben yıllardır PHP ile projeler geliştiriyorum. PHP yalnızca kullandığım bir programlama dili değil; web geliştirme dünyasında büyük bir ekosistemin parçası. Laravel’den WordPress’e, küçük kişisel projelerden büyük uygulamalara kadar pek çok sistemin arkasında PHP’nin ve açık kaynak topluluğunun emeği var.

Açık kaynak yazılımları desteklememin önemli nedenlerinden biri de bu: Bir yazılımın nasıl geliştirildiğini, sorunların nasıl ele alındığını ve düzeltmelerin nasıl yayımlandığını takip edebilmek.

Elbette açık kaynak olmak, bir yazılımı otomatik olarak güvenli yapmaz. Kaynak kodunun erişilebilir olması da bütün hataların mutlaka bulunacağı anlamına gelmez. Bu olay, herkesin yıllardır kullandığı temel bir yazılım bileşeninde kritik güvenlik sorunları çıkabileceğini hatırlatıyor.

Ama bir güvenlik açığının ortaya çıkmasıyla, bir projenin bu açığı nasıl araştırdığı, düzelttiği ve kullanıcılarını nasıl bilgilendirdiği farklı meseleler. Açık kaynak projelerinin güvenli kalabilmesi için deneyimli geliştiricilere, bağımsız güvenlik denetimlerine, testlere ve sürdürülebilir finansmana ihtiyacı var.

PHP ekibinin yayımladığı bu düzeltmeler de kendiliğinden ortaya çıkmadı. İnsanların araştırması, kodu incelemesi, alternatif çözümleri değerlendirmesi ve geriye dönük uyumluluk gibi zor konularla uğraşması gerekti.

Bu emeği yalnızca bir sorun çıktığında hatırlamamak gerekiyor. Kullandığımız açık kaynak projelerine imkânımız ölçüsünde sponsorluk yapmak, bağışta bulunmak, hata bildirmek, testlere katkı sunmak veya dokümantasyonu iyileştirmek de ekosisteme katkının bir parçası.

Bu konuda daha fazla bilgi edinmek isteyenler, PHP Foundation’ın güvenlik güncellemesi ve PHP’nin güvenlik çalışmalarına ilişkin açıklamasını da okuyabilir.

Sonuç: Panik değil, sorumluluk

Yıllardır yazılım geliştiren biri olarak şunu söyleyebilirim: Hiçbir sistemin kusursuz olduğunu varsaymamak gerekiyor. Önemli olan, bir sorun ortaya çıktığında bunu görmezden gelmemek ve gerekli önlemleri zamanında almak.

Bugün PHP kullanıyorsanız yapmanız gereken ilk şey, web sitenizin hangi PHP sürümünde çalıştığını öğrenmek ve ilgili güvenlik düzeltmesinin uygulanıp uygulanmadığını doğrulamak.

Güncelleyin, gerekiyorsa hosting sağlayıcınızla iletişime geçin ve kullandığınız altyapıyı kontrol edin. Eski projelerde uyumluluk sorunları çıkabilir; bu, güncellemeyi sonsuza kadar ertelemek için bir gerekçe değil, geçişi dikkatli planlamak için bir nedendir.

Açık kaynak yazılımlar sayesinde bugün çok güçlü araçlara erişebiliyoruz. Bu araçlardan yararlanırken onların güvenli kalmasına katkı sunmak ve güvenlik duyurularını ciddiye almak da bizim sorumluluğumuz.

PHP kullanıyorsanız bu güncellemeyi yapılacaklar listenizin en üst sıralarına alın. Bugün kontrol etmek, yarın uğraşmak zorunda kalabileceğiniz çok daha büyük sorunların önüne geçebilir.