WordPress Eklenti Güvenlik İncelemesi Sürümü Engellerse Ne Yapılır?

Kısa yanıt: Eklenti sürümü neden dağıtılamıyor?

WordPress.org dizininde barındırılan bir eklentinin yeni sürümü otomatik güvenlik incelemesinde engellendiyse, önce commit edenlere gelen bulgu e-postasını okuyun; dosya ve satır düzeyindeki işaretleri gerçek kodla karşılaştırın, sorunu giderin ve yeni bir sürüm yayımlayın. Engellenen sürüm, WordPress.org güncelleme API'si üzerinden sitelere sunulmaz; daha önce dağıtılmış sürüm ve eklentinin dizin sayfası bu nedenle otomatik olarak kaldırılmaz. WordPress Plugin Handbook bu ayrımı açıkça belgeliyor. Yanlış pozitif olduğunu düşünüyorsanız bildirim e-postasına gerekçeyle yanıt verebilirsiniz; bu, kod incelemesini atlamak için bir yol değildir.

Buradaki konu kendi sitenizde bir eklentiyi staging üzerinde yükseltmekten farklıdır. O sürecin kontrol listesi için özel modül güncellemesinde staging ve geri dönüş rehberine bakın. WordPress.org dağıtımına hazırlanan özel yazılımın kapsamını değerlendirmek için Webinle web yazılım hizmetini inceleyebilirsiniz.

Engel e-postasını bir hata raporu gibi ele alın

Resmî açıklamaya göre WordPress.org üzerinde barındırılan her yeni eklenti sürümü, güncelleme API'sinden dağıtılmadan önce otomatik incelemeden geçiyor. Yüksek risk puanı alan sürüm bloklanıyor ve eklentinin bütün committer hesaplarına bulguları içeren e-posta gidiyor. E-posta, işaretlenen dosya ve satıra bağlantı verebilir. Önce bildirimin hangi sürüme ait olduğunu, hangi değişiklikten sonra geldiğini ve bulgunun üretimde çalışan önceki sürümü mü yoksa yalnızca yeni paketi mi etkilediğini ayırın.

"Yüksek risk" ifadesini kötü niyet suçlaması olarak okumayın. WordPress'in kılavuzu, yanlışlıkla eklenen bir açığın da yüksek puan alabileceğini belirtiyor. Uygulama ekibinin görevi, bildirimi tarafsızca incelemek ve tekrarlanabilir bir güvenlik testi hazırlamaktır. Bulgu alıntısını rapora geçirirken gerekli teknik bağlamı saklayın; kullanıcı verisi veya gizli anahtarı ekip dışı bir araca kopyalamayın. Birden çok bulgu varsa her biri için ayrı karar yazın: doğrulandı, açıklama gerektiriyor veya yanlış pozitif olabilir.

Kod düzeltmesini nasıl sınarsınız?

İşaretlenen satırdan başlayın fakat yalnızca tek satırı değiştirmeyin. Girdi nereden geliyor, kim bu eylemi tetikleyebiliyor, hangi yetki kontrolü var ve çıktı nereye gidiyor sorularını izleyin. Örneğin bir yönetim işlemi erişim kontrolü gerektiriyorsa, doğru rol dışındaki kullanıcı için de test edin. Form girdisi işleniyorsa beklenmedik metin ve boş değerle deneyin. Dosya yolu veya URL gibi alanlarda sınır dışı girdiyi kontrol edin. Bunlar genel güvenli kod inceleme örnekleridir; WordPress'in otomatik tarayıcısının tam kural listesini varsaymaz.

Düzeltmeyi ayrı dalda hazırlayıp eklenti testlerini ve WordPress üzerinde gerçek kullanıcı akışını çalıştırın. Pakete giren dosyaları yeniden listeleyin; kaynak depoda olmayan ama dağıtım paketine eklenen bir bağımlılık sorunun kaynağı olabilir. Yayın notunda güvenlik düzeltmesini doğru anlatın, fakat açığın istismarını kolaylaştıracak gereksiz ayrıntıları kamuya açık açıklamaya koymayın. Bir testin yeşil olması otomatik inceleme eşiğini geçeceğinizi garanti etmez; ekip kendi kod kalitesini ve kullanıcı etkisini bağımsız değerlendirmelidir.

Plugins Team'in 2026 duyurusu inceleme sırasında birden fazla araçtan çıkan bulguların birleştirildiğini ve yanlış pozitif olasılığının sıfır olmadığını söylüyor. Bu nedenle e-postadaki sonucu tek otorite kabul etmek yerine bulguyu kod, veri akışı ve testle karşılaştırın. Eksik kanıt varsa cevap yazarken hangi koşulda bulgunun oluşmadığını somut gösterin. Yalnızca "bizde çalışıyor" demek, güvenlik sorununu çürütmez.

Yeni sürüm ve itiraz yolları

Resmî kılavuz, doğrulanan sorun için düzeltme yapıp yeni bir sürüm yayımlamayı öneriyor. Blok, işaretlenen sürüme uygulanıyor; düzeltme sürümü de normal otomatik incelemeden geçiyor. Bu yüzden yeni sürüm numarası, paket içeriği ve changelog birbirini tutmalı. Yeniden yayın öncesi aynı zafiyet sınıfını başka dosyalarda arayın. Eski sürümün dağıtımda kalması, yeni özelliklerin ulaştığı varsayımıyla müşteri desteği vermemeniz gerektiği anlamına gelir.

Yanlış pozitif olasılığında bildirime yanıt verip gerekçenizi iletin. Hangi satırın neden güvenli olduğunu, test adımını ve erişim sınırını gösteren kısa açıklama hazırlayın. İtiraz sürerken iş planını belirsiz bir onay tarihine bağlamayın; bakım ekibine mevcut dağıtılan sürümün durumunu bildirin. Kullanıcılar için acil bir açık varsa iletişim ve geçici risk azaltma planını ayrıca değerlendirin. Bu yazı, her itirazın kabul edileceği veya incelemenin belirli sürede tamamlanacağı vaadinde bulunmaz.

Yanlış alarm ile gerçek engeli ayırma kontrolü

Sürüm sorumluluğunu önceden belirleyin

Eklentiyi birden fazla kişi yayımlıyorsa committer hesaplarına gelen güvenlik uyarılarının kim tarafından izleneceğini yazılı hale getirin. Ayrılan ekip üyesinin e-posta adresinin tek bildirim noktası olması bir operasyon riskidir. Her sürüm için kodu onaylayan, dağıtım paketini hazırlayan ve engel halinde müşteri iletişimini yöneten sorumluları kaydedin. Böylece tarama bildirimi geldiğinde bulguların sahipsiz kalmasını önlersiniz.

İnceleme sonucunu bir kalite ölçüsü olarak tek başına kullanmayın. Bloklanmayan sürümde de işlevsel hata, erişilebilirlik sorunu veya kendi veri güvenliği açığınız olabilir. WordPress.org taraması belirli güvenlik risklerini arar; kendi ürün kabul testiniz, gerçek form veya ödeme gibi kritik işlevleri ayrıca sınamalıdır. Dağıtım kontrolü ile kullanıcı deneyimi kontrolünü aynı kayıt içinde ama ayrı sonuçlar olarak tutun.

Bir eklenti sahibi kontrol panelinde yeni sürümü görmediğinde önce WordPress.org dizinindeki yayımlı sürümü, güncelleme API'sinin sunduğu sürümü ve kendi depodaki etiketi ayrı kaydetmeli. Bunlar aynı anda değişmeyebilir. Bildirim e-postası yoksa yalnızca otomatik güvenlik bloğu olduğu sonucuna atlamayın; paket, sürüm etiketi, dağıtım sırası veya başka operasyonel sorunları inceleyin. E-posta varsa tam sürüm kimliğini ve bulgu bağlantılarını doğrulayın. Önceki sürümün kullanıcı sitelerinde görünmesi, engellenen yeni sürümün dağıtılmadığı durumla uyumludur.

Dağıtım sonrası kontrolü de planlayın: düzeltilmiş sürüm gerçekten güncelleme kanalında görünüyor mu, temiz test sitesinde yükseltme tamamlanıyor mu, kritik işlevler çalışıyor mu ve gerektiğinde önceki güvenli sürüme nasıl dönülecek? Bu test, WordPress.org incelemesinin yerine geçmez; kullanıcıya ulaşan sürümün operasyonel doğruluğunu kontrol eder. Eklentinin sürüm geçmişi, sorumlu committer ve güvenlik bildirimi adresi belgelenirse bir sonraki uyarı kaybolmaz.

WordPress.org eklentiniz için sürüm engeli aldıysanız önce bulgu, etkilenen kod yolu ve paket sürümünü tek bir inceleme kaydında toplayın. Ardından düzeltme ve test kapsamını belirleyin. Özel WordPress geliştirme veya bakım sürecini birlikte değerlendirmek için Webinle web yazılım sayfasından iletişime geçebilirsiniz.