Redis, 23 Temmuz’da yedi ayrı güvenlik sürümü yayımladı. Bu güncellemeler, araştırmacıların Redis 6.2.22, 7.4.9, 8.6.4 ve 8.8.0 için kimliği doğrulanmış uzaktan kod çalıştırma kanıtları paylaşmasının ardından geldi. Dört saldırı zincirinin tamamı RESTORE komutunu kullanıyor; Streams tarafındaki zincirler ayrıca EVAL ve XGROUP, 8.8.0 zinciri ise EVAL ile birlikte paketle gelen RedisBloom modülünü de gerektiriyor.
Redis’in açıklamasına göre alttaki bellek hataları uzaktan kod çalıştırmaya kadar gidebiliyor. Şirketin yayımladığı düzeltmeler, dağıtılmış sürüme göre farklılık gösteriyor: Redis 6.2.23, 7.2.15 ve 7.4.10 Streams içindeki shared-NACK use-after-free sorununu kapatıyor; Redis 8.2.8, 8.4.5 ve 8.6.5 hem bu Streams hatasını hem de RedisBloom ve TDigest bileşenlerindeki out-of-bounds write açığını düzeltiyor; Redis 8.8.1 ise RedisBloom ve TDigest yükleyicilerini yamanıyor. Streams için gerekli koruma 8.8.0 sürümünde zaten yer alıyordu.
İncelenen kanıtlardan ikisi, Redis’in mayıs ayında kullanıcıların kurmasını istediği 6.2.22 ve 7.4.9 sürümlerini hedef alıyordu. Ancak o güncellemeler shared-NACK sahiplik kontrolünü içermediği için, aynı ailede yeni zincirler daha sonra da kuruldu. Araştırmacılar, yayımlanan PoC’lerin çalıştığını gösterdi; buna karşın 24 Temmuz 2026 itibarıyla sahada aktif istismar işaretine rastlanmadığını da belirtti.
Yeni açıkların birinde hedef Redis Streams. Kötü amaçlı biçimde hazırlanmış bir RDB nesnesi, iki tüketicinin aynı bekleyen giriş kaydını paylaşmasına yol açabiliyor. İçeride streamNACK olarak tutulan bu kayıt, ilk tüketici silindiğinde serbest kalıyor; ikinci tüketici de aynı nesneyi tuttuğu için dangling pointer oluşuyor. Paylaşılan kod, bu bellek bozulmasını önce keyfi bellek erişimine, ardından da system() çağrısına çevirmeyi amaçlıyor. Akışın sonunda saldırgan, veritabanı hash işlevini zehirleyerek hazırlanmış bir GET isteğini komut çalıştırmaya dönüştürüyor.
Redis 8.6.4 için yayımlanan zincir de aynı yolun üzerinde ilerliyor. The Hacker News tarafından yapılan kaynak incelemesine göre 8.6.4 etiketli kod, Redis’in PR #15081 ile eklediği çift sahiplik kontrolünü taşımıyor. Koruma 23 Temmuz’da yayımlanan Redis 8.6.5 sürümünde görünüyor. Saldırı zincirinin ilk adımında double-free bellek bozulması elde ediliyor, ardından saldırgan bunun üzerinden keyfi bellek erişimi kuruyor. Son aşamada veritabanı hash işlevi manipüle edilerek crafted GET çağrısı system() çalıştıracak şekilde yönlendiriliyor; PoC, pointer’ı eski yerine koyup Redis’in yanıt verip vermediğini de kontrol ediyor.
İkinci yol RedisBloom içindeki TDigest RDB yükleyicisinde yer alıyor. Yükleyici, centroid dizileri için belleği seri hale getirilmiş compression değerine göre ayırıyor, fakat kaç düğüm yükleneceğini belirlerken saldırganın kontrol edebildiği ayrı bir capacity alanına güveniyordu. Gerçekte küçük ayrılmış bellek ile şişirilmiş meta verinin birleşmesi, out-of-bounds write üretiyor. Redis 8.8.0 için hazırlanan script bu uyuşmazlığı önce okuma ve yazma ilkelere dönüştürmeyi, sonra Redis ve libc adreslerini sızdırmayı hedefliyor. Ardından yine veritabanı hash işlevi zehirlenerek hazırlanmış bir GET isteği üzerinden system() çağrısı zincirleniyor. Aynı kök nedene dayanan ayrı bir proof of concept de 8.8.0 üzerinde kimliği doğrulanmış RCE zinciri gösterdi.
Redis’in temmuz yamasında TDigest kapasitesinin, compression değerinden türetilen bellek ayırma miktarıyla eşleşmesi zorunlu hale getirildi. Şirket ayrıca, diziler okunmadan önce birleştirilmiş ve birleştirilmemiş düğüm sayaçlarını sınırlandırdı. Böylece hem taşma hem de yanlış boyutlandırma kaynaklı yazma işlemleri engellenmeye çalışıldı.
Yayımlanan repository, Streams tarafını CVE-2026-25589 için “eksik düzeltme ailesi” olarak tanımlıyor. Ancak Redis bu CVE’yi Streams shared-NACK kusuruna değil, RESTORE sırasında oluşan RedisBloom bellek bozulmasına eşlemiş durumda. Temmuz sürüm notlarında yeni iki hata sınıfı için ne CVE ne de CVSS puanı yer aldı. 24 Temmuz itibarıyla NVD’de Temmuz’daki shared-NACK ve TDigest bulguları için ayrı bir kayıt görünmüyordu; katalogda hâlâ mayıs kayıtları olan CVE-2026-25243 ve CVE-2026-25589 listeleniyordu. CISA’nın Known Exploited Vulnerabilities kataloğunda da bu kimliklerden herhangi biri yer almadı. İlgili kayıtlar için NVD bağlantıları şöyle: https://nvd.nist.gov/vuln/detail/CVE-2026-25243 ve https://nvd.nist.gov/vuln/detail/CVE-2026-25589.
Gelişme, mayıs ayında yamalanan başka bir yapay zekâ kaynaklı Redis RCE bulgusundan sonra geldi. Bera Buddies kendisini “AI Agent Research” olarak tanımlıyor. Chaofan Shou, X üzerinde Kimi K3 ajanlarının yaklaşık 90 dakikada 19 Redis zero-day bulduğunu yazdı; başka bir çalıştırmada ise Redis 8.8.0 için çalışan exploit’in 27 dakikada üretildiğini söyledi. Bu sayıların, sürelerin ve ajanların ne kadar bağımsız çalıştığına ilişkin iddiaların tamamı araştırmacıların kendi beyanına dayanıyor. Redis’in açık kayıtları ise sadece kusurları ve düzeltmeleri doğruluyor; zero-day sayısını ya da ajanların özerklik düzeyini teyit etmiyor.
Mayıs ayında güvenli kabul edilen 6.2.22 ve 7.4.9 sürümleri, temmuzdaki yeni zincirler nedeniyle yeniden güncelleme gerektiriyor. Redis çalışanlarının ilettiği mesaj net: “yakın zamanda yamalandı” ifadesi yeterli değil, hangi dalın hangi sürümde olduğu ayrıca kontrol edilmeli. RESTORE yetkisini gerçekten gerekmeyen hesaplardan kaldırmak ve güvenilmeyen ağ erişimini engellemek, açıklanan iki saldırı yolunu da kapatıyor.