IBM QRadar EDR'da TOTP doğrulamasında deneme sınırı açığı (CVE-2026-91869): düzeltme 3.12.27 sürümünde
IBM, Security QRadar EDR 3.12 – 3.12.26 sürümlerini etkileyen iki açık için güvenlik bülteni yayımladı. CVE-2026-91869 (CVSS 8.1) TOTP doğrulamasındaki yetersiz deneme sınırı nedeniyle güvenlik kısıtlamalarının aşılmasına, CVE-2026-91868 (CVSS 6.5) hassas bilginin açığa çıkmasına yol açabiliyor. Düzeltme 3.12.27; workaround yok.
CVE-2026-91869, CVE-2026-91868
IBM, EDR ürünü Security QRadar EDR (eski adıyla ReaQta) için iki açığı kapatan bir güvenlik bülteni yayımladı. Bültenin ilk yayın tarihi 11 Kasım 2026; CVE kayıtları NVD'ye 13 Kasım'da işlendi. Öne çıkan açık CVE-2026-91869: IBM'in verdiği CVSS 3.1 puanı 8.1 (yüksek), zafiyet sınıfı CWE-307, yani aşırı kimlik doğrulama denemesinin yeterince sınırlandırılmaması. Bültene göre TOTP (tek kullanımlık kod) doğrulamasındaki deneme sınırı yetersiz ve kimliği doğrulanmış uzak bir saldırgan bu yolla güvenlik kısıtlamalarını aşabiliyor.
Aynı bültendeki ikinci açık CVE-2026-91868 (CVSS 6.5, CWE-284): hatalı erişim denetimi nedeniyle kimliği doğrulanmış uzak bir saldırgan hassas bilgi elde edebiliyor. Her iki açık da ağ üzerinden, düşük yetkili bir hesapla ve kullanıcı etkileşimi olmadan tetiklenebilir olarak puanlanmış. Bültende sahada istismar bilgisi yer almıyor; açıklar bu haberin yazıldığı sırada CISA KEV kataloğunda değil. Yine de konu bir EDR yönetim platformu: konsol hesabı, uç noktalardaki tespit ve müdahale yetkilerine açılan kapıdır ve MFA katmanındaki bir zayıflık bu yüzden ciddiye alınmalı.
Etkilenen ve düzeltilmiş sürümler
| Ürün | Etkilenen | Düzeltilmiş sürüm |
|---|---|---|
| IBM Security QRadar EDR | 3.12 – 3.12.26 | 3.12.27 |
Sürümler IBM bültenindeki haliyle verilmiştir. IBM, bültendeki listenin yalnızca destek süresi devam eden sürümleri kapsadığını, listede olmayan desteği bitmiş sürümlerin "etkilenmiyor" anlamına gelmediğini belirtiyor. Bültende workaround ya da hafifletme önlemi verilmiyor ("None").
Beni etkiliyor mu?
Ortamınızda IBM Security QRadar EDR 3.12 dalı çalışıyorsa ve sürüm 3.12.26 ya da altındaysa etkileniyorsunuz. IBM'e göre QRadar EDR operator'ı, abonelik kanalında yeni uyumlu sürüm çıktığında varsayılan "Automatic" onay stratejisiyle kendiliğinden yükselir; strateji "Manual" seçilmişse güncelleme onayınızı bekler. Bu yüzden iki şeye bakın: kurulu sürüm ve onay stratejisi.
Ürünün çalıştığı OpenShift cluster'ında kurulu operator sürümlerini listelemek için:
kubectl get csv -AAboneliklerin kanalını ve kurulu sürümünü görmek için:
kubectl get subscription -AOperator ve namespace adları kurulumdan kuruluma değişebilir; çıktıda QRadar EDR satırını bulamazsanız OpenShift konsolunda Operators › Installed Operators ekranından sürümü ve "Update approval" değerini kontrol edin. Sürüm 3.12.27'nin altındaysa ve onay stratejisi "Manual" ise bekleyen bir güncelleme onayı olabilir.
Ne yapılmalı?
- QRadar EDR'ı 3.12.27 sürümüne yükseltin. Onay stratejisi "Automatic" ise yükseltmenin gerçekten tamamlandığını sürüm kontrolüyle doğrulayın; "Manual" ise bekleyen operator güncellemesini change management sürecinizden geçirip onaylayın.
- Workaround bulunmadığı için yükseltmeye kadar maruziyeti azaltın: EDR konsoluna erişimi yönetim ağı ya da VPN ile sınırlayın. Bu, IBM'in önerdiği bir workaround değil, genel bir önlemdir.
- Açık kimliği doğrulanmış bir saldırgan gerektirdiği için konsol hesaplarını gözden geçirin: kullanılmayan hesapları kapatın, parolası sızmış olabilecek hesapların parolasını yenileyin.
- Konsolun kimlik doğrulama loglarında aynı hesap için kısa sürede çok sayıda başarısız TOTP denemesine ve ardından gelen başarılı girişe bakın; tanımadığınız kaynak adreslerinden gelen oturumları inceleyin.
- Yükseltmeden sonra yönetici hesaplarının MFA kayıtlarının beklediğiniz cihazlara ait olduğunu doğrulayın.
