PHP Güvenlik Açığı: WordPress Siteniz Etkileniyor mu?

PHP’de Tespit Edilen Kritik Güvenlik Açıkları WordPress Sitelerini Etkileyebilir. Hangi PHP Sürümlerinin Güvenli Olduğunu, Riskleri ve Güncelleme Öncesi Kontrol Etmeniz Gerekenleri İnceliyoruz.

Yazan SEO Kovanı Ekim 22, 2026 12 DK Okuma

Son güncelleme: 22 Ekim 2026. Bu yazı, PHP güvenlik ekibinin 21 Ekim 2026 tarihli duyurusuna dayanıyor; yeni gelişmeler oldukça içeriği güncelleyeceğiz.

Bir WordPress sitesi kullanıyorsanız son güvenlik haberi ilk bakışta kafa karıştırıcı görünebilir:

“PHP’de iki kritik açık bulundu. WordPress sitem de risk altında mı?”

Kısa cevap: Evet, etkileniyor olabilirsiniz. Ancak açık WordPress çekirdeğinde değil, WordPress’in üzerinde çalıştığı PHP katmanında. Sitenizin PHP sürümünü kontrol edin ve 8.5.12, 8.4.27, 8.3.36, 8.2.35 ya da daha yeni bir sürüme geçin. Daha eski bir sürüm kullanıyorsanız hosting sağlayıcınızın güvenlik yaması sunup sunmadığını doğrulayın.^[1]

PHP ekibi 21 Ekim 2026’da CVE-2026-109618 ve CVE-2026-109619 kodlu iki kritik açık için acil güncellemeler yayımladı. Resmî duyuruya göre bu açıklar, kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya kadar gidebiliyor. PHP ekibi bu nedenle bütün kullanıcıları hemen güncellemeye çağırıyor.^[1]

Bu noktada en önemli ayrım şu:

WordPress’i güncellemiş olmanız, PHP’yi de güncellediğiniz anlamına gelmez.

WordPress çekirdeğini, temaları ve eklentileri yönetim panelinden güncelleyebilirsiniz. PHP sürümünü ise çoğunlukla hosting sağlayıcınız veya sunucu yöneticiniz yönetir. Yani WordPress tarafında her şey güncel görünürken siteniz hâlâ açık barındıran bir PHP sürümüyle çalışıyor olabilir.

Bu yazının amacı panik yaratmak değil. Hangi sürümlerin etkilendiğini, sitenizin PHP sürümünü nasıl kontrol edeceğinizi ve güncellemede nelere dikkat etmeniz gerektiğini adım adım anlatıyoruz.

PHP güvenlik açığı nedir ve neden bu kadar önemli?

21 Ekim 2026 tarihli PHP güvenlik duyurusu iki ayrı açığı kapsıyor:

CVE-2026-109618: Bellek yetersizliği (out-of-memory) sırasında PHP, iç istek verileri henüz yarım hazırlanmışken kesintiye uğrayabiliyor. İstek temizlenirken bu geçersiz veri geçerliymiş gibi işlenebiliyor.
CVE-2026-109619: Bir isteğe ait iç durum, bellek serbest bırakıldıktan sonra da kalabiliyor. Aynı PHP süreci (worker) daha sonraki bir isteği işlerken bu eski durumu kullanabiliyor.^[1]

PHP ekibine göre her iki açık da kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırma (unauthenticated remote code execution) riskine yol açabiliyor. Yani saldırganın sitede bir kullanıcı hesabına sahip olması gerekmeyebilir.^[1]

PHP ekibi açıkları duyurmadan bir gün önce, 20 Ekim’de bir ön duyuru yayımladı. Bu duyuruda iki açığın da CVSS v4.0 ölçeğinde 9,2 puan aldığını belirterek kullanıcıları güncellemeye hazırlanmaları için uyardı.^[1] Bu önem derecesi, sıradan bir yazılım hatasından çok daha ciddi bir riske işaret ediyor.

Kimler risk altında?

Resmî duyuru riski tek bir web sunucusu veya hosting türüyle sınırlamıyor. Web isteklerine cevap veren bütün PHP kurulumları etkileniyor; örneğin:^[1]

PHP-FPM,
Apache + mod_php,
php-cgi,
FrankenPHP,
LiteSpeed.

PHP ekibi, kimlik doğrulaması olmadan ve uygulama kodu çalışmadan önce tetiklenebilen bir saldırıyı gösterdiği için Apache mod_php kurulumlarında riski en yüksek seviyede değerlendiriyor.^[1]

Bu yüzden “Ben WordPress kullanıyorum, bu konu PHP geliştiricilerini ilgilendirir.” demek doğru değil. Hosting altyapınız etkilenen bir PHP sürümünü çalıştırıyorsa siteniz de bu açıktan etkilenebilir.

Şu anda saldırı var mı?

22 Ekim 2026 itibarıyla tablo net değil. PHP’nin resmî duyurusu sahada aktif bir saldırıdan söz etmiyor.^[1] Bazı güvenlik firmaları ise açıkları hedef alan tarama ve saldırı denemeleri gördüğünü bildiriyor; doğrulanmış ihlallere dair kanıtlar şimdilik sınırlı.^[2] Ancak açıkların ayrıntıları artık herkese açık olduğu için güncellemeyi ertelemek risklidir.

Açık WordPress’te mi?

Hayır. CVE-2026-109618 ve CVE-2026-109619, WordPress çekirdeğine değil PHP çalışma ortamına ait açıklar. WordPress ise PHP üzerinde çalıştığı için dolaylı olarak risk altına giriyor.

Benzer şekilde WooCommerce, Elementor, özel bir tema veya LiteSpeed Cache kullanmanız bu açıkların kaynağı değil. Ancak bu yazılımların hepsi PHP üzerinde çalışıyor. Alttaki çalışma ortamı güvenli değilse WordPress kurulumunun güncel olması tek başına yeterli olmaz.

Bu yüzden WordPress güvenliğini yalnızca “WordPress, eklentiler ve tema güncel mi?” sorusuyla sınırlamayın. Sunucu yazılımları ve PHP sürümü de aynı güvenlik zincirinin parçasıdır.

WordPress’i güncellemek PHP açığını kapatır mı?

Hayır. WordPress panelinde “Tüm güncellemeler tamamlandı.” mesajını görmek, bu iki açığın kapandığı anlamına gelmez. PHP sürümünü değiştirmek çoğu ortamda şu yollardan biriyle yapılır:

Hosting kontrol panelinden,
Sunucu yönetim sisteminden,
Paket yöneticisinden,
Hosting sağlayıcısının destek ekibi aracılığıyla.

Hosting erişimlerinin ve sunucu sorumluluğunun kimde olduğu bu tür durumlarda kritik hâle gelir. Bu konuyu web sitesi yaptırırken dikkat edilmesi gerekenler rehberimizde ayrıntılı olarak ele aldık.

Hangi PHP sürümleri güvenli?

PHP projesinin 21 Ekim 2026’da yayımladığı yamalı sürümler ve dalların destek durumu şöyle:^[1]^[3]

PHP dalı	Yamalı sürüm	Destek durumu (22 Ekim 2026)
PHP 8.5	8.5.12	Aktif destek (31 Aralık 2027’ye kadar)
PHP 8.4	8.4.27	Aktif destek (31 Aralık 2026’ya kadar), ardından 2028 sonuna kadar güvenlik desteği
PHP 8.3	8.3.36	Yalnızca güvenlik desteği (31 Aralık 2027’ye kadar)
PHP 8.2	8.2.35	Yalnızca güvenlik desteği; 31 Aralık 2026’da sona eriyor

Bu sürümleri veya daha yenilerini kullanmalısınız. Kullandığınız dala göre yapmanız gereken:

PHP 8.5: En az 8.5.12’ye geçin.
PHP 8.4: En az 8.4.27’ye geçin.
PHP 8.3: En az 8.3.36’ya geçin; orta vadede 8.4 veya 8.5’i planlayın.
PHP 8.2: Hemen 8.2.35’e geçin; bu dal 31 Aralık 2026’da destek dışı kalacağı için 8.4 veya 8.5 geçişini de takvime alın.

PHP 8.2 için önemli bir ayrıntı var: Bu dal 31 Aralık 2026’da kullanım ömrünün sonuna (EOL) ulaşacak ve PHP projesinden güvenlik güncellemesi almayı bırakacak.^[3]^[4] Dolayısıyla 8.2.35’e geçmek bugünkü açığı kapatır ama kalıcı bir çözüm değildir.

PHP 8.1 veya daha eski bir sürüm kullanıyorsanız

PHP 8.1 ve öncesi artık PHP projesinden güncelleme almıyor. Bazı Linux dağıtımları ve uzun süreli destek (LTS) sağlayıcıları bu dallara kendi güvenlik yamalarını uyarlayabiliyor (backport). PHP ekibi de açıkların ciddiyeti nedeniyle 7.4, 8.0 ve 8.1 için kaynak koddan derlenebilecek sınırlı yamalar yayımladı.^[1]

Ancak site sahibi açısından doğru soru “PHP 7.4 hâlâ çalışıyor mu?” değil, şudur:

“Kullandığım PHP sürümü, hosting sağlayıcım tarafından hâlâ güvenlik güncellemesi alıyor mu?”

Bunu sağlayıcınızdan net biçimde doğrulayamıyorsanız desteklenen bir PHP sürümüne geçiş planlayın.

WordPress için hangi PHP sürümünü tercih etmeli?

Bir sürümün güvenlik yaması alması ile uzun vadede tercih edilmesi aynı şey değildir.

WordPress Hosting ekibi, 19 Ağustos 2026’da yayımlanan WordPress 7.1 için yeni kurulumlarda PHP 8.4 veya 8.5 öneriyor.^[4] WordPress’in uyumluluk tablosuna göre WordPress 6.9, 7.0 ve 7.1, PHP 8.4 ve 8.5 ile uyumlu. WordPress 6.8 ise PHP 8.4 ile uyumlu, 8.5 ile uyumlu değil.^[5]

Bu yüzden “En yüksek PHP sürümünü seçin.” gibi mekanik bir tavsiye doğru değil. Daha sağlıklı karar sırası şöyle:

WordPress sürümünüzü kontrol edin.
Tema ve eklentilerin güncel olduğundan emin olun.
PHP uyumluluğunu doğrulayın.
Yedek alın.
Mümkünse test ortamında (staging) deneyin.
Desteklenen güncel bir PHP dalına geçin.

Bugün güncel bir WordPress kurulumu için PHP 8.4 olgun ve güçlü bir tercih. Ancak 8.4’ün aktif destek süresi 31 Aralık 2026’da bitiyor; sonrasında 2028 sonuna kadar yalnızca güvenlik güncellemesi alacak. Bugün yeni bir geçiş planlıyorsanız ve eklentileriniz uyumluysa PHP 8.5 daha uzun bir destek süresi sunuyor.^[3]^[4]^[5]

WordPress sitenizin PHP sürümünü nasıl öğrenirsiniz?

Bunun için teknik bilgiye ihtiyacınız yok. WordPress’in Site Sağlığı ekranı, yönetim panelinde Araçlar menüsünün altında bulunuyor.^[6] PHP sürümünü görmek için şu yolu izleyin:

Araçlar → Site Sağlığı → Bilgi → Sunucu

Örneğin burada 8.4.26 görüyorsanız, 21 Ekim 2026 güncellemesi açısından 8.4.27 veya daha yeni bir yamalı sürüme geçmeniz gerekir.

Hosting panelinizdeki PHP sürümünü Site Sağlığı ekranındakiyle karşılaştırmak da faydalıdır. Birden fazla PHP çalıştırıcısı (handler), alan adı veya alt alan adı bulunan sunucularda her sitenin aynı sürümle çalıştığını varsaymayın.

Hosting firmanız “Güncelledik.” diyorsa yine de kontrol edin

Yönetilen hosting sağlayıcılarının çoğu güvenlik yamalarını sunucu seviyesinde uygular. PHP ekibi de Linux dağıtımlarının ve LTS sağlayıcılarının yamaları önceden aldığını belirtiyor.^[1] Ancak buradan “Hosting firması kesin güncellemiştir.” sonucu çıkmaz. Kontrol etmeniz gereken şey, sitenizin gerçekte çalıştığı PHP sürümü veya sağlayıcının bu açıklar için uyguladığı yamadır.

Paylaşımlı hosting kullanıyorsanız destek ekibine şöyle sorabilirsiniz:

“CVE-2026-109618 ve CVE-2026-109619 için PHP sürümümüz yamalandı mı? Alan adım hangi yamalı PHP sürümüyle çalışıyor?”

Bu soru, “Sunucularınız güvenli mi?” gibi genel bir sorudan çok daha net bir cevap almanızı sağlar.

PHP’yi güncellemeden önce ne yapmalısınız?

Kritik bir açık söz konusu olduğu için güncellemeyi geciktirmemek gerekiyor. Aynı dal içindeki bir yama güncellemesi (örneğin 8.4.26’dan 8.4.27’ye) genellikle uyumluluk sorunu yaratmaz; bu durumda öncelik hızlı davranmaktır. Ancak bir ana sürümden diğerine (örneğin 8.2’den 8.4’e) geçiyorsanız bunu canlı sitede kontrolsüz biçimde yapmak doğru değil. WordPress’in resmî PHP güncelleme rehberi de güncellemeden önce yedek almayı ve WordPress, tema ve eklentileri güncellemeyi öneriyor.^[7]

1. Tam yedek alın

En azından WordPress dosyalarını, wp-content klasörünü, veritabanını ve gerekli sunucu yapılandırmalarını geri döndürülebilir biçimde yedekleyin. Yedek almak kadar, yedekten gerçekten geri dönebildiğinizi doğrulamak da önemlidir.

2. WordPress, tema ve eklentileri güncelleyin

Eski bir eklenti, PHP 8.4 veya 8.5’te kullanımdan kaldırılmış (deprecated) fonksiyon uyarıları, tür hataları veya ölümcül hatalar (fatal error) üretebilir. PHP sürümünü değiştirmeden önce uygulama katmanını güncellemek bu riski azaltır.

3. Mümkünse test ortamında deneyin

Özellikle WooCommerce, üyelik sistemi, rezervasyon, ödeme altyapısı, özel tema veya özel PHP kodu kullanan projelerde bir test ortamı (staging) ciddi fayda sağlar. Ana sayfanın açılması tek başına uyumluluk testi değildir.

4. Kritik kullanıcı akışlarını deneyin

Güncellemeden sonra yalnızca sitenin açıldığını kontrol etmeyin. Bir e-ticaret sitesinde sepete ekleme, ödeme, sipariş e-postaları, kullanıcı girişi ve yönetim panelini deneyin. Kurumsal bir sitede ise iletişim ve teklif formlarını, aramayı, dosya yüklemeyi, çok dilli yapıyı, önbelleği (cache) ve zamanlanmış görevleri (cron) kontrol edin.

5. Süreçleri yeniden başlatın ve kayıtları kontrol edin

PHP paketini güncelledikten sonra PHP-FPM, Apache ve çalışan PHP süreçlerinin yeniden başlatıldığından emin olun; aksi hâlde eski kod bellekte çalışmaya devam edebilir. Ardından PHP ve web sunucusu kayıtlarını (log) inceleyin. Görünürde sorunsuz çalışan bir site arka planda uyarı, kullanımdan kaldırma bildirimi, ölümcül hata veya zaman aşımı üretiyor olabilir.

Site çalışıyorsa güncelleme gerçekten gerekli mi?

Evet. Bir güvenlik güncellemesinin gerekliliği, sitenin o anda hata verip vermemesiyle ölçülmez. Siteniz hızlı açılıyor, hiçbir hata göstermiyor ve Site Sağlığı ekranında ciddi bir sorun görünmüyor olabilir. Bunların hiçbiri alttaki PHP açığının olmadığını kanıtlamaz.

Güvenlik açığı “Site şu anda bozuk mu?” sorusuyla ilgili değildir; belirli koşullar oluştuğunda bir saldırganın sistemi kötüye kullanıp kullanamayacağıyla ilgilidir.

PHP ekibinin bu olayda bu kadar net davranmasının nedeni de bu. Resmî duyuruda tam bir geçici çözüm olmadığı ve güncellemenin tek güvenli seçenek olduğu açıkça belirtiliyor.^[1]

Cloudflare veya WAF kullanmak PHP açığını kapatır mı?

Hayır. Cloudflare, başka bir CDN veya web uygulaması güvenlik duvarı (WAF) saldırı yüzeyinin bir kısmını daraltabilir; belirli istek boyutlarını, botları veya bilinen saldırı kalıplarını engelleyebilir. Cloudflare ve WAF ayarları bu açıdan faydalı bir savunma katmanıdır. Ancak PHP çalışma ortamındaki hatayı düzeltmez.

Dolayısıyla “WAF var, PHP güncellemesine gerek yok.” yaklaşımı yanlıştır. WAF savunmanın bir katmanıdır; yama ise açığın kendisini düzeltir.

PHP ekibinin geçici önlemleri var mı?

Var; ancak bunları güncellemenin yerine geçen ayarlar olarak görmeyin. PHP duyurusu, hemen güncelleme yapılamıyorsa belirli saldırı yollarını daraltabilecek bazı yapılandırmalar listeliyor. Bunlar arasında bellek sınırı, POST boyutu, oturum yükleme ilerlemesi (session upload progress) ayarı ve PHP süreçlerinin yeniden başlatılması gibi oldukça teknik adımlar var.^[1]

Fakat PHP’nin kendi ifadesiyle bunların hiçbiri kurulumu güvenli hâle getirmiyor. Bu yüzden paylaşımlı hosting kullanan bir site sahibinin internetten birkaç php.ini satırı kopyalayıp sorunu çözdüğünü varsaymak yerine hosting sağlayıcısının güncellemesini doğrulaması daha doğru. Kendi VPS veya fiziksel sunucunuzu yönetiyorsanız da öncelik yamalı PHP paketlerine geçmek olmalı.

Sitenizin hacklendiğini nasıl anlarsınız?

Etkilenen bir PHP sürümü kullanmış olmak, sitenizin mutlaka ele geçirildiği anlamına gelmez. İki kavramı ayırmak gerekir:

Açık barındırmak (vulnerable): Saldırıya açık bir sürüm kullanmak.
Ele geçirilmiş olmak (compromised): Açığın gerçekten kullanılmış ve sistemin ele geçirilmiş olması.

Yalnızca PHP sürümünüzün açık barındırdığını tespit ettiyseniz önce güncelleyin. Şüpheli bir durum varsa ayrıca şunları inceleyin:

WordPress yönetici kullanıcıları,
Son değiştirilmiş PHP dosyaları,
Beklenmeyen eklenti veya MU-plugin dosyaları,
Web sunucusu erişim ve hata kayıtları,
PHP kayıtları,
Zamanlanmış görevler (cron),
Dosya bütünlüğü,
WAF kayıtları.

Araştırmacılar bu açıklarla sunucu belleğindeki bilgilerin de okunabildiğini gösterdi. Patchstack bu yüzden ihlal belirtisi gösteren sunucularda veritabanı şifrelerinin, API anahtarlarının ve diğer gizli bilgilerin değiştirilmesini öneriyor.^[2]

Ayrıca yalnızca PHP sürümünü yükseltmek, geçmişte yapılmış olası değişiklikleri geri almaz. Bir güvenlik olayından şüpheleniyorsanız olay müdahalesini ve temiz bir yedekten geri dönme sürecini ayrıca değerlendirin.

PHP güncellemesi SEO’yu etkiler mi?

Doğru yapıldığında PHP güncellemesinin amacı sıralamayı değiştirmek değil, sunucu ortamını güvenli tutmaktır. Ancak kötü planlanmış bir geçiş dolaylı SEO sorunları yaratabilir. Örneğin güncellemeden sonra:

Sayfalar 500 hatası verebilir,
Bazı URL’ler boş dönebilir,
Site haritası üretimi bozulabilir,
Önbellek katmanı çalışmayabilir,
Form veya e-ticaret işlemleri hata verebilir,
Zamanlanmış görevler aksayabilir.

Google açısından sorun “PHP 8.4 kullanmanız” değildir. Sorun, güncellemeden sonra sitenin taranabilirliği veya kullanıcı deneyimi bozulursa ortaya çıkar. Bu yüzden teknik bakım ile SEO’yu birbirinden ayrı düşünmeyin. PHP geçişinden sonra en azından şunları kontrol edin:

Kritik URL’lerin HTTP durum kodları,
Site haritası,
robots.txt,
Canonical etiketleri,
Search Console tarama ve dizine ekleme sinyalleri,
Core Web Vitals veya temel hız metrikleri.

Bu kontrolleri nasıl yapacağınızı ilk site incelemesi rehberimizde adım adım anlattık.

WordPress site sahibi bugün ne yapmalı?

Yazının tamamını okumak istemiyorsanız uygulanabilir kontrol listesi şu:

Mevcut PHP sürümünüzü öğrenin.
8.5 kullanıyorsanız en az 8.5.12’ye geçin.
8.4 kullanıyorsanız en az 8.4.27’ye geçin.
8.3 kullanıyorsanız en az 8.3.36’ya geçin.
8.2 kullanıyorsanız en az 8.2.35’e geçin ve 8.4 ya da 8.5 geçişini planlayın.
8.1 veya daha eski sürümlerde sağlayıcınızın yama durumunu doğrulayın; mümkünse desteklenen bir sürüme geçin.
Ana sürüm değiştirmeden önce tam yedek alın.
WordPress, tema ve eklentileri güncelleyin.
Güncellemeden sonra PHP süreçlerinin yeniden başlatıldığından emin olun.
Formları, ödemeyi, girişi, önbelleği ve kritik sayfaları test edin.
PHP ve web sunucusu kayıtlarında yeni ölümcül hata olup olmadığını kontrol edin.
“WordPress güncel” mesajını PHP’nin güncel olduğunun kanıtı saymayın.

Bu adımlar yalnızca bu iki açık için değil, WordPress bakım politikanız için de iyi bir temel oluşturur.

Sonuç: WordPress güncelse bile PHP’yi kontrol edin

CVE-2026-109618 ve CVE-2026-109619, WordPress çekirdeğinde bulunan açıklar değil. Ancak WordPress PHP üzerinde çalıştığı için bu ayrım site sahiplerini riskin dışında bırakmıyor.

PHP ekibi iki açığın kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya kadar gidebileceğini ve web isteklerine cevap veren bütün PHP kurulumlarını etkilediğini açıkça belirtiyor. Ekip 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerini yayımladı ve tam bir geçici çözüm olmadığı için güncellemeyi tek güvenli seçenek olarak tanımlıyor.^[1]

WordPress tarafında ise güncel kurulumlarda PHP 8.4 ve 8.5 artık olgun ve desteklenen seçenekler.^[4]^[5] Bugün yapacağınız en basit kontrol bile değerli:

WordPress → Araçlar → Site Sağlığı → Bilgi → Sunucu → PHP sürümü

Sürümünüz yamalı değilse hosting sağlayıcınızla veya sunucu yöneticinizle güncellemeyi hemen planlayın. PHP 8.2 kullanıyorsanız yalnızca bugünkü açığı kapatmakla yetinmeyin; 31 Aralık 2026’daki destek bitiş tarihini de hesaba katarak güncel bir dala geçiş planı yapın.

Bir web sitesinin güvenliği yalnızca eklenti güncellemekten ibaret değildir:

WordPress, tema, eklenti, PHP, web sunucusu ve hosting altyapısı aynı güvenlik zincirinin parçalarıdır. Bu zincirin en eski halkası, çoğu zaman bütün sistemi gereksiz yere risk altında bırakır.

WordPress sitenizin teknik altyapısını yeniliyor veya yeni bir proje planlıyorsanız WordPress web tasarım hizmetimizde güncel PHP uyumluluğunu, performansı ve teknik SEO temelini birlikte ele alıyoruz. Eski bir siteyi güncel altyapıya taşımak için web sitesi yenileme sürecimizi inceleyebilir, iletişim sayfamızdan bize ulaşabilirsiniz.

Kaynaklar

Blog İçeriğini Yapay Zekâya Sorun

Tercih Ettiğiniz Yapay Zekâ Aracıyla Yazıyı Özetletin, Aklınıza Takılan Noktaları Sorun & Anlatılan Adımları Kendi Sitenize Nasıl Uyarlayabileceğinizi Konuşun.

CHAT GPT CLAUDE GEMINI GROK