# 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.

- Source canonique : [https://allaux.fr/tr/securite/editeur-du-module-a-disparu-faille-non-corrigee](https://allaux.fr/tr/securite/editeur-du-module-a-disparu-faille-non-corrigee)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Modülün klasörüne HTTP erişimini web sunucusu düzeyinde engelleyin; dosya uzantılarını süzmek yerine dizinin tamamını reddedin. Engellemeyi dışarıdan, açık yönetim oturumu ve tarayıcı önbelleği olmadan doğrulayın. Modülü arka ofiste devre dışı bırakmak dosyalarını sunucudan kaldırmaz: kural devreye girene kadar daha önce yazılmış günlükler ve dışa aktarımlar erişilebilir kalır.

## 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ı.

| Valeur | Description |
|---|---|
| %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 |

Source : 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.

## Okunabilir müşteri verisi bir veri ihlalidir

> Duyuru, GDPR yükümlülüklerinin değerlendirilmesini açıkça istiyor. Veri ihlali, kişisel verilerin kazara veya hukuka aykırı biçimde yok edilmesine, kaybına, değiştirilmesine ya da yetkisiz şekilde ifşa edilmesine yol açan bir güvenlik olayıdır: kamuya açık bir ifşa, kötü niyetli birinin uğradığına dair kanıt olmasa bile buna dâhildir. Her ihlal, bildirilmeyenler de dâhil olmak üzere bir iç kayıt defterine işlenmelidir. İhlal, kişilerin hak ve özgürlükleri için risk oluşturuyorsa, öğrenildikten sonraki 72 saat içinde denetim otoritesine bildirilir. Risk yüksekse ilgili kişiler de korunma tavsiyeleriyle birlikte bilgilendirilmelidir. Bunlar GDPR’ın 33. ve 34. maddeleridir.

## 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

- **Terk edilmiş modüller ve eklentiler** — Neden gerçek birinci saldırı vektörü olduğu ve mağazanızda uyuyanları nasıl tespit edeceğiniz. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Mağazanızı ilgilendiren açıkları takip etme** — Düzeltmesiz biten duyurular da dâhil olmak üzere, duyuruları nerede izleyeceğiniz. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **PrestaShop modülleri** — Çözüm değiştirmeniz gerektiğinde kurulum, değiştirme ve uyumluluk. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### 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.