WordPress 7.0.4 bir kod çalıştırma açığını kapattı: asıl risk kimdeydi

Yamanın kapsamı

Güvenlik ekibi tek bir madde sıraladı: Imagick ve Ghostscript kullanan sitelerde, Yazar veya üstü yetkiye sahip kimliği doğrulanmış bir kullanıcının zararlı dosya yüklemesiyle uzaktan kod çalıştırması. Bildirimi pwn.ai ekibi yapmış.

Sürüm sayfasındaki değişen dosya listesi tek satır:

/wp-includes/class-wp-image-editor-imagick.php

Hiçbir paket de güncellenmemiş. Yani bu, kırk hata düzeltmesi taşıyan bir bakım sürümü değil, tek amaçlı bir güvenlik sürümü. Hemen uygulamanın geri dönüş riski bu yüzden neredeyse yok. Bir e-ticaret sitesi işleten için genellikle belirleyici olan da budur.

Yamanın 4.7'ye kadar geri taşınması

Düzeltme, 4.7.35'e kadar inen yirmi üç eski dalda yayımlandı. Hâlâ WordPress 5.2 üzerinde duran bir siteyi bekleyen yamalı bir sürüm var demek. 4.6 ve öncesi ise artık hiç güvenlik güncellemesi almıyor.

Bu karar tek başına sorunun boyutu hakkında bir şey söylüyor. WordPress sıradan bir hatayı sekiz yıl geriye taşımaz.

Durumunuzu söyleyecek üç komut

Sıra önemli: önce sürüm, sonra Imagick, sonra Ghostscript. Son ikisinden biri yoksa bu açık sizi zaten hiç ilgilendirmiyordu.

Kendi sunucunuzda çalıştırın

wp core version
php -r 'echo extension_loaded("imagick") ? Imagick::getVersion()["versionString"] : "no imagick";'
gs --version

Bizim sunucumuzun yanıtı

Sunucumuz 15 Ağustos 2026'da şöyle yanıt verdi:

7.0.4
ImageMagick 6.9.12-98 Q16 x86_64 18038
10.02.1

Üç koşul da sağlanıyor. Haber bize ulaşmadan önce bizi koruyan tek şey, WordPress'in varsayılanı olan ve kapatmadığımız çekirdek otomatik güncellemesiydi.

Vaktimizi alan tuzak: policy.xml

Her ImageMagick sıkılaştırma rehberi, PostScript ve PDF kodlayıcılarının çalışmaması için policy.xml dosyasını kapatmanızı söyler. Tavsiye yerinde. Sorun başka yerde.

Debian ve Ubuntu üzerindeki standart ImageMagick 6 kurulumunda o satırlar, etkin yapılandırmanın içinde değil, dosyanın açıklama bloğunun içinde duruyor. Satırı arayıp bulduk, bir an rahatladık, sonra bir işe yarayıp yaramadığını sınadık. Yaramıyordu.

İnancı olgudan iki komut ayırıyor. Birincisi gerçekten yürürlükteki politikaları basar, ikincisi Ghostscript'in hâlâ çağrıldığını kanıtlar:

identify -list policy
convert sample.pdf out.png

İlk çıktıda Coder başlıklı hiçbir satır yoksa, dosyada ne yazıyor olursa olsun kodlayıcı kısıtınız yok demektir. İkinci komut izin hatası yerine Ghostscript hatası döndürüyorsa yol açıktır. Bizim sunucumuzda Ghostscript hatası döndü.

O halde panelinizde kaç kişinin Yazar yetkisi olduğunu sayın. WordPress bir Yazara varsayılan olarak pdf, psd, xps ve oxps yüklemesine izin verir; bunlar da tam olarak Ghostscript'e uğrayan biçimlerdir.

Bir güvenlik eklentisi bunu yakalamazdı

Güvenlik eklentisi satan biri için pahalı bir cümle, ama doğru.

Wordfence ve benzerleri istek katmanında çalışır: şüpheli yük, kötü adres, başarısız giriş denemesi. Buradaysa yükleme tümüyle meşruydu, yükleme hakkı gerçekten olan biri yaptı ve işlem bir çekirdek dosyasının içinde gerçekleşti. Hiçbir uygulama güvenlik duvarı kuralı bunu anormal saymaz.

Üç şey işe yaradı ve üçü de ücretsiz: açık bırakılmış çekirdek otomatik güncellemesi, mümkün olan en az Yazar hesabı ve görünüşte değil gerçekten kısıtlanmış bir ImageMagick kurulumu.

Riskin dürüst ölçüsü

Sitenizin tek kullanıcısı sizseniz buradaki pratik riskiniz sıfıra yakındı. Yazar yetkisiyle kimlik doğrulaması gerektiren bir açık, saldırganın önce bir hesaba ihtiyacı olduğu anlamına gelir.

Gerçek risk başka yerde: kaydın açık olduğu siteler, çok yazarlı yayınlar, on kişinin yayımlama yetkisi taşıdığı ve kullanıcı listesine iki yıldır kimsenin bakmadığı kurumsal bloglar. Tarif size uyuyorsa yama işin yarısı, o listeyi gözden geçirmek de diğer yarısı.

Aynı mantığı bir sitenin ele geçirilmeden önce verdiği sinyaller yazısında açtık. Yetkilere ve sunucu yapılandırmasına kendi ekibinizin dışından birinin bakmasını isterseniz, sunucu ve erişim düzeylerinin güvenlik incelemesi tam da bu kontrol listesinden başlıyor.

Haberle ilgisi olmayan ama sizinle ilgisi olan son bir not: yapılandırmasına hiç dokunulmamış paylaşımlı barındırmada duran bir site bu kararları veremez. Bunun bedelini barındırma yapılandırmasının site performansına yansıması yazısında yazdık. Sıfırdan kuruyorsanız, sunucu yapılandırması ilk günden belli olan bir site kurmak bütün bunları yayına aldıktan sonra düzeltmekten ucuza gelir.

Kaynaklar

• WordPress 7.0.4 sürüm duyurusu, tarih, açık tanımı ve bildiren ekip için
• 7.0.4 sürüm sayfası, değişen dosya listesi ve geri taşınan dallar için

Her iki kaynak da, yukarıdaki bütün komutlar da 15 Ağustos 2026'da kendi sunucumuzda çalıştırılıp doğrulandı.