· kaynak dev.to (home feed)
CVSS 10.0 puanlı WSO2 API Manager JWT kimlik doğrulama atlaması sahadaki saldırılarda görüldü
WSO2'nün API yönetim ürünlerindeki kritik bir kimlik doğrulamasız zafiyet (CVE-2026-5430), saldırganların JWT doğrulamasını atlatmasına olanak tanıyor; watchTowr bunun istismar girişimlerini çoktan gözlemledi.

Kritik WSO2 zafiyeti nedeniyle kurumlara uyarı
WSO2'nün API yönetim ürünlerini kullanan kurumlar, CVE-2026-5430 olarak takip edilen kritik bir kimlik doğrulama atlamasını istismar eden aktif saldırılar konusunda uyarılıyor. SecurityWeek'in haberine göre zafiyet 10.0'a varan bir CVSS puanına sahip ve kimlik doğrulaması gerektirmiyor; yani saldırganların hedeflemek için geçerli bir hesaba ihtiyacı yok. watchTowr araştırmacıları ilk istismar girişimlerini 13 Eylül 2026'da kaydetti ve WSO2 konuyu kapsayan bir güvenlik duyurusu (WSO2-2026-5328) yayımladı.
Etkilenen ürün ailesi WSO2 API Manager, API Control Plane, Traffic Manager ve Universal Gateway'i kapsıyor.
Atlama nasıl çalışıyor
Zafiyet, ürünlerin JSON Web Token'ları doğrulama biçiminde yatıyor. Etkilenen sürümler, desteklenmeyen imza algoritmalarıyla imzalanmış JWT'leri kabul ediyor; bu da bir saldırganın sahte bir token üreterek bunun gerçekmiş gibi kabul edilmesini sağlıyor. Hiçbir kimlik bilgisi çalınmıyor ve kullanıcı etkileşimi gerekmiyor; tek ön koşul, saldırganın zafiyetli JWT kimlik doğrulama sürecine — tipik olarak internete açık bir API veya yönetim endpoint'ine — erişebilmesi.
watchTowr'nun tekrarlama testleri, başarılı bir atlatmanın ne sağladığını gösterdi. Yakalanmış bir payload'ı doğru ürüne karşı yeniden oynatan araştırmacılar, API backend hedeflerine, kimlik bilgilerine ve kayıtlı uygulamaların consumer key ve secret'larına erişim kazandı. Bir API yönetim platformu dahili hizmetlerin önünde durduğu ve bunların kimlik bilgilerini sakladığı için, bu tek adım dahili ortamın geniş bir kesimini açığa çıkarabiliyor.
Sahada gerçekte ne gözlemlendi
Saha kanıtının dikkatli okunması gerekiyor. watchTowr'nun honeypot ağında bir saldırgan sahte bir JWT gönderdi — ancak bunu yanlış ürüne yöneltti ve o girişim başarılı olmadı. watchTowr ardından aynı payload'ı doğru hedefe karşı oynadı ve kimlik doğrulama atlamasının anlatıldığı gibi çalıştığını doğruladı.
Özetle tablo şu: istismar girişimlerinin sahadaki varlığı doğrulanmış ve zafiyetin istismar edilebilirliği kanıtlanmış durumda; ancak kamuya açık raporlar, gerçek kurban ortamlarında başarılı ele geçirmeleri veya sonraki veri hırsızlıklarını henüz belgelemiyor. Bu boşluk, savunmacılara doğrulanmış ihlaller görünmeye başlamadan önce hareket etme fırsatı tanıyor.
Yama ve kapatma önlemleri
WSO2 duyurusu, ürüne ve sürüme özgü güncelleme seviyeleri belirliyor. Abonelik müşterileri, kendi sürüm dalları için gerekli güncelleme seviyesinde olduklarını doğrulamalı; topluluk dağıtımı kullanıcıları ise ilgili herkese açık yamaların uygulanmış olduğunu kontrol etmeli.
Zafiyetli yollara ağ erişiminin kısıtlanması da bu saldırı rotasını engelliyor; ancak analiz, yalnızca yönetim konsolunu özel hale getirmenin yeterli olmayabileceğine dikkat çekiyor: diğer açık API'ler zafiyetli JWT'leri kabul edecek şekilde yapılandırılmışsa saldırıya açık kalmaya devam ediyorlar. Açığa çıkmış olabilecek tüm kimlik bilgileri veya consumer secret'ları belirlenmeli ve döndürülmalı; döndürme planında bağımlı hizmetler de hesaba katılmalı.
Savunmacılar nelere bakmalı
Kullanıcı etkileşimi söz konusu olmadığı için iş kullanıcıları olağandışı bir şey fark etmeyebilir. Faydalı sinyaller arasında beklenmeyen veya desteklenmeyen imza algoritmaları taşıyan JWT'lerin ardından yüksek yetkili yanıtlar gelmesi, bilinmeyen veya anonim kimlikler tarafından API hedeflerine veya kimlik bilgilerine erişim ve kayıtlı uygulamalarda, consumer key ve secret'larda ya da backend tanımlarında denetim günlüğü değişiklikleri yer alıyor. Standart URL tabanlı proxy logları JWT başlık içeriklerini göstermez; bu nedenle bunların kimlik doğrulama ve API denetim loglarıyla çapraz kontrol edilmesi gerekir. Ekipler ayrıca gateway'in normalde bağlanmadığı dahili API'lere veya veri depolarına giden trafiği de izlemeli.
Neden önemli
API yönetim altyapısı tasarımı gereği bir kritik noktadır: backend hizmetlerinin kimlik bilgilerini tutar ve bunlara trafik aktarır; yönetici hesaplarının tamamen ele geçirilmesinin dahili sistemlere yatay hareket için bir başlangıç noktası haline gelebilmesinin nedeni budur. En yüksek düzeyde ciddiyette, kimlik doğrulamasız bir atlama, kamuya açık uyarıdan günler önce gözlemlenen sahadaki girişimlerle birleşince, açıkta olan her dağıtım için yamalamayı acil hale getiriyor. Hemen yamalayamayan ekipler zafiyetli endpoint'lere erişimi kısıtlamalı; atlama kanıtı bulanlar ise kimlik bilgilerinin açığa çıktığını varsaymalı ve bunları buna göre döndürmelidir.
- #security
- #wso2
- #jwt
- #api-management
- #vulnerability
İlgili yazılar
- Wordfence, The Events Calendar WordPress eklentisinde iki kimlik doğrulaması gerektirmeyen RCE zinciri buldu
- CVE-2026-32746: 1994 döneminden kalma, kimlik doğrulama öncesi telnetd taşması Linux, BSD'ler ve cihazlara ulaşıyor
- Google, sınırlı aktif sömürü altındaki Pixel modem yetkilendirme atlatma açığı CVE-2026-58704'ü yamaladı