WordPress Çekirdek Güvenlik Girişimi AI Dalgasına Karşı

🇬🇧 English: Read this in English →

WordPress’te güvenlik meselesi, çoğunlukla ancak bir şey ters gittiğinde Pazartesi sabahına düşen bir konu. Normal bir haftada hackerone.com/wordpress’e düşen raporlara kimin baktığını, biriken kuyruğun büyüyüp büyümediğini ya da düzeltilmiş bir yamanın senin sitene otomatik güncelleme olarak inmesi ne kadar sürüyor diye kimse düşünmüyor. Ben düşünüyorum, çünkü otuz küsur yıldır kullandığım her teknolojide bakım katmanının hep aynı sessiz yoldan büyüdüğünü gördüm: bir olay, bir olay daha, ta ki biri “sıkıcı olan kısmı” fonlamaya karar edene kadar.

Bugün bununla açmamın sebebi şu: yapay zekâ borunun şeklini değiştirdi. Araştırmacılar kodu artık eskisinden çok daha hızlı okuyor. Bu bizim için iyi bir şey aslında — “daha çok göz” WordPress’i dürüst tutan şeyin ta kendisi — ama “daha çok göz”ün karşılığındaki rapor kuyruğunun da aynı hızda büyümesi gerekiyor, ve insan eliyle yapılan triyaj (triage) LLM’lerin destek verdiği tarama kadar ölçeklenmiyor. Triyaj tarafını kimse yeniden tasarlamazsa, biriken kuyruk maçı otomatik olarak alır.

WordPress güvenlik ekibi, geçen Cuma bunu açıkça söyledi. Aşağıda ne taahhüt ettikleri, ben olsam bundan ne okurdum ve bu hafta kendi müşteri sitelerimde neyi değiştirirdim var.

Gerçekten yeni olan ne

Rudy Faile, “The Core Security Initiative” yazısını 28 Ağustos 2026’da Make/Security’de yayımladı ve aynı gün Make/Core tarafına da çapraz gönderi olarak düştü. Yazı, girişimin sebebini dolambaçsız koyuyor: “ileri düzey yapay zekâ modellerinin gelişmesi” projeye gelen zafiyet bildirimlerinde ölçülebilir bir artışa yol açıyor ve ekip triyaj, doğrulama ve çözüm süreçlerini bu yeni hacme göre ölçeklendirmek zorunda.

Girişim, isim verilmiş üç sütun üzerine oturuyor. İlki, daha iyi bir sürüm süreci — “daha sıkı ve daha otomatik bir güvenlik sürüm süreci, iyileştirilmiş uçtan uca test ile” — böylece düzeltme hazır olduğunda ayrı bir olayın kendisi olmadan yayına inebilecek. Temmuzdaki 7.0.2 acil sürümünü ya da Ağustostaki 7.0.4 Imagick RCE yamasını yaşayan varsa, o sütunu benimle aynı biçimde okuyacaktır: darboğaz artık sürüm kanalının kendisi.

İkinci sütun, birikmiş kuyruğu kırmak. Ekip, “ekosistemin geneline dağılmış” uzun süreli çekirdek katkıcılarını ve şirket sponsorluğundaki katkıcıları özellikle bu iş için devreye alıyor; hedef, açık raporları sıfıra çekmek. Bu bir slogan değil, kapsam taahhüdü. Biriken kuyruk, tek başına önemsiz görünen bulguları birleşerek büyüyen bir risk yüzeyine dönüştüren şeydir; çünkü saldırganın hangisinin hâlâ çözülmediğini tahmin etmesine gerek kalmaz.

Üçüncü sütun, yapay zekâyı zafiyetlerin kendisine yöneltmek — yani yapay zekâ destekli taramayı projenin dışında değil içinde çalıştırmak. Çerçeveleme simetrik: hataları bulmanın maliyetini düşüren araçlar bakımcıların da elinde olursa, savunanlar da bu araçları ölçekte çalıştırabilir. Faile, bunun insan araştırmacıları değiştirmediğini, tamamladığını açıkça söylüyor; raporlar hâlâ hackerone.com/wordpress üzerinden ve ekibin yayımladığı yönergelere göre gidiyor.

Girişim tek başına değil. Aynı haftalar içinde WordPress 7.2 için Secrets API teklifi masaya kondu — birinci sınıf bir kimlik bilgisi deposu, yani eklentiler API anahtarlarını artık wp_options tablosuna düz metin olarak yazmasın diye — ve mevcut sürüm takvimiyle koordineli programlanıyor. Bu, koordineli bir hamle ve öyle duyuruluyor.

WordPress ve WooCommerce tarafında ne anlama geliyor

Eklenti ya da tema geliştiriyorsan, pratik okuma şu: senin CVE döngün kısalacak. Triyaj hızlanacak, ki bu elinde gerçek bir hata olan bakımcı için iyi haber; Haziran’dan beri “düşük öncelikli” diye kendine söylediğin bir raporun üstünde oturuyorsan da hafiften rahatsız edici bir haber. Birikmiş kuyruk çalışması o rapora nasıl olsa uğrayacak. Yaman yollayan tarafta olmak daha iyi.

WooCommerce mağazası ya da ajans portföyü işletiyorsan, ilk hissedeceğin sütun sürüm süreci olacak. Daha sıkı bir güvenlik sürüm döngüsü, “advisory yayımlandı” ile “otomatik güncelleme filoya ulaştı” arasındaki aralığın daralması demek. Bunu zaten istersin. Ama aynı zamanda sessiz sedasız otomatik güncellemeyi kapattığın siteler — kendine özel bir deploy hattı olan, tedirgin bir müşterin olan, bir gün upstream’e taşırım dediğin legacy fork’u olan — en uzun süre açıkta kalanlar oluyor. Projenin içinden koşan yapay zekâ destekli tarama, saldırganların bir yamayı istismarla ilişkilendirme hızının tavanını sürekli yükseltecek, çünkü yamanın kendisi zaten kamuya açık kod.

WordPress hosting ya da yönetilen hizmet satıyorsan, girişim sana hediye. Müşterine dürüstçe şunu söyleyebilirsin: projenin bakımcıları artık sürüm kanalını ürünün kendisi gibi ele alıyor, sürümün bir yan etkisi gibi değil. Felsefe olarak zaten öyleydi; şimdi fonlanmış, ismi konmuş bir iş kolu.

Ben olsam ne yapardım (ya da yapmazdım)

Raporunu HackerOne üzerinden ilet. GitHub Issues’a değil, eklenti destek forumuna değil, bir committer’a DM’e değil. Faile’nin yazısı çok açık: “rapor kalitesi bu hacimde her zamankinden önemli,” ve giriş kanalını asıl önemli kılan şey de o hacim. İyi bir rapor — tekrarlanabilir adımlar, etkilenen sürümler, minimal PoC, net bir etki cümlesi — saatler içinde triyaja giriyor. Kötüsü de sonunda giriyor, ama iyi olanların arkasına. Aceleye geldi diye kötü bir raporla iyi niyet krediyini harcama.

Prensipten otomatik güncellemeyi kapatmayı bırak. İnsanların bunu yapmasının her sebebini anlıyorum; hepsini ben de bir noktada yaşadım. Ama girişim, yamadan kamusal istismara kadar geçen pencereyi daraltacak; üç gün geç inen elle kapılı bir deploy, gereksiz bir hata. Operasyonun bir kapıya ihtiyaç duyuyorsa, kapıyı staging ortamının önüne koy — güncellemeyi anında çeksin — production’ın önüne değil, orada güncelleme “biri baksın da” beklerken oturuyor.

Secrets API teklifi hâlâ masadayken kendi secret depolamanı denetle. Henüz çekirdeğe inmedi, ama yön belli. Eğer wp_options içinde API anahtarların varsa, bunu zaten biliyorsun; “gelecekteki ben halleder” oyununu bırak, biletini bugün aç ki gerçek bir kimlik bilgisi deposuna geçiş, politika toplantısı değil kod değişikliği olarak yaşansın.

Yapay zekâ destekli tarama sütununu kod incelemesini gevşetmek için bahane sayma. Yapay zekâ tabanı yükseltir, tavanı yükseltmez. Bir LLM’in yakaladığı hatalar nasıl olsa er ya da geç yakalanacak olanlardır; asıl canını yakan, geçerli kod gibi görünen tasarım hatalarıdır — yanlış kapsamdaki capability kontrolleri, yanlış action’ı doğrulayan nonce’lar, REST endpoint’i ile metabox kaydı arasındaki yarış koşulları. Bunlar için hâlâ o kalıbı daha önce görmüş bir insan lazım.

Uzaktan baktığımda, son on yılın açık kaynak güvenlik çalışmalarının çoğunun aynı dersin daha büyük ölçekte tekrarı olduğunu görüyorum: güvenilirlik hep sıkıcı olan yerde yaşıyor. WordPress, sıkıcı olan kısmı bugün kamuoyu önünde fonladı. Hamle bu.