Wordfence kayıtlarında sık gördüğünüz cümle şudur: “… is vulnerable to unauthorized modification of data due to a missing capability check on the X function.” Türkçesi: X işlevinde yetenek kontrolü eksik olduğu için veriler yetkisiz biçimde değiştirilebiliyor. Elimizdeki bir yıllık WordPress verisinde (20 Ekim 2026’ya kadar) 1.084 kayıt bu zayıflığı, yani CWE-862’yi taşıyor. XSS’ten sonra en kalabalık ikinci grup. Yakın akrabaları olan hatalı yetkilendirme ve erişim denetimi numaralarıyla birlikte saydığımızda grup 1.300’ü aşıyor.
CWE-862 tek cümlede
MITRE’nin tanımı kısa: ürün, bir aktör bir kaynağa erişmeye ya da bir işlem yapmaya çalıştığında yetkilendirme kontrolü yapmıyor. “Aktör” burada sitenize istek gönderen herkes. WordPress diliyle söylersek, eklenti bir işi yapmadan önce “bu kişinin bu işi yapma yeteneği (capability) var mı?” diye sormuyor.
Bu, kimlik doğrulamadan farklı bir sorudur. Kimlik doğrulama “bu kişi kim?” diye sorar; yetkilendirme “bu kişi bunu yapabilir mi?”. WordPress REST API el kitabı bu ayrımı açıkça yapar: mümkün olan her yerde kullanıcının giriş yapıp yapmadığını değil, işlemi yapıp yapamayacağını current_user_can ile kontrol edin.
Açık nerede doğuyor
Eklentiler tarayıcıdan gelen istekleri birkaç yoldan karşılar. CWE-862 kayıtlarının açıklamalarında en sık iki yol geçiyor:
AJAX işlevleri. Bir eklenti wp_ajax_ ile başlayan bir kanca kaydettiğinde, giriş yapmış her kullanıcı, rolü ne olursa olsun, o işlevi çağırabilir. wp_ajax_nopriv_ önekiyle kaydedilen işlevleri ise giriş yapmamış ziyaretçiler de çağırabilir. İşlevin içinde rol kontrolü yoksa, abone de yönetici kadar yetkili olur. Çektiğimiz verideki CWE-862 kayıtlarının yaklaşık %30’unun açıklamasında AJAX geçiyor.
REST uç noktaları. REST rotası kaydederken geliştirici bir permission_callback vermek zorundadır; WordPress 5.5’ten beri bu alan yoksa geliştiriciye uyarı gösterilir. El kitabı, herkese açık olması istenen rotalar için __return_true kullanılmasını söyler. Sorun, yalnız yöneticinin kullanması gereken bir rotaya da bu değerin yazılmasıyla başlar. CWE-862 kayıtlarının beşte birinden fazlası REST’ten söz ediyor.
Açıklamaların yaklaşık yarısında “capability check” ifadesi geçiyor; yani kayıt doğrudan eksik olan şeyin adını koyuyor.
Nonce neden kurtarmıyor
Kayıtlarda ikinci sık ifade “nonce”. Pek çok eklenti, işlevini korumak için yalnız nonce denetler. WordPress belgesi nonce’u şöyle anlatır: nonce, belirli bir kullanıcı ve belirli bir işlem için üretilen, harf ve rakamlardan oluşan bir özettir; adının aksine tek kullanımlık değildir, varsayılan ömrü bir gündür ve bu süre içinde aynı kullanıcı için aynı değeri üretir. CSRF gibi saldırılara karşı korur.
Ama belge bir uyarıyı iki kez tekrarlar: nonce’lara kimlik doğrulama, yetkilendirme ya da erişim denetimi için asla güvenilmemelidir; işlevleri current_user_can ile koruyun ve nonce’un ele geçirilebileceğini varsayın.
Bunun pratikte ne anlama geldiğini kayıtlar gösteriyor. Bir eklenti, nonce’u sitenin herkese açık sayfalarına basıyorsa (örneğin bir ön yüz formu için), sayfayı açan her ziyaretçi o nonce’u görebilir. İşlev yalnız nonce’a bakıyorsa, nonce’u sayfadan okuyan biri işlevi çağırabilir. CWE-862 kayıtlarının yaklaşık dörtte birinde nonce’tan söz edilmesi bu yüzden.
Etkisi ne kadar
Bu grubun ortanca puanı 5,3; sitedeki tüm kayıtların ortancası olan 6,4’ün altında. Kayıtların büyük çoğunluğu orta sınıfta. Nedeni şu: korumasız kalan işlev çoğu zaman sınırlı bir iş yapar, bir bildirimi kapatmak, bir ayarı sıfırlamak, bir kaydı dışa aktarmak gibi.
Ama grubun içinde 50’yi aşkın kritik kayıt da var. Korumasız işlev WordPress seçeneklerini (option) güncelleyebiliyorsa, saldırgan örneğin varsayılan kullanıcı rolünü yönetici yapıp kendine hesap açabilir. Dosya yazabiliyorsa sunucuda kod çalıştırabilir. Bu yüzden CWE-862 kaydını okurken asıl soru “korumasız işlev ne yapıyor?” sorusudur. Kayıt metni bunu genellikle söyler: “update arbitrary options”, “delete arbitrary files”, “change the plugin’s settings”.
Gereken rol, sizin için asıl bilgi
Grubun rol dağılımı şöyle: kayıtların yaklaşık %47’si hesap gerektirmiyor, %39’u abone düzeyinde bir hesap istiyor. Katkıcı ve üstü rolleri isteyen kayıtlar azınlıkta. Bu tablo, AJAX ve REST anlatımıyla örtüşüyor: giriş yapmış her kullanıcıya açık işlevler “abone” etiketini, nopriv ve __return_true işlevleri “giriş gerekmiyor” etiketini doğuruyor.
Sitenizde herkese açık üyelik varsa, abone düzeyindeki kayıtları hesapsız kayıtlar gibi okuyun. Bir saldırganın abone hesabı açması bir form doldurmak kadar kolaydır. WooCommerce mağazalarında müşteri hesabı, öğrenme sistemlerinde öğrenci hesabı aynı işi görür. Rollerin ayrıntısını kullanıcı rolleri yazımızda anlattık.
Hangi eklentilerde birikiyor
CWE-862 kayıtları 770’in üzerinde farklı ürüne dağılıyor, ama bazı eklenti türlerinde belirgin biçimde yoğunlaşıyor. Bu türde en çok kaydı olan eklentiler arasında bir etkinlik yönetimi eklentisi (12 kayıt), iki öğrenme yönetim sistemi, LearnPress ve Tutor LMS (11’er kayıt), bir randevu eklentisi, bir kullanıcı profili eklentisi, bir çerez onayı eklentisi ve bir destek bileti sistemi var.
Ortak noktaları açık: hepsi ziyaretçilerin ya da düşük yetkili üyelerin etkileşime girdiği çok sayıda işlev sunuyor. Öğrenci derse kaydolur, ödev gönderir, sınav çözer; müşteri randevu alır, bilet açar. Her işlem ayrı bir AJAX ya da REST çağrısıdır ve her biri “bu kişi bu kaydı değiştirebilir mi?” kontrolünü ayrı ayrı ister. İşlev sayısı arttıkça birinin unutulma ihtimali de artıyor.
Bu kayıtların yalnız beşte birinde düzeltilmiş sürüm numarası açıkça yazıyor; geri kalanında etkilenen son sürüm belirtilmiş. Bu eklentilerden birini kullanıyorsanız, ürün sayfasındaki “güncel sürüm etkilenmiyor görünüyor” satırı, kurulu sürümünüzü karşılaştırmanın en hızlı yolu.
Site sahibi ne yapabilir
- Güncelleyin. Düzeltme, eksik kontrolün işleve eklenmesidir; düzeltilmiş sürüm çıktığında güncellemeyi bir sonraki bakım gününe bırakmayın. Eklentiler listesindeki durum sütunu, güncel sürümün bilinen kayıtlardan etkilenip etkilenmediğini gösterir.
- Üyeliğe ihtiyacınız yoksa kapatın. Abone düzeyi kayıtların neredeyse tamamını sizin için geçersiz kılar.
- Kayıt sonrası ayarları kontrol edin. Seçenek güncelleyebilen bir kayıt çıktıysa, güncellemeden sonra Ayarlar › Genel sayfasındaki varsayılan rolün hâlâ “Abone” olduğuna ve Kullanıcılar sayfasında tanımadığınız bir yönetici olmadığına bakın.
- Kullanmadığınız eklentiyi silin. Devre dışı bir eklentinin AJAX ve REST kancaları çalışmaz; ama dosyaları sunucuda durduğu sürece eklentiyi bir gün yeniden etkinleştirdiğinizde eski açıklar da geri gelir.
Geliştirici gözüyle tek kural
WordPress belgelerinin bu konudaki özü tek cümleye sığar: nonce isteğin nereden geldiğini, current_user_can isteği yapanın kim olduğunu doğrular ve ikisi birbirinin yerine geçmez. REST rotalarında permission_callback, AJAX işlevlerinde işlevin ilk satırı bu kontrolün yeridir.
Bu türün ay ay dağılımı, en çok kayıt çıkan ürünler ve en yeni kayıtlar eksik yetki kontrolü sayfasında. Aynı aileden olup bir adım daha ileri giden açıklar için yetki yükseltme sayfasına bakabilirsiniz.