# Yeni bir açık yayınlandı: ne kadar vaktim var

> Bu soru retorik değil ve ölçülen yanıt, çoğu satıcının tahmin ettiğinden daha kısa. İşte bir açığın yayınlanması ile ilk toplu saldırılar arasında gerçekte gözlemlenen süreler.

- Source canonique : [https://allaux.fr/tr/securite/combien-de-temps-pour-appliquer-un-correctif](https://allaux.fr/tr/securite/combien-de-temps-pour-appliquer-un-correctif)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Bültende yalnızca iki noktaya bakın: açık, kimlik doğrulaması olmadan sömürülebiliyor mu ve sürümünüz etkilenen aralıkta mı. İkisinin de yanıtı evetse, dosya ve veritabanı yedeğini aldıktan sonra düzeltmeyi bir sonraki bakım penceresini beklemeden uygulayın. Sömürü için hesap gerekiyorsa güncelleme olağan döngünüze girebilir.

## Tek bir süre yoktur, birden fazla süre vardır

Soru bana neredeyse her zaman aynı biçimde geliyor: kullandığım bir eklentide yeni bir açık yayınlandı, pazartesiye kadar bekleyebilir mi. Soru yerinde. Sipariş alan bir mağazada cuma akşamı güncelleme yapmak, haftanın en kötü anında bir şeyleri bozma riskini kabul etmek demektir; üstelik pazartesi sabahına kadar onaracak kimse yoktur. Sorun şu ki takvimi siz belirlemiyorsunuz.

Kararı zorlaştıran şey yalnızca sürenin kısa olması değil. Önceden bilinememesi. Aynı hafta yayınlanan ve aynı önem puanını taşıyan iki açıktan biri saatler içinde otomatik saldırılara konu olabilir, diğerinde ise yaklaşık bir ay boyunca hiçbir istismar gözlemlenmeyebilir. Hangisinin hangisi olduğunu ancak sonradan öğrenirsiniz ve yanlış tarafa bahis oynadıysanız bunu müşterilerinizden duyarsınız.

| Valeur | Description |
|---|---|
| 5 saat | bir açığın kamuya açıklanması ile ilk toplu saldırılar arasındaki medyan süre |
| 2’de 1 | yüksek etkili güvenlik açıklarının yaklaşık yarısı, açıklanmasından sonraki 24 saat içinde istismar ediliyor |
| %46 | güvenlik açığının, kamuya açıklandığı anda hiçbir yaması mevcut değildi |

Source : Patchstack, State of WordPress Security in 2026 (2025 yılı verileri)

## Dört gerçek kronoloji, dört farklı yanıt

Birkaç saat. 17 Temmuz 2026’da WordPress, zincirlendiğinde kimlik doğrulaması olmadan uzaktan kod çalıştırmaya izin veren iki açığı gidermek için 7.0.2, 6.9.5 ve 6.8.6 sürümlerini acil olarak yayınladı. Açıklamadan birkaç saat sonra kamuya açık gösterim kodları ortaya çıktı ve izleyen günlerde gerçek koşullardaki istismar birçok ekip tarafından doğrulandı. Burada hafta sonunu beklemek bir seçenek değildi; WordPress.org ilgili sürümlerde otomatik güncellemeleri zorunlu kıldı.

Birkaç gün. Burst Statistics eklentisindeki kimlik doğrulama atlatma açığı, CVE-2026-8181, puan 9,8, 8 Mayıs 2026’da keşfedildi ve dört gün sonra, 12 Mayıs 2026’da 3.4.2 sürümüyle giderildi. Yirmi dört saat içinde 7.400’den fazla saldırı engellendi. Yama vardı; yine de uygulanması gerekiyordu.

Neredeyse bir ay. Everest Forms Pro eklentisi, CVE-2026-3300, yine 9,8 puanla, yamasını 18 Mart 2026’da aldı. Aktif istismar ancak 13 Nisan 2026’dan itibaren gözlemlendi. Üç hafta gecikmeyle güncelleyen bir satıcı bu işten sıyrılırdı. Karar anında bunu kimse garanti etmiyordu.

Birkaç hafta, sonra bir zirve. Gravity SMTP, CVE-2026-4020, 17 Mart 2026’da 2.1.5 sürümüyle düzeltildi. Toplu istismar ancak Mayıs 2026 başında başladı ve 6 ile 7 Haziran 2026’da zirve yaptı. Yama ile zirve arasında neredeyse üç ay: marttan beri güncellenmemiş bir mağaza haziranda hâlâ geçerli bir hedefti.

Bu dört açıktan ikisi tam olarak aynı önem puanını taşıyor ve kronolojileri hiç benzeşmiyor. Bir puanın tek başına kararı veremeyeceğinin nedeni tam olarak budur.

## Paradoks: saldırıyı tetikleyen şey yamanın kendisidir

Satıcıların en zor kabul ettiği nokta budur ve nedenini anlıyorum: sezgisel olarak yayınlanan bir yama iyi haber olmalıdır. Onu kuran siteler için öyledir. Diğerleri için tam tersini yapar.

Yeni bir sürüm kamuya açık bir olaydır. Düzeltilmiş kod önceki kodla karşılaştırılabilir, fark görünürdür ve bu fark kusurun nerede olduğunu ve neyin süzülmesi gerektiğini gösterir. O andan itibaren açık bir varsayım olmaktan çıkar; henüz kımıldamamış tüm kurulumlara toplu olarak uygulanabilen, doğrulanabilir bir bilgi hâline gelir. En tehlikeli pencerenin yamadan önce değil, hemen sonrasında olmasının nedeni budur.

Doğrudan sonucu şudur: yönetim panelinizde « güncelleme mevcut » yazdığı gün, rahat bir sürenin başında değil, çoktan yarışın içindesiniz. Tersi durum da önemlidir: güvenlik açıklarının %46’sının kamuya açıklandığı anda hiçbir yaması yoktur. Orada güncelleme bir seçenek bile değildir ve tek hareket alanınız geçici bir azaltma önlemidir.

## Bir açığı « bir sonraki bakımda »dan « bu akşam »a taşıyan ölçütler

1. **Kimlik doğrulaması olmadan istismar edilebiliyor** — Açık ara en ağır ölçüt. Bir hesap gerektiği sürece, müşteri hesabı bile olsa, saldırının hazırlanması gerekir. Hiçbir hesap gerekmiyorsa saldırı ek maliyet olmadan tüm web üzerinde otomatikleştirilir ve mağazanız sizi hedefleyen biri tarafından değil, genel bir tarama tarafından vurulur.
2. **Eklenti çok yaygın kurulu** — Kurulu taban ne kadar genişse, otomasyon saldırgan için o kadar kârlı olur. On binlerce sitede çalışan bir eklenti bir araç yazmayı haklı çıkarır; üç yüz mağazadaki bir modül çok daha az. Bu bir garanti değil, bir olasılıktır.
3. **Yama zaten kamuya açık** — Düzeltilmiş sürüm yayınlandıysa kod farkı okunabilir ve geri sayım sizin haberi okuduğunuz anda değil, yamanın yayınlandığı anda başlamıştır. Yaması olmadan duyurulan bir açık, paradoksal biçimde güncelleme açısından daha az aceledir; çünkü kurulacak bir şey yoktur. Azaltılması aceledir.
4. **Hiçbir azaltma önlemi mümkün değil** — İlgili özelliği devre dışı bırakabiliyor, kullanılmıyorsa modülü kaldırabiliyor, hedeflenen giriş noktasına erişimi kısıtlayabiliyor veya uygulama güvenlik duvarında bir yolu engelleyebiliyorsanız zaman kazanır ve hafta içi sakin sakin güncelleyebilirsiniz. Bunların hiçbiri bir satış işlevini bozmadan mümkün değilse geriye yalnızca güncelleme kalır ve o da bu akşamdır.

## Envanter olmadan bu ölçütler işe yaramaz

> Yukarıdakilerin tamamı, birçok mağazanın sahip olmadığı iki şeyi varsayar. Birincisi, sitede gerçekte neyin çalıştığına dair güncel ve eksiksiz bir liste: eklentiler, temalar, kurulu sürümler ve bir kez test için eklenip hiç kaldırılmamış her şey dâhil. Bu liste olmadan, az önce okuduğunuz güvenlik duyurusunun sizi ilgilendirip ilgilendirmediğini bile bilemezsiniz. İkincisi, mağazayı bozmadan güncelleme yapabilmenin yolu: geri yüklenebilir ve denenmiş bir yedek, bir test ortamı ve herkesin bildiği bir müdahale penceresi. Bunlar olmadan bir güncellemenin hafta sonuna bırakılmasının gerçek nedeni ihtiyat değil, onaramayacağınız bir şeyi bozma korkusudur. O korku ise giderilebilir.

## Konuyla ilgili diğer sayfalar

- **Mağazanızı ilgilendiren açıkları takip etme** — Duyuruyu üç hafta sonra değil, yayınlandığı gün öğrenmenin yolu. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Acil güvenlik güncellemesi** — Bu sayfadaki sorunun yanıtı « bu akşam » olduğunda somut olarak ne yapıyorum. ([/wordpress-woocommerce/mise-a-jour/urgence-securite](/wordpress-woocommerce/mise-a-jour/urgence-securite))
- **Müdahaleden önce mağazayı yedekleme** — Riskli bir güncellemeyi geri alınabilir bir işleme dönüştüren ön koşul. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Terk edilmiş modüller ve eklentiler** — Kendinize hangi süreyi tanırsanız tanıyın, hiçbir yamanın gelmeyeceği durum. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))

## FAQ

### Önem puanı yüksek bir açık her zaman önce mi istismar edilir?

Hayır. Puan olası etkiyi ölçer, saldırganın otomatikleştirmeye duyduğu ilgiyi değil. Bu sayfada anılan iki açık aynı 9,8 puanını taşıyor: biri yamasından yaklaşık bir ay sonra aktif olarak istismar edildi, diğerinde yirmi dört saatte 7.400’den fazla saldırı engellendi. Kurulu site sayısı ve kimlik doğrulaması gerekmemesi çoğu zaman puandan daha ağır basar.

### Somut olarak hafta sonunu bekleyebilir miyim?

Açık kimlik doğrulaması olmadan istismar edilebiliyorsa, yaygın kurulu bir eklentideyse, yaması zaten kamuya açıksa ve hiçbir azaltma önlemi mümkün değilse: hayır. Bu dört noktadan biri ortadan kalkarsa payınız vardır, ancak bunu haftalarla değil günlerle ölçmenizi öneririm. Toplu istismara kadar geçen medyan süre beş saattir.

### Henüz bir yama yoksa ne yapmalıyım?

Bu, açıklama anında güvenlik açıklarının neredeyse yarısı için geçerlidir. O hâlde maruziyeti azaltmak gerekir: bileşen zorunlu değilse devre dışı bırakın veya kaldırın, ilgili özelliğe erişimi kısıtlayın, hedeflenen giriş noktasını uygulama güvenlik duvarında engelleyin ve günlükleri izleyin. Bu önlemler geçicidir ve yama uygulandıktan sonra kaldırılmalıdır.

### Otomatik güncellemeler bu sorunu çözer mi?

Yalnızca kısmen. Resmî güncelleme kanalından geçen her şeyi kapsarlar ve acil durumlarda yayıncı tarafından zorunlu kılınabilirler; 17 Temmuz 2026’da yayınlanan WordPress sürümlerinde olduğu gibi. Elle kurulan bileşenleri veya sürümlerini yayıncının kendisi dağıttığı bileşenleri kapsamazlar. Elle takip edilmesi gerekenler işte bunlardır.

### Güncellemeden önce etkilenip etkilenmediğimi nasıl anlarım?

Güncelleme hiçbir şeyi temizlemez: istismar daha önce gerçekleştiyse elde edilen erişim yerinde kalır. Kritik bir açıkta geç kalınmış bir güncellemeden sonra yönetici hesaplarını, yakın zamanda değiştirilmiş dosyaları, olağan dışı zamanlanmış görevleri ve ilgili döneme ait erişim günlüklerini incelerim.