Projeler ve ajans desteği için müsait · Hızlı yanıt, işi yapan kişiden

Mesaj gönderin contact@allaux.fr
FR EN TR
allaux.
Acil durum Projemi konuşalım

Modülümün yayıncısı ortadan kayboldu ve açık hiçbir zaman kapatılmayacak

Bazı güvenlik duyuruları “hiçbir düzeltme yayımlanmayacak” cümlesiyle biter. Bu durumda güncelleme bir seçenek değildir ve modülü devre dışı bırakmak her zaman yetmez: geriye kalan işler şunlardır.

Sorunumu anlatayım Mesaj gönderin

Duyuru “hiçbir düzeltme yayımlanmayacak” diye bittiğinde

Mayıs 2026’da, Agence Web 360 tarafından yayımlanan upsshipping adlı bir PrestaShop kargo modülü için güvenlik duyurusu yayımlandı. Referans CVE-2026-39079, CVSS puanı 8,6. 2.4.0 dâhil olmak üzere tüm sürümler etkileniyor. Duyuru açıkça belirtiyor: hiçbir düzeltme yayımlanmayacak, çünkü yayıncı artık faaliyette değil.

Harekete geçmeden önce maruziyetin niteliğini anlamakta yarar var. Modülün günlük klasörüne dışarıdan erişilebiliyordu. İçindeki XML dosyaları UPS API kimlik bilgilerini, erişim lisans numarasını, gönderici hesap numaralarını ve müşterilere ait kişisel verileri (ad, posta adresi, telefon) açığa çıkarıyor. Gerçekten gözlenen bir olayda bu klasörde 2,3 milyondan fazla XML dosyası, yaklaşık 8,7 GB veri vardı ve Şubat 2023 ile Nisan 2026 arasını kapsıyordu.

Yani bu, alışılmış anlamda istismar edilen bir açık değil: okunan bir veri yığını. Bu ayrım devamındaki her şeyi belirler, çünkü “düzeltmek” kelimesinin anlamını değiştirir. Daha önce yazılmış dosyalar yerinde durduğu sürece kodu düzeltmek hiçbir işe yaramazdı.

  • %46 güvenlik açığının, kamuya açıklandığı anda bir düzeltmesi yoktu
  • %35 2024’te açıklanan güvenlik açığı, Nisan 2025’te hâlâ düzeltilmemişti

Patchstack, State of WordPress Security in 2026 (2025 verileri); Wordfence, 2024 yıllık raporu

Bu durumda olduğunuzu gösteren işaretler

  • Modülle ilgili güvenlik duyurusu, düzeltilmiş bir sürümün yayımlanmayacağını açıkça belirtiyor.
  • Yayıncının ürün sayfası, sitesi veya müşteri alanı yanıt vermiyor ve hiçbir destek kanalı çalışmıyor.
  • Modülün son yayımlanan sürümü yıllar öncesine ait; oysa mağaza o tarihten sonra büyük sürüm değiştirdi.
  • Modül, sitenin genel kök dizini altında kendi klasörünün içine günlük, dışa aktarım veya önbellek dosyaları yazıyor.
  • Üçüncü taraf servislere ait kimlik bilgileri, modülün yazdığı dosyalarda açık metin olarak duruyor.

Modülü devre dışı bırakmak neden yetmez

Yönetim panelinde bir modülü devre dışı bırakmak, mağazanın onu çalıştırmasını durdurur. Dosyalarını sunucudan kaldırmaz. Genel kök dizinin altında kalan bir dosya, modülün yönetim panelindeki durumundan bağımsız olarak çoğu zaman web sunucusu üzerinden doğrudan erişilebilir kalır: sunucu, bir yerde bir kutucuğun işaretinin kaldırıldığını bilmez.

Üstelik burada asıl sorun kod bile değil. Sorun, çoktan yazılmış dosyalar. Bu dosyalar API kimlik bilgileri ve müşteri verileri içerir ve orada durdukları sürece okunabilir kalırlar; modül etkin olsun, devre dışı olsun ya da değiştirilmeyi bekliyor olsun fark etmez. İki yıl önce kapatılmış bir modül, iki yıllık geçmişi ifşa etmeye devam ediyor olabilir.

Çok sık karıştırılan iki aşamayı ayırmak gerekir. Maruziyeti durdurmak anlıktır, sizden başka kimseye bağlı değildir ve mağazanın işleyişine dokunmadan yapılır. Modülü değiştirmek ise bir projedir: çözüm seçimi, testler, kabul, bazen kargo firması tarafında yapılandırma değişikliği. İkincisi hiçbir zaman birincisini geciktirmenin gerekçesi olmamalıdır.

Ben hangi sırayla ilerliyorum

  1. İlgili klasöre HTTP erişimini kapatın

    Web sunucusu düzeyinde, site yapılandırmasında veya dizin erişim kurallarında; belirli dosya uzantılarını süzmek yerine klasörün tamamını reddederek. Kesin yapılandırmayı burada yayımlamıyorum: ifşa olan yolu adlandırır ve o yolun dolaşıma girmesine gerek yok.

  2. Engellemenin gerçekten çalıştığını doğrulayın

    Dışarıdan, açık bir yönetim oturumu olmadan ve tarayıcı önbelleği devre dışıyken. Yapılandırmanın yanlış yerine yazılmış bir kural hata üretmez: yalnızca hiç uygulanmaz.

  3. Çoktan yazılmış dosyaları temizleyin

    Neyin, hangi dönem boyunca ifşa olduğunu belirlemek için ihtiyaç duyacağınız kopyayı genel kök dizinin dışında sakladıktan sonra.

  4. Üçüncü taraf kimlik bilgilerini sıfırlayın

    UPS API kimlik bilgileri, erişim lisans numarası, gönderici hesap numaraları. Yalnızca mağaza yapılandırmasında değil, sağlayıcı tarafında: dışarıdan okunabilmiş bir kimlik bilgisi, kaynağında iptal edilene kadar geçerli kalır.

  5. Sahtecilik izi olup olmadığını kontrol edin

    Kargo hesabında: dosyaların kapsadığı tüm dönem boyunca tanımadığınız gönderiler, etiketler ve faturalandırmalar.

  6. Modülü devre dışı bırakmakla kalmayın, silin

    Duyurunun açık tavsiyesi budur. Dosyalar sunucuda durduğu sürece sorun çözülmüş değil, askıya alınmıştır.

  7. Kişisel verilere ilişkin yükümlülükleri değerlendirin

    Müşteri verileri okunabilir durumdaydı. Dosyanın bu kısmının kendi kuralları ve kendi süreleri vardır; teknik çalışmadan bağımsızdır.

Yerine koyacağınız modülü seçerken önemli olan tek ölçüt

Maruziyet durdurulduktan sonra asıl soru kalır: gerçekten ihtiyaç duyduğunuz bir modülün yerine ne koyacaksınız. Özellikler bir saatte karşılaştırılır ve herkesin yaptığı da budur. Sonucu belirleyen ise başka bir şeydir: kim düzeltme yayımlıyor ve hangi sıklıkla.

Uygulamada, satın almadan önce şunlara bakarım: son sürümün tarihi, son on iki ayda çıkan sürüm sayısı, yayıncının güvenlik düzeltmelerini duyurduğu bir kanalın olup olmadığı ve her şeyden önce kendi kodu hakkındaki duyurulara nasıl tepki verdiği; düzeltilmiş bir sürüm yayımlamış mı, ne kadar sürede ve bunu açıkça söylemiş mi. Bir duyuruyu düzgün ele almış bir yayıncı, bir sonrakini de düzgün ele alır.

Fiyat tek başına hiçbir şeyi garanti etmez, eskilik de etmez. İstediğinizin %80’ini yapan ama yayıncısı düzeltme yayımlayan bir modül, kâğıt üzerinde kusursuz görünen ve üç yıldır kımıldamayan bir modülden iyidir. Bu, kaldırmakta olduğunuz modül için de aynı akıl yürütmedir: onu düzeltecek birine ihtiyaç duyulan güne kadar gayet iyi çalışıyordu.

Konuyla ilgili diğer sayfalar

İhtiyacınızı bir dakikada anlatın

Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.

constat
plateforme
depuis-quand (facultatif)
sauvegarde
Size dönebilmem için en az bir e-posta veya telefon numarası belirtin.

Size dönebilmem için en az bir e-posta veya telefon numarası belirtin.

Sıkça sorulan sorular

Modül gayet iyi çalışıyor, gerçekten silmem gerekir mi?
Evet. Çalışan ama artık kimsenin düzeltmediği bir modül güvenli bir modül değildir; bir sonraki açığı kapatılmayacak bir modüldür. İfşa olan klasöre erişimi engellemek size zaman kazandırır, kalma hakkı vermez.
Klasörü sunucu düzeyinde engellemek yeterli mi?
Bu acil önlemdir, çözüm değildir. Okumayı kapatır ama ne çoktan yazılmış dosyaları ne kodu kaldırır; ileride bir taşıma veya barındırma değişikliğinin kuralı kimse fark etmeden devre dışı bırakma riskini de ortadan kaldırmaz.
Bu dosyaları birinin gerçekten aldığını nasıl anlarım?
Çoğu zaman bunu kanıtlayamazsınız, özellikle sunucunun erişim günlükleri yeterince geriye gitmiyorsa. Erişim kanıtının olmaması, erişim olmadığının kanıtı değildir: değerlendirme, neyin ne kadar süre ifşa olduğu üzerinden yapılır.
Modülü kendim düzeltebilir miyim?
Kod şifreli veya lisansla kilitli değilse teknik olarak çoğu zaman evet. Ama o andan itibaren bakımcı sizsiniz: bir sonraki uyumsuzluk ve bir sonraki açık size kalır. Bunu bazen geçiş önlemi olarak yaparım, asla kalıcı çözüm olarak değil.
Müşterilerimi bilgilendirmek zorunda mıyım?
Risk düzeyine bağlıdır ve değerlendirmenin amacı tam olarak budur. Her hâlükârda zorunlu olan, bildirim gerektirmediği sonucuna varsanız bile ihlali iç kayıt defterinize işlemektir.
Bu tür bir modülü değiştirmek ne kadar sürer?
Değiştirme, ayarlara ve yeniden yapılacak testlere göre günler veya haftalar sürer. Maruziyeti durdurmak ise saatlerle ölçülür ve önce yapılması gereken odur.

İlgili sayfalar