PHP'deki Kritik Güvenlik Açıkları: Web Siteniz Etkilenir mi, Kime Ne Sormalısınız?
21 Ekim 2026'da PHP için iki kritik açık (CVE-2026-109618, CVE-2026-109619) ve düzeltme sürümleri yayınlandı. Sitenizin etkilenip etkilenmediğini hızlı karar tablosuyla görün; ajansınıza ve hosting firmanıza soracağınız 6 soruyu öğrenin.
Bir sabah "web sitelerinin yüzde 70'i tehlikede" başlıklı bir haber görüyorsunuz. Siteniz o yüzde 70'in içinde mi? Panik yapmadan önce sorulacak soru şu: sitenizi kim yazdı, kim barındırıyor ve sunucudaki PHP sürümünü kim takip ediyor?
21 Ekim 2026'da PHP ekibi, uzaktan kod çalıştırmaya yol açabilen iki kritik açık için acil düzeltme sürümleri yayınladı. Bu yazı yazılımcılar için değil, web sitesi yaptıran ve yöneten işletmeler için: açık ne anlama geliyor, sizin tarafınızda ne değişir, ajansınıza ve hosting firmanıza ne sormalısınız?
Kısaca: 30 saniyelik özet
- Açık, sitenizin kodunda değil, sitenizin üzerinde çalıştığı PHP altyapısında. Siteniz PHP ile çalışıyorsa konu sizi ilgilendirir.
- İki açık var: CVE-2026-109618 ve CVE-2026-109619. Biri bellek yetersizliği anında bozulan istek verisiyle, diğeri eski (stale) iç durumun sonraki isteğe taşınmasıyla ilgili. İkisi de uzaktan kod çalıştırmaya yol açabilir.
- Düzeltilmiş sürümler: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35.
- PHP 8.1 ve daha eski sürümler PHP projesinden resmi güncelleme almıyor.
- Sorumlu taraf çoğunlukla sunucuyu yöneten taraf: hosting firması, sistem yöneticisi ya da ajansınız. Sizin işiniz doğru soruları sormak.
"Yüzde 70" ne anlama geliyor?
La Presse'in 21 Ekim 2026 tarihli haberi, kritik bir açığın web sitelerinin yaklaşık yüzde 70'ini tehdit ettiğini yazıyor. PHP'nin web'in çok büyük bölümünü çalıştırdığı doğru; ancak bu oranı birincil kaynaklardan doğrulayamadık ve PHP'nin kendi duyurusunda böyle bir rakam yok. Bu yüzden rakamı, haber kaynağına ait bir tahmin olarak okumanızı öneririz.
Önemli olan rakam değil: etkilenebilecek sitelerin çok geniş olması ve düzeltmenin hazır olması. Bekleyerek kazanılacak bir şey yok.
Siteniz etkilenir mi? Hızlı karar tablosu
| Durumunuz | Etkilenir misiniz? | Ne yapmalı? |
|---|---|---|
| Site PHP ile çalışıyor (WordPress, Laravel, CodeIgniter, özel yazılım vb.) | Evet, sunucudaki PHP sürümüne bağlı | PHP sürümünü öğrenin, düzeltilmiş sürüme geçişi isteyin |
| Site yalnızca statik HTML, PHP kullanmıyor | Bu açıklar için hayır | Ek işlem gerekmez |
| Paylaşımlı hosting | Hosting firmasının yamasına bağlı | Firmaya yama tarihini yazılı sorun |
| VPS veya kendi sunucunuz | Evet, sorumluluk sizde ya da yöneticinizde | Paket güncellemesini hemen planlayın |
| PHP 8.1 veya eskisi | Resmi yama yok | Desteklenen sürüme geçiş planı yapın |
Hangi barındırma türünde olduğunuzdan emin değilseniz paylaşımlı, VPS ve bulut hosting karşılaştırmamız farkı anlamanıza yardımcı olur.
Not: PHP duyurusuna göre en yüksek risk mod_php kullanan kurulumlarda; kimlik doğrulaması gerektirmeyen bir istek, uygulama kodu çalışmadan önce açığı tetikleyebiliyor. PHP-FPM, php-cgi, FrankenPHP ve LiteSpeed gibi diğer çalışma biçimleri de etkilenenler arasında. Hangisini kullandığınızı bilmeniz gerekmez, yöneticinizin bilmesi yeter.
Teknik tarafı iş diliyle anlatalım
CVE-2026-109618. Sunucunun belleği bir istek sırasında tükendiğinde PHP, gelen veriyi yarım hazırlanmış halde bırakabiliyor. İstek bittikten sonra yapılan temizlik bu bozuk veriyi geçerliymiş gibi işleyebiliyor. Sonuç, bellekte kontrol dışı davranış ve en kötü senaryoda saldırganın kendi kodunu çalıştırması.
CVE-2026-109619. İsteğe ait bazı iç bilgiler, ait oldukları bellek serbest bırakıldıktan sonra da duruyor. Aynı süreç tarafından işlenen bir sonraki istek bu eski bilgiyi kullanabiliyor.
Resmi kayıtlar: GHSA-w8hw-w9fx-j79w ve GHSA-6wmf-4rv5-p3rp (PHP güvenlik duyurusu).
Ajansınıza ve hosting firmanıza sorulacak 6 soru
Aşağıdaki soruları e-postayla sorun, yanıtı yazılı alın:
- Sitemde şu an hangi PHP sürümü çalışıyor? Cevap 8.5.12, 8.4.27, 8.3.36 veya 8.2.35'ten (ya da daha yenisinden) düşükse yama uygulanmamıştır.
- Yama ne zaman uygulanacak ya da uygulandı mı? Tarih isteyin.
- Güncellemeden önce yedek alınıyor mu, geri dönüş planı var mı? Yedeğin gerçekten geri yüklenebildiği test edilmiş olmalı.
- Güncelleme sonrası hangi sayfalar test edilecek? En az ana sayfa, giriş, ödeme ve form akışları.
- Sitem PHP 8.1 veya daha eski bir sürümde mi? Öyleyse geçiş planı ve maliyeti.
- Bu konuda bana bildirim yapılacak mı? Kritik açıklarda haber vermek iyi bir bakım sözleşmesinin parçasıdır.
Güncelleme hemen yapılamıyorsa
PHP ekibi, güncellemenin yerini tutmayan geçici önlemler de sıralıyor. Bunlar yalnızca sunucu yöneticisi içindir:
- CVE-2026-109618 için:
memory_limit=-1ve istek boyutu sınırlarının (post_max_size) ihtiyaca göre daraltılması; web sunucusu veya konteyner düzeyinde kaynak sınırları. Ayarlar uygulamanın ezemeyeceği biçimde (php_admin_value) verilmeli. - CVE-2026-109619 için:
session.upload_progress.enabled = 0(php.ini veya havuz yapılandırmasında,ini_set()ile değil). Yalnızca PHP 8.5'te ek olarakfatal_error_backtraces = 0.
Bu ayarlar bazı özellikleri etkileyebilir. Kalıcı çözüm güncellemedir.
Bizim yaklaşımımız
Limon Software Solutions olarak kritik bir PHP duyurusu geldiğinde izlediğimiz sıra basit: önce hangi projenin hangi PHP sürümünde çalıştığını çıkarırız, ardından yedek alıp düzeltilmiş sürüme geçeriz, son olarak kritik akışları test eder ve müşteriye yazılı bilgi veririz. Sürüm bilgisini kayıt altında tutmak, bu tür günlerde saatler kazandırır.
Sitenizin barındırılmasını bu sorumlulukla birlikte devretmek isterseniz hosting ve WordPress hosting paketlerimize göz atabilirsiniz.
Sık sorulan sorular
PHP açığı ne demek, benim sitem hacklenir mi?
Açık, saldırganın uygun koşullarda sunucuda kod çalıştırmasına imkân verebiliyor. Düzeltilmiş sürümü kullanıyorsanız bu açıklar için risk kapanır.
Sitemi PHP ile mi yazdılar, nasıl öğrenirim?
Ajansınıza sorun ya da sitenizin yöneticisine "PHP sürümü nedir?" diye yazın. WordPress kullanıyorsanız panelde Araçlar > Site Sağlığı > Bilgi > Sunucu bölümünde de görünür.
Paylaşımlı hostingteyim, kendim bir şey yapmalı mıyım?
Çoğunlukla PHP'yi hosting firması günceller. Yine de yama tarihini yazılı isteyin ve kendi yedeğinizi alın.
PHP 8.1 kullanıyorum, ne olacak?
PHP projesi 8.1 ve eskisi için resmi sürüm yayınlamıyor; yalnızca kaynaktan derleyenler için asgari yamalar paylaştı. Desteklenen bir sürüme geçmek en güvenli yoldur. PHP 8.2'nin güvenlik desteği de 31 Aralık 2026'da sona eriyor.
Güncelleme sitemi bozar mı?
Bozabilir; bu yüzden önce yedek alınmalı, sonra ana akışlar test edilmelidir. Eski eklenti veya kütüphane içeren sitelerde uyumluluk kontrolü gerekir.
Hacklenip hacklenmediğimi nasıl anlarım?
Beklenmedik dosya değişiklikleri, tanımadığınız yönetici hesapları, ani trafik veya kaynak kullanımı artışı işaret olabilir. Şüphede temiz bir yedekten geri dönün ve parolaları değiştirin.
Sonuç
Haber başlığındaki oran tartışılabilir, ama düzeltme sürümleri gerçek ve hazır. Siteniz PHP ile çalışıyorsa bugün yapacağınız iş net: sürümü öğrenin, yedeği doğrulayın, yamayı yazılı isteyin. Yardıma ihtiyacınız olursa Limon Software Solutions ekibine yazabilirsiniz.
Sitenizin PHP Sürümünü Birlikte Kontrol Edelim