# E-posta gönderim sağlayıcım erişim anahtarımı devre dışı bıraktı

> Sipariş e-postalarınızı gönderen servis, anahtarınızı haber vermeden kapatıyor veya başka bir yerden gelen bir kullanım bildiriyor: bu çoğu zaman, kimlik bilgilerinizi nereye bakacağını bilen herkese açık hâle getiren bir eklentinin sonucudur.

- Source canonique : [https://allaux.fr/tr/securite/cle-api-envoi-emails-desactivee](https://allaux.fr/tr/securite/cle-api-envoi-emails-desactivee)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Anahtara dokunmadan önce sızıntıyı kapatın: sorumlu e-posta gönderim eklentisini güncelleyin veya devre dışı bırakın, aksi hâlde yeni anahtar da aynı yoldan dışarı çıkar. Sonra sağlayıcıda yeni anahtarı oluşturun, eklentinin yapılandırmasına yazın — WooCommerce’de wp_options, PrestaShop’ta ps_configuration — ve gönderimler yeniden başladıktan sonra eskisini iptal edin.

## Uyarı her zaman dışarıdan gelir

Senaryo neredeyse hiç değişmez. Mağazanızda hiçbir şey fark etmemişsinizdir, her şey çalışıyor görünmektedir ve sizi üçüncü bir taraf uyarır: gönderim sağlayıcınız hesabın erişim anahtarını askıya alır, olağan dışı bir gönderim hacmi bildirir ya da faturanızda hiç tetiklemediğiniz binlerce mesaj görürsünüz. Bazen ilk işaret daha da sessizdir: yapılandırmaya kimse dokunmadığı hâlde sipariş onayları artık gitmez.

Bir sağlayıcı bir anahtarı rastgele kapatmaz. Size ait olmayan bir altyapıdan gönderim yapıldığını ya da olağan trafiğinize hiç benzemeyen içerikler gördüğünü söyler. Anahtar teknik olarak hâlâ çalışmaktadır: yalnızca başka biri tarafından kullanılmaktadır. Başka biri kullanıyorsa da, o anahtar bir yerde okunmuştur.

Karşılaştığım vakalarda okunduğu yer neredeyse hiçbir zaman sizin bilgisayarınız değildir. Sitenin kendisidir: bu kimlik bilgilerini tutan ve nereye bakacağını bilen herkese okunabilir hâle getiren bir eklenti.

## Sizi uyarması gerekenler

- Gönderim sağlayıcınız, siz hiçbir şey talep etmeden erişim anahtarını devre dışı bırakır.
- Olağan dışı gönderim hacmi uyarısı veya faaliyetinizle ilgisi olmayan bir fatura alırsınız.
- Yapılandırmanızda hiçbir şey değişmediği hâlde sipariş onay e-postaları artık gitmez.
- Sağlayıcının panosunda, müşteriniz olmayan alıcılara yapılan gönderimler görünür.
- Alan adınız istenmeyen posta kaynağı olarak işaretlenmeye başlar.
- Sitede kurulu bir e-posta gönderim eklentisi aylardır güncellenmemiştir.

## Bir gönderim eklentisi neyi saklar, sistem raporu gerçekte neleri içerir

İşlemsel e-postaların gönderimini üstlenen bir eklentinin dışarıdaki bir servise bağlanması gerekir ve bunun için bir sırra ihtiyacı vardır: bir API anahtarı, bir yetkilendirme jetonu, bazen bir kullanıcı adı ve parola. Bu sır, sitenin veritabanında bir yapılandırma tablosuna, eklentinin her gönderimde yeniden okuyabileceği bir biçimde yazılır. Dolayısıyla gerçek anlamda korunamaz: eklentinin okuyabildiğini, aynı yeri sorgulayabilen herhangi bir kod da okuyabilir.

Buna bir de bu eklentilerin neredeyse tamamında bulunan bir özellik eklenir: sistem raporu. Destek talebi açtığınızda eklemeniz istenen dosya budur. WordPress ve PHP sürümlerini, sunucu bilgilerini, veritabanı bilgilerini, kurulu eklentilerin envanterini, aktif temayı ve e-posta bağlayıcılarının yapılandırmasını, yani anahtarları ve jetonları tek bir yerde toplar. Bu masum bir teşhis dosyası değildir: sırlarıyla birlikte kurulumunuzun eksiksiz tarifidir. Ona bir ekran görüntüsü gibi değil, bir parola gibi davranın.

CVE-2026-4020 tam olarak bu noktayı gösterir. Yaklaşık 100.000 sitede bulunan Gravity SMTP eklentisini, 2.1.4 dâhil olmak üzere tüm sürümlerinde etkiler. Eklentinin REST API uç noktalarından birinde bir izin denetimi vardı, ancak bu denetim her zaman doğru döndürüyordu: kapı kilitliydi ve kilit herkese evet diyordu. Uç nokta bu durumda yaklaşık 365 KB JSON veri döndürüyordu; yani eksiksiz sistem raporunu: bağlı e-posta servislerinin API anahtarları ve OAuth jetonları (Amazon SES, Google, Mailjet, Resend, Zoho), veritabanı bilgileri, WordPress ve PHP sürümleri, sunucu bilgileri, eklenti envanteri ve aktif tema. Düzeltme olan 2.1.5 sürümü 17 Mart 2026'da yayınlandı; açık ise 31 Mart 2026'da duyuruldu.

Devamı doğrudan sizi ilgilendiren kısımdır. Toplu istismar Mayıs 2026 başında başladı ve 6 ile 7 Haziran 2026'da zirve yaptı: tek bir günde 4 milyondan fazla engellenen istek ve Wordfence'e göre toplamda 17 milyondan fazla deneme. Bu ölçekte soru, sitenizin yoklanıp yoklanmadığı değil, yoklandığı anda güncel olup olmadığıdır.

## Anahtar sızıntısından sonra işlem sırası

1. **Anahtara dokunmadan önce sızıntıyı kapatın** — Eskisini açığa çıkaran eklenti hâlâ yerinde ve düzeltilmemişken yeni bir anahtar üretirseniz, yenisi de aynı yoldan, bazen birkaç saat içinde sızar. Bu yüzden ilk işlem, ilgili eklentiyi güncellemek veya güncelleme hemen mümkün değilse geçici olarak devre dışı bırakmaktır.
2. **Eskisini iptal etmeden önce yenisini oluşturun** — Çoğu gönderim sağlayıcısında birden fazla anahtar bir arada bulunabilir. Yenisini oluşturun, site yapılandırmasına kaydedin, bir test e-postası gönderin, ulaştığını doğrulayın ve ancak ondan sonra eskisini iptal edin. İptal edilip yerine yenisi konmayan bir anahtar tüm sipariş onaylarınızı keser ve bunu müşteri şikâyetlerinden öğrenirsiniz.
3. **Her şeyi anlamayı beklemeden iptal edin** — İnceleme günler sürebilir; anahtar ise saniyesinde kullanılabilir. Önce iptal ederim, sonra anlarım. Tersi, soruşturma boyunca açık bir kapı bırakmak demektir ve bu hiçbir zaman iyi bir takas değildir.
4. **Diğer sırları da ele geçirilmiş sayın** — Bir sistem raporunda dışarı çıkan yalnızca gönderim anahtarı değildir. Diğer e-posta bağlayıcılarının jetonları, veritabanı kimlik bilgileri ve açığa çıkan yapılandırmanın tamamı bilinir kabul edilmelidir. Yenilenebilecek olanı yenileyin, geri kalanını değiştirin ve neyi değiştirdiğinizi yazılı olarak tutun.
5. **Sunucu günlüklerini yeniden okuyun** — Anahtar değiştirildikten sonra erişim günlüklerinde REST API çağrılarını ve dönen yanıt kodlarını arayın. Uç noktanın sitenizde çağrılıp çağrılmadığını ve hangi tarihten itibaren çağrıldığını size bu söyler. Barındırıcınız günlükleri yalnızca birkaç gün saklıyorsa, iz bulunmaması hiçbir şeyi kanıtlamaz.

## Savunmasız bir gönderim eklentisi tek yol değildir

> Haziran 2026'da ShapedPlugin adlı yayıncının derleme ve dağıtım altyapısı ele geçirildi. Product Slider Pro for WooCommerce, Real Testimonials Pro ve Smart Post Show Pro ürünlerinin tuzaklanmış Pro sürümleri, yayıncının kendi resmi kanalından, LicenseLoader.php adlı bir yükleyici dosyayla birlikte dağıtıldı. Bu yük, wp-config.php dosyasının tamamını, yönetici hesaplarını, e-posta gönderim eklentilerinin sakladığı kimlik bilgilerini (WP Mail SMTP, Post SMTP, Easy WP SMTP) ve son üç ayın WooCommerce siparişlerini dışarı çıkarıyordu. CVE-2026-10735 referansı, CVSS puanı 9,8; giderim 16 Haziran 2026'da başladı, duyuru 22 Haziran 2026 tarihlidir. Başka bir deyişle: hiçbir e-posta eklentisi savunmasız olmasa bile gönderim anahtarınız sızabilir.

## verification-apres-fuite.sh

```
# Journaux d'acces : appels a l'API REST, groupes par IP et par route
grep -h 'wp-json' access.log* | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -40

# Fichiers PHP modifies dans les 30 derniers jours
find wp-content -type f -name '*.php' -mtime -30 -ls | head -40
```

## Konuyla ilgili diğer sayfalar

- **Sitem yazmadığım e-postalar gönderiyor** — Sorunun diğer yüzü: sitenin kendisi gönderim makinesine dönüştüğünde. ([/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits](/securite/mon-site-envoie-des-emails-que-je-n-ai-pas-ecrits))
- **Sipariş e-postaları artık ulaşmıyor** — Bir anahtar yerine yenisi konmadan iptal edildiğinde müşteri tarafında olanlar. ([/wordpress-woocommerce/problemes/emails-commande-non-recus](/wordpress-woocommerce/problemes/emails-commande-non-recus))
- **Sitemin ele geçirilip geçirilmediğini kontrol etme** — Sızan sırların bir giriş noktası olarak kullanılmış olabileceği durumda yapılacak kontroller. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **REST API** — REST API uç noktası nedir ve bozuk bir izin denetimi neden her şeyi açar. ([/glossaire/api-rest](/glossaire/api-rest))

## FAQ

### Sağlayıcım anahtarımı kapattı: sitem mutlaka ele geçirilmiş midir?

Zorunlu olarak değil. Bir anahtar, sunucu hiç değiştirilmeden de okunabilir: CVE-2026-4020 örneğinde sistem raporunu elde etmek için tek bir REST API uç noktasını sorgulamak yetiyordu. Site değiştirilmemiş, yalnızca okunmuştu. Bu, sizin adınıza e-posta göndermek için zaten yeterlidir.

### Anahtarı yeniden üretirsem sorun çözülür mü?

Yalnızca onu açığa çıkaran eklenti önce düzeltildiyse. Aksi hâlde yeni anahtar da eskisiyle aynı açık yolun ardında durur. Önce güncellerim, sonra değiştiririm ve eski anahtarı iptal etmeden önce bir test e-postasının ulaştığını doğrularım.

### Aynı anda başka hangi anahtarları değiştirmeliyim?

Açığa çıkan sistem raporunda yer alan hepsini: diğer e-posta bağlayıcılarının jetonları, veritabanı kimlik bilgileri ve daha geniş olarak site yapılandırmasında tutulan her sır. Tedbir olarak yönetici parolasını da.

### Sitemin gerçekten hedef alınıp alınmadığını nasıl anlarım?

Sunucunun erişim günlükleriyle: ilgili uç noktaya yapılan çağrılar ve dönen yanıt kodu aranır. Barındırıcınız yalnızca birkaç günlük geçmiş saklıyorsa, iz bulunmaması olay olmadığı anlamına gelmez.

### Müşterilerimi bilgilendirmeli miyim?

Neyin sızdığına bağlıdır. Sistem raporu siparişlerinizi değil kurulumunuzu anlatır; ancak bir dağıtım zinciri ihlalinde sipariş verileri de işin içine girebilir. Kişisel veriler söz konusu olduğu anda konu hukuki bir konuya dönüşür: ihlali iç kayıt defterine işlemek ve kişiler için risk varsa 72 saat içinde yetkili denetim otoritesine bildirmek gerekir.