PHP RCE Açığı: WordPress Sitenizi Nasıl Korursunuz?

WordPress güvenliği söz konusu olduğunda ilk akla gelenler genellikle tema, eklenti ve çekirdek güncellemeleri oluyor. Ancak sitenin güvenliği, yönetim panelinde gördüğümüz bu bileşenlerle sınırlı değil. WordPress’in çalışmasını sağlayan PHP’de ortaya çıkan bir açık, kullandığımız tema ve eklentiler güncel olsa bile web sitemizi etkileyebiliyor.

21 Ekim 2026’da duyurulan iki kritik PHP RCE açığı da tam olarak bu nedenle önemli. Uzaktan kod çalıştırılmasına yol açabilen bu güvenlik sorunları, yalnızca belirli bir eklentiyi kullanan siteleri değil, savunmasız PHP kurulumlarında çalışan farklı web uygulamalarını ilgilendiriyor. WordPress kullanıcıları için çözüm ise yeni bir güvenlik eklentisi aramaktan önce, sitenin hangi PHP sürümünde çalıştığını öğrenmek ve gerekli güvenlik güncellemesinin uygulanmasını sağlamak.

Peki PHP’deki bu açıklar WordPress sitelerini nasıl etkiliyor? Hangi sürümler güncellenmeli, hosting firmasından ne istenmeli ve güncellemeden sonra nelere bakılmalı? Bu rehberde konuyu, kendi blogunu yöneten kullanıcıların da uygulayabileceği adımlarla inceleyelim.

PHP RCE Açığı Nedir?

RCE, Remote Code Execution ifadesinin kısaltmasıdır ve uzaktan kod çalıştırma anlamına gelir. Böyle bir açık başarıyla kullanıldığında saldırgan, etkilenen sistemde kendi kodunu çalıştırabilir. Bir web sitesi açısından bu; dosyaların değiştirilmesi, uygulamanın erişebildiği bilgilerin okunması veya siteye zararlı içerik yerleştirilmesi gibi sonuçlara yol açabilir.

Erişimin kapsamı, ele geçirilen işlemin yetkilerine bağlıdır. Dolayısıyla her RCE açığı saldırgana doğrudan sunucunun bütün yönetim yetkilerini vermez. Bununla birlikte WordPress dosyalarına ve veritabanı bağlantı bilgilerine erişebilen bir PHP işleminin ele geçirilmesi, site için başlı başına ciddi bir sorundur.

PHP ekibinin duyurduğu CVE-2026-109618 ve CVE-2026-109619 kayıtları, PHP motorunun bellek ve istek yönetimiyle ilgili iki ayrı hatayı kapsıyor. Her iki açığın da resmî kayıtlardaki CVSS v4.0 önem derecesi 9,2/10.

Teknik ayrıntılar, PHP ekibinin CVE-2026-109618 duyurusunda ve CVE-2026-109619 duyurusunda açıklanıyor. Site sahipleri açısından bu kayıtların ortak sonucu açık: Kalıcı çözüm, ilgili düzeltmeleri içeren PHP paketine geçmek.

WordPress Siteleri Bu Açıktan Nasıl Etkilenir?

Bir ziyaretçi WordPress sitenizdeki bir yazıyı açtığında, önbellekten karşılanmayan isteklerde PHP devreye girer. WordPress dosyaları çalıştırılır, gerekli veriler alınır ve ziyaretçiye gönderilecek sayfa hazırlanır. PHP motorundaki bir güvenlik sorunu, bu işlemin dayandığı altyapıyı etkiler.

Bu yüzden WordPress’in, temanızın ve bütün eklentilerinizin güncel olması tek başına yeterli değildir. Sunucudaki PHP kurulumu savunmasızsa, WordPress tarafındaki güncellemeler bu açığı kapatmış olmaz. WordPress’in resmî açıklamasında da sorunların WordPress’e özgü olmadığı ve bunlar için ayrı bir WordPress güncellemesi planlanmadığı belirtiliyor.

Özellikle Apache’nin mod_php yapılandırmasında doğrulanan saldırı, uygulama kodu çalışmaya başlamadan önce tetiklenebiliyor. Başka bir ifadeyle saldırının gerçekleşmesi için WordPress yönetim paneline giriş yapılması veya sitede kullanıcı hesabı bulunması gerekmeyebiliyor. PHP-FPM, CGI, FrankenPHP ve LiteSpeed üzerinden çalışan PHP kurulumları da resmî duyuruda risk kapsamında değerlendiriliyor; ancak istismar koşulları her ortamda aynı değil.

Başarılı bir saldırının WordPress üzerindeki sonuçları, sunucunun izinlerine ve uygulamanın erişebildiği kaynaklara göre değişebilir:

• WordPress dosyaları değiştirilerek ziyaretçiler başka adreslere yönlendirilebilir.
• Siteye sonradan yeniden erişmek için zararlı dosyalar bırakılabilir.
• Uygulamanın erişebildiği veritabanı bilgileri ve kullanıcı verileri tehlikeye girebilir.
• İçeriğe istenmeyen bağlantılar veya spam sayfalar eklenebilir.
• Kaynak tüketimi ve hatalar nedeniyle site kullanılamaz hâle gelebilir.

Bunlar olası etkilerdir; savunmasız sürüm kullanan her sitenin ele geçirildiği anlamına gelmez. Ancak sitenin normal açılması da güvenli olduğunu göstermez. Öncelikle açık kapatılmalı, şüpheli bir belirti varsa bunun için ayrıca inceleme yapılmalıdır.

Hangi PHP Sürümleri Güvenlik Güncellemesini İçeriyor?

İlk iki kritik açığı kapatan sürümler PHP 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 olarak yayımlandı. Aşağıdaki tablo, her PHP dalındaki ilk düzeltilmiş sürümü gösteriyor. Kullanacağınız sürümü seçerken daha yeni güvenlik güncellemelerini de takip etmelisiniz.

Burada dikkat edilmesi gereken nokta, yalnızca PHP’nin ana sürümüne bakmamaktır. Örneğin “PHP 8.4 kullanıyorum” bilgisi yeterli olmaz; 8.4.26 ile 8.4.27 arasında bu açıklar bakımından önemli bir fark bulunur. Her sürüm, kendi dalındaki düzeltmeyle karşılaştırılmalıdır.

Bazı Linux dağıtımları ve uzun süreli destek sağlayıcıları, güvenlik düzeltmelerini mevcut paketlerine geri taşıyabilir. Böyle bir durumda temel sürüm numarası eski görünse de kullanılan paket yamayı içerebilir. Bunu anlayabilmek için sağlayıcının güvenlik bülteni ve tam paket sürümü kontrol edilmelidir. T.C. Siber Güvenlik Başkanlığının bildirimi de üretici sürümlerinin yanında dağıtım ve LTS sağlayıcılarının yamalı paketlerine yer veriyor.

Eski PHP dallarında kalmayı uzun vadeli bir çözüm olarak görmemek gerekir. PHP’nin resmî destek takvimine göre PHP 8.1 ve önceki sürümlerin proje tarafından verilen güvenlik desteği sona ermiş durumda. PHP 8.2’nin güvenlik desteği de 31 Aralık 2026’da bitiyor. Bu nedenle güncelleme planında yalnızca bugünkü açığı değil, kullanılan dalın destek süresini de dikkate alın.

23 Ekim’de Açıklanan Ek Güvenlik Sorunu

PHP ekibi, ilk duyurunun ardından CVE-2026-115560 numaralı ek bir risk hakkında da bilgi paylaştı. Bu sorun, oturum verilerinin işlenmesinde belirli yapılandırmaların ve uygulama davranışlarının birlikte bulunmasını gerektiriyor. Dolayısıyla ilk iki açıktan ayrı değerlendirilmesi gerekiyor.

PHP’nin 23 Ekim tarihli açıklamasına göre risk; yapılandırmada session.serialize_handler değerinin php_binary veya php_serialize olması, uygulamanın bunu çalışma sırasında php değerine çevirmesi ve ardından session_start() çağırmasıyla ilişkili. Yükleme ilerlemesi özelliğinin de açık olması gerekiyor.

Her WordPress sitesi bu koşulları taşımayabilir; ancak kullanılan eklentiler ve özel kodlar değerlendirmeye dâhil edilmelidir. Duyuruda, sonraki olağan hata düzeltme sürümüne kadar session.upload_progress.enabled=0 ayarı öneriliyor. Bu nedenle yukarıdaki sürümlere geçilmesini, bu ek sorun için de otomatik olarak yeterli kabul etmemek gerekir.

WordPress’te PHP Sürümü Nasıl Öğrenilir?

PHP sürümünü öğrenmek için sunucu komutlarına hâkim olmanız gerekmiyor. WordPress yönetim panelindeki Site Sağlığı bölümü üzerinden sitenizin kullandığı sürümü görebilirsiniz:

1. WordPress yönetim paneline giriş yapın.
2. Araçlar → Site Sağlığı bölümünü açın.
3. Bilgi sekmesine geçin.
4. Sunucu başlığı altında PHP sürümünü bulun.
5. Varsa PHP SAPI bilgisini de not alın; bu bilgi PHP’nin hangi yöntemle çalıştırıldığını anlamaya yardımcı olur.

Ardından hosting panelinde aynı alan adı için seçili sürümü kontrol edin. Birden fazla siteniz varsa bu işlemi her site için tekrarlayın. Aynı hosting hesabındaki iki alan adı farklı PHP sürümlerinde çalışabilir; alt alan adlarında ve eski deneme kurulumlarında da benzer bir durum bulunabilir.

SSH Üzerinden PHP Sürümünü Kontrol Etmek

SSH erişiminiz varsa terminaldeki PHP sürümünü şu komutla öğrenebilirsiniz:

php -v

Ancak bu komutun gösterdiği sürüm, web sitenizin kullandığı PHP ile aynı olmayabilir. Özellikle kontrol paneli bulunan sunucularda, terminalde başka bir PHP kurulumu çalışırken alan adı farklı bir PHP-FPM havuzuna bağlı olabilir. Bu nedenle komut çıktısını, WordPress Site Sağlığı bilgisi ve alan adının sunucu ayarlarıyla birlikte değerlendirin.

Sürüm öğrenmek için herkese açık bir phpinfo.php dosyası bırakmanız gerekmez. Paneldeki bilgiler yeterli değilse hosting desteğinden ilgili alan adının web PHP sürümünü ve paket durumunu kontrol etmesini isteyin.

Hosting Kullanan WordPress Site Sahipleri Ne Yapmalı?

Paylaşımlı hosting veya yönetilen WordPress hosting kullanıyorsanız PHP paketlerinin güncellenmesi genellikle sağlayıcının sorumluluğundadır. Size düşen, sitenizin hangi sürümde çalıştığını öğrenmek ve güvenlik düzeltmesinin o kuruluma uygulandığını doğrulatmaktır. Panelde yeni bir sürümün görünmesiyle alan adınızın o sürümde çalışması aynı şey değildir.

1. Hosting Firmanızdan Yama Durumunu Öğrenin

Destek kaydında alan adınızı ve mevcut PHP sürümünüzü belirtin. Yalnızca “Sunucum güvenli mi?” diye sormak yerine ilgili açıkların kapatılıp kapatılmadığını sorun. Böylece verilecek yanıt doğrudan ihtiyacınız olan bilgiyi kapsar.

Merhaba, alan adımın kullandığı PHP kurulumunda CVE-2026-109618 ve CVE-2026-109619 düzeltmelerinin uygulanıp uygulanmadığını öğrenmek istiyorum. Kullanılan tam paket sürümünü veya ilgili güvenlik bültenini paylaşabilir misiniz? Güncellemeden sonra PHP çalışanları yeniden başlatıldı mı? Ayrıca CVE-2026-115560 için yapılandırmanın değerlendirilmesini ve gerekli önlemin uygulanmasını rica ediyorum.

2. Dosya ve Veritabanı Yedeğinizi Hazırlayın

PHP sürümünü değiştirmeden önce WordPress dosyalarının ve veritabanının güncel yedeğini alın. Yedeğin yalnızca panelde listelenmesiyle yetinmeyin; indirilebildiğini, hangi tarihe ait olduğunu ve gerektiğinde nasıl geri yükleneceğini öğrenin. Mümkünse bir kopyasını hosting hesabının dışında saklayın.

Yedek almak açığı kapatmaz; güncelleme sırasında oluşabilecek uyumluluk sorunlarında geri dönüş imkânı sağlar. Saldırı şüphesi bulunan bir sistemden alınmış yedeği ise doğrudan temiz yedek olarak değerlendirmeyin.

3. Uyumlu ve Yamalı PHP Sürümüne Geçin

cPanel’de MultiPHP Manager veya PHP seçicisi, Plesk’te ise alan adının PHP ayarları üzerinden sürüm seçimi yapılabilir. Menü adları hosting firmasına göre değişebilir. Bazı hizmetlerde bu işlemi destek ekibinin yapması gerekir.

Seçtiğiniz sürümün güvenlik düzeltmelerini içerdiğini doğrulayın. Hâlihazırda desteklenen bir PHP dalındaysanız, o dalın yamalı sürümüne geçmek acil düzeltmeyi uygulamak için uygun olabilir. Eski ve desteksiz bir sürümden geçişte ise tema, eklenti ve PHP uzantılarının uyumluluğu ayrıca kontrol edilmelidir.

4. Değişikliğin Sitenize Uygulandığını Kontrol Edin

İşlemden sonra Site Sağlığı bölümüne dönerek PHP sürümüne tekrar bakın. Geri taşınmış bir dağıtım yaması kullanılıyorsa sağlayıcının tam paket bilgisini esas alın. Ardından sitenin ziyaretçi tarafını ve yönetim panelini deneyin. Güncelleme tamamlandığı hâlde yanlış alan adının eski PHP kurulumuna bağlı kalması gibi durumlar böylece fark edilebilir.

Kendi VPS veya VDS Sunucunuzu Yönetiyorsanız

Sunucuyu kendiniz yönetiyorsanız önce PHP’nin hangi kaynaktan kurulduğunu belirlemelisiniz. İşletim sisteminin paketleri, üçüncü taraf depolar, kontrol panelinin sağladığı PHP sürümleri ve konteynerler farklı güncelleme yöntemleri kullanabilir. Aynı sunucuda birden fazla PHP kurulumu bulunması da mümkündür.

Bu nedenle yalnızca varsayılan PHP paketini güncellemek yeterli olmayabilir. Alan adlarının kullandığı PHP işleyicilerini ve havuzlarını belirleyin; düzeltmeleri ilgili kurulumlara uygulayın. Dağıtım veya kontrol paneli sağlayıcısının duyurusuna göre gerekli servisleri yeniden başlatın ve çalışan sürümü web üzerinden doğrulayın.

• Bütün alan adlarını, alt alan adlarını ve açık test kurulumlarını listeleyin.
• Her birinin kullandığı PHP sürümünü ve işleyicisini belirleyin.
• İlgili paket kaynağından güvenlik güncellemesini uygulayın.
• Eski PHP çalışanlarının yenilendiğini kontrol edin.
• Birden fazla sunucu veya konteyner kopyası varsa işlemi her kopya için doğrulayın.

Servis adları ve paket yolları ortama göre değiştiği için farklı bir sunucuya ait komutları doğrudan uygulamayın. Özellikle Plesk gibi panellerin kendi PHP paketleriyle işletim sisteminin varsayılan PHP paketlerini birbirinden ayırın.

Yamayı hemen uygulayamıyorsanız savunmasız PHP kurulumuna erişimi sunucu veya ağ düzeyinde sınırlandırmayı değerlendirin. WordPress’in bakım eklentisiyle bir uyarı sayfası göstermek, gelen isteğin PHP tarafından işlenmesini mutlaka engellemez. Gerekirse yama uygulanana kadar hizmetin geçici olarak kapatılması, sistem yöneticisiyle birlikte değerlendirilmelidir.

Geçici Güvenlik Ayarları Açığı Kapatır mı?

PHP ekibinin duyurularında, güncellemenin hemen yapılamadığı durumlar için bazı geçici önlemler bulunuyor. Ancak bunlar belirli saldırı yollarını azaltıyor; ilk iki kritik açık için PHP güncellemesinin yerini tutmuyor.

Oturum Tabanlı Yükleme İlerlemesini Kapatmak

session.upload_progress.enabled = Off

Bu ayar, PHP’nin oturum üzerinden dosya yükleme ilerlemesini takip eden özelliğini kapatır. Dosya yüklemeyi tamamen kapatmakla aynı işlem değildir; ancak bu özelliği kullanan bir eklentinin ilerleme göstergesi etkilenebilir. Özelliğin işleyişi PHP’nin yükleme ilerlemesi belgesinde açıklanıyor.

Ayarın hangi dosyada yapıldığı önemlidir. Resmî teknik öneri, değişikliğin istek ayrıştırılmadan önce geçerli olan php.ini, PHP-FPM havuzu veya sunucu yapılandırmasında uygulanması ve bütün PHP çalışanlarının yeniden başlatılmasıdır. FPM üzerinde .user.ini dosyasına veya WordPress içinden yapılan ini_set() çağrısına güvenilmemelidir.

Paylaşımlı hosting kullanıyorsanız bu ayarı hosting desteğine uygulatın. wp-config.php içine bir satır eklemek, gerekli erken yapılandırmanın sağlandığını göstermez. Ayrıca bu ayar ilk iki kritik açığın bütün yollarını kapatmadığından PHP güncellemesi yine yapılmalıdır.

Bellek ve İstek Sınırlarını Değiştirmek

CVE-2026-109618 duyurusunda memory_limit=-1 değerinin idari düzeyde uygulanması, belirli bir saldırı yoluna karşı geçici seçenek olarak yer alıyor. Ancak PHP’nin bellek sınırını kaldırmak kaynak tüketimini artırabilir ve bütün bellek ayırma hatalarını engellemez. Bu nedenle sıradan bir WordPress performans ayarı gibi uygulanmamalıdır.

İstek boyutu, girdi sayısı ve yükleme sınırları da sunucunun kaynaklarıyla uygulamanın ihtiyaçları birlikte değerlendirilerek düzenlenmelidir. Örneğin medya yüklemesi yapılan bir blogda sınırları gereğinden fazla düşürmek, görsel yüklemeyi veya içe aktarma işlemlerini bozabilir. Bu değişiklikler sistem yöneticisinin uygulayacağı geçici koruma planının parçası olmalıdır.

Güvenlik Eklentisi, WAF veya CDN Kullanmak Yeterli mi?

WordPress güvenlik eklentileri; giriş denetimi, dosya değişikliği takibi ve olay kaydı gibi alanlarda yararlı olabilir. Ancak PHP motorundaki bir hatayı düzeltmek için PHP paketinin güncellenmesi gerekir. Özellikle uygulama başlamadan tetiklenebilen saldırılarda, WordPress içinde çalışan bir eklentiyi tek koruma olarak görmek doğru olmaz.

Web uygulaması güvenlik duvarı, yani WAF, belirli istekleri PHP’ye ulaşmadan engelleyebilir. Yine de hangi saldırı yollarını kapsadığı, kuralların etkinliği ve kaynak sunucuya doğrudan erişim bulunup bulunmadığı kontrol edilmelidir. CDN kullanmak veya trafiğin bir bölümünü önbellekten sunmak da PHP güncellemesinin yerine geçmez.

LiteSpeed Cache kullanan sitelerde ayrıca eklentiyle PHP kurulumunu birbirinden ayırmak gerekir. LiteSpeed Cache ayarları rehberinde anlattığım önbellek düzeni, uygun isteklerin daha düşük maliyetle karşılanmasını sağlar. Ancak eklentiyi güncellemek veya önbelleği temizlemek, sunucudaki PHP güvenlik açığını kapatmaz.

PHP Güncellemesinden Sonra WordPress’te Neleri Kontrol Etmelisiniz?

PHP güncellemesinden sonra yalnızca ana sayfayı açıp işlemi tamamlanmış saymayın. Ziyaretçilere gösterilen sayfa önbellekten geliyor olabilir; yönetim paneli, form gönderimi veya medya yükleme gibi işlemlerdeki bir sorun ilk bakışta fark edilmeyebilir.

Bir uyumsuzluk çıkarsa nedenini hata kaydından araştırın. Sorun eski bir eklentiye, temaya veya eksik PHP uzantısına bağlı olabilir. İlk çözüm olarak güvenlik düzeltmesini içermeyen eski sürüme dönmek, kapatmaya çalıştığınız riski yeniden oluşturur. Gerekirse sorunlu bileşeni güncelleyin veya kontrollü biçimde devre dışı bırakarak inceleyin.

Denemeleri sitenin bir kopyasında yapmak faydalıdır. Ancak bu ortamın canlı sunucudaki uzantıları ve yapılandırmayı ne ölçüde temsil ettiğini de bilmek gerekir. WordPress Playground ve Blueprint rehberinde ele aldığım önizleme ortamı, eklenti davranışını incelemek için kullanılabilir; canlı hostingdeki PHP paketinin yamalandığını ise ayrıca doğrulamalısınız.

Saldırı Şüphesi Varsa Nasıl İlerlemelisiniz?

Tanımadığınız bir yönetici hesabı, beklenmedik yönlendirmeler, değişen dosyalar veya kendiliğinden oluşan sayfalar inceleme gerektirir. Ancak tek başına bir hata mesajı, yüksek trafik veya PHP çökmesi, sitenin bu açıklardan biriyle ele geçirildiğini kanıtlamaz.

Şüpheli bir durumla karşılaşırsanız hosting firmanızla görüşün, erişimi gerektiği ölçüde sınırlandırın ve günlüklerin korunmasını sağlayın. Temizlikten önce alınacak inceleme kopyasını, geri yüklemek için kullanacağınız temiz yedekten ayrı tutun. WordPress’in saldırıya uğrayan siteler için hazırladığı rehber, bu sürecin düzenli biçimde yürütülmesi için yararlı bir başvuru kaynağıdır.

PHP’yi güncellemek yeni saldırı yolunu kapatabilir; daha önce bırakılmış zararlı dosyaları veya değiştirilmiş veritabanı kayıtlarını kendiliğinden temizlemez. Bu nedenle ihlal tespitinde dosyalar, veritabanı, zamanlanmış görevler ve sunucu erişimleri birlikte değerlendirilmelidir. Temiz ortam sağlandıktan sonra ilgili hesap parolaları, uygulama parolaları ve WordPress oturum anahtarları da yenilenmelidir.

WP-CLI ile Dosya Bütünlüğünü Kontrol Etmek

WP-CLI erişiminiz varsa çekirdek ve desteklenen eklenti dosyalarını resmî sağlama toplamlarıyla karşılaştırabilirsiniz:

wp core verify-checksums

wp plugin verify-checksums --all

Çekirdek doğrulama komutu, WordPress dosyalarındaki farklılıkları bulmaya yardımcı olur ve WordPress’i yüklemeden çalışır. Eklenti doğrulama komutu ise WordPress.org üzerinde sağlama toplamı bulunan paketleri kontrol eder; özel veya ücretli bütün eklentiler için veri bulunmayabilir.

Bu kontrollerin temiz sonuç vermesi, bütün sitenin ve sunucunun temiz olduğunu kanıtlamaz. Veritabanı, medya dizini ve özel kodlar ayrıca incelenmelidir. Saldırı şüphesinde kontrolleri, dosyalar korunarak ve tercihen güvenilir bir inceleme ortamında yürütmek daha sağlıklı olur.

PHP RCE Açığı Hakkında Sık Sorulan Sorular

WordPress Güncellemesi PHP Açığını Kapatır mı?

Hayır. WordPress dosyalarının güncellenmesiyle sunucudaki PHP paketinin güncellenmesi farklı işlemlerdir. Bu açıklar için sitenin kullandığı PHP kurulumuna ilgili güvenlik düzeltmelerinin uygulanması gerekir.

Sitemde Dosya Yükleme Formu Yoksa Güvende miyim?

Görünür bir dosya yükleme formunun bulunmaması tek başına koruma sağlamaz. Sunucunun gelen istekleri nasıl işlediği önemlidir. Sürüm ve yapılandırma kontrolü yine yapılmalıdır.

HTTPS ve İki Aşamalı Doğrulama Yeterli Olur mu?

HTTPS bağlantının korunmasına, iki aşamalı doğrulama ise hesap güvenliğine yardımcı olur. Ancak ikisi de PHP motorundaki bu hataları düzeltmez. Bu önlemleri sürdürürken PHP güncellemesini ayrıca uygulamalısınız.

Hosting Firması Güncel Olduğunu Söylüyorsa Başka Bir Şey Yapmalı mıyım?

Alan adınızın kullandığı PHP kurulumu için düzeltmenin uygulandığını teyit ettirin. Tam paket sürümü veya güvenlik bülteni, genel bir “güncel” yanıtından daha açıklayıcıdır. Sonrasında sitenizin temel işlevlerini kontrol edin.

PHP Güncellemesi Yapıldıktan Sonra Bütün Sorun Çözülür mü?

İlk iki açık için ilgili düzeltmelerin çalışan PHP kurulumuna uygulanması gerekir. Ek oturum riski ayrıca değerlendirilmelidir. Daha önce saldırı gerçekleşmişse, güncellemenin yanında temizlik ve olay incelemesi de yapılmalıdır.

WordPress Güvenliğinde PHP Güncellemelerini İhmal Etmeyin

PHP’deki bu açıklar, WordPress bakımının tema ve eklenti güncellemelerinden ibaret olmadığını gösteriyor. Sitenizin kullandığı PHP sürümünü bilmek, hosting sağlayıcınızın yama durumunu takip etmek ve değişiklikten sonra temel işlevleri denemek de bu bakımın bir parçası.

Blogunuzu korumak için öncelikle Site Sağlığı bölümünden PHP sürümünü öğrenin. Ardından sağlayıcınızdan ilgili güvenlik düzeltmelerinin uygulandığını teyit edin; yedeklerinizi kontrol ederek gerekli güncellemeyi tamamlayın. Şüpheli bir değişiklik fark ederseniz bunu güncellemeden ayrı ele alıp inceletin. Böylece yalnızca sürüm değiştirmiş değil, yapılan işlemin sitenize doğru şekilde uygulandığını da kontrol etmiş olursunuz.