WordPress kendi kendine güncellendi: ne oldu
Tüm kurulumlara dayatılan bir güvenlik güncellemesi her yıl yaşanmaz. Yaşandığında bu bir önlem değildir: kapatılan açığın hesapsız ve parolasız istismar edilebildiği anlamına gelir.
17 Temmuz 2026’da neyin düzeltildiği
Hiçbir talepte bulunmadığınız hâlde « Your site has been updated » başlıklı bir e-posta aldıysanız, ortada bir arıza yok. WordPress 17 Temmuz 2026’da 7.0.2, 6.9.5 ve 6.8.6 sürümlerini yayınladı ve WordPress.org, ilgili sürümlerde zorunlu otomatik güncellemeleri devreye aldı. Resmi tavsiye tek cümle: hemen güncelleyin.
İki açık kapatıldı. CVE-2026-60137, WP_Query sınıfının author__not_in parametresi üzerinden kolaylaşan bir SQL enjeksiyonudur; WordPress 6.8’den beri mevcuttur ve WordPress.org bunu kritik olarak sınıflandırır. CVE-2026-63030, WordPress 6.9 ile gelen toplu REST API’deki bir rota karışıklığıdır; WordPress.org bunu yüksek olarak sınıflandırır, Tenable ise 9,8 CVSS puanı verir. Ayrı ayrı ele alındığında ikisi de ciddi sorunlardır. Zincirlendiklerinde ise 6.9.x ve 7.0.x kurulumlarında kimlik doğrulaması olmadan uzaktan kod çalıştırmaya imkân verirler: hesap yok, parola yok, bir yöneticinin bir şeye tıklamasına gerek yok. Tenable’ın savunmasız olarak listelediği sürümler 6.8.0 ile 6.8.5, 6.9.0 ile 6.9.4 ve 7.0.0 ile 7.0.1 arasıdır.
Patchstack’in 2026 WordPress güvenliği raporu, bir açığın kamuya duyurulması ile kitlesel istismarı arasındaki ortanca süreyi beş saat olarak veriyor ve yüksek etkili açıkların yaklaşık yarısının yirmi dört saat içinde istismar edildiğini tahmin ediyor. 17 Temmuz’daki duyurudan birkaç saat sonra kamuya açık gösteri kodları ortaya çıktı ve izleyen günlerde gerçek koşullarda istismar, aralarında Patchstack’in de bulunduğu birkaç ekip tarafından doğrulandı. Zorunlu güncellemenin gerekçesi tam olarak budur: bu zaman ölçeğinde her sitenin kendi kendine güncellenmesini beklemek savunulabilir değildi.
Dayatılan bir güncellemenin işaretleri
- 17 Temmuz 2026 civarında, sizin hiçbir müdahaleniz olmadan gelen « Your site has been updated » başlıklı bir WordPress e-postası.
- Kimse güncelleme düğmesine basmadığı hâlde yönetim panelinde değişmiş bir sürüm numarası.
- Aynı gün ortaya çıkan beyaz ekran, hata veya bozulmuş sayfa düzeni; genellikle yeni sürümle uyumsuz bir eklenti veya tema.
- Yerinde kalmış bir .maintenance dosyasının işareti olan « Briefly unavailable for scheduled maintenance » mesajında takılı kalmış bir site.
- Tersi durum, asıl endişe verici olan da budur: hiç e-posta yok, sürüm değişikliği yok ve site hâlâ eski bir sürümde çalışıyor.
Düzeltilmiş sürüme geçtiğinizi otuz saniyede doğrulama
Şu anda önemli olan tek bir soru var: sitede gerçekte hangi sürüm çalışıyor. Yönetim panelinde yanıt, panonun sağ alt köşesinde ve Pano → Güncellemeler bölümündedir. Orada 7.0.2, 6.9.5 veya 6.8.6 ya da daha sonra yayınlanmış bir sürüm görmelisiniz. 7.0.1, 6.9.4, 6.8.5 veya daha eski bir sürüm görüyorsanız güncelleme gerçekleşmemiştir ve site savunmasız bir sürümde kalmıştır.
Komut satırında iki komut yeterlidir ve bunların avantajı, sürümü önbelleğe alınmış olabilecek bir yönetim sayfasından değil doğrudan dosyalardan okumalarıdır. İkincisi ayrıca resmi güncelleme sunucusunu sorgular ve kurulmayı bekleyen bir şey kalıp kalmadığını söyler.
wp core version
wp core check-updateSite eski bir sürümde kaldıysa
-
Otomatik güncellemelerin kapatılmadığını doğrulayın
<code>wp-config.php</code> içindeki <code>AUTOMATIC_UPDATER_DISABLED</code> sabiti veya false değerine ayarlanmış <code>WP_AUTO_UPDATE_CORE</code>, dayatılan her güncellemeyi engellemeye yeter. Bazı bakım ve optimizasyon eklentileri aynı ayarı açıkça söylemeden yapar.
-
Güncellemeleri barındırma sağlayıcınızın yönetip yönetmediğini sorun
Yönetilen bir pakette güncellemenin ne zaman uygulanacağına bazen kendi testlerinden sonra sağlayıcı karar verir. Bu durumda sorulacak soru « neden » değil « ne zaman » olur ve kabul edilebilir yanıt saatlerle ölçülür.
-
Çekirdeğin elle değiştirilmediğini doğrulayın
Elle düzenlenmiş çekirdek dosyaları güncellemenin, bazen sessizce, başarısız olmasına yol açar. Ayrıca sürüm numarasını içeren dosyayı biri düzenlediyse ekranda yazan numara hiçbir şey kanıtlamaz: şüphe hâlinde çekirdek dosyalarını aynı sürümün resmi arşiviyle karşılaştırırım.
-
Bakım kipinde kalmış bir siteyi kurtarın
Yarıda kesilen bir güncellemeden sonra kök dizinde kalan <code>.maintenance</code> dosyası tüm siteyi bloke eder. Silmek kolaydır, ancak ardından güncellemenin gerçekten tamamlandığını doğrulamak gerekir; sayfaların yeniden açılması tek başına yeterli değildir.
-
Yalnızca ana kurulumu değil, hepsini sayın
Bir çoklu site ağı, bir test kopyası, iki yıl önce unutulmuş bir alt klasördeki eski kurulum: savunmasız sürümde kalanlar tam olarak bunlardır, çünkü onların e-postalarını kimse okumaz.
-
Yedek alın, sonra elle güncelleyin
Önce dosyaların ve veritabanının tam yedeği, sonra yönetim panelinden veya komut satırından güncelleme. Bozulan bir eklenti sonradan onarılır; açık kalan bir uzaktan kod çalıştırma açığı onarılmaz.
Konuyla ilgili diğer sayfalar
-
Acil güvenlik güncellemesi
Dayatılan bir güncellemeyi canlı bir mağazayı bozmadan uygulamak.
-
Başarısız güncellemeden sonra geri dönme
Zorunlu güncelleme bir eklentiyi veya temayı bozduysa.
-
Sitemin ele geçirilip geçirilmediğini doğrulama
Kesin bir gösterge yayınlanmadığında uygulanacak yöntem.
-
İlk iki saatte ne yapmalı
Basit bir güncellemeden fazlasını bulursanız izlenecek işlem sırası.
İhtiyacınızı bir dakikada anlatın
Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.