Redis heeft op 23 juli zeven beveiligingsreleases verzonden nadat onderzoekers geverifieerde RCE PoC’s hadden gepubliceerd voor de standaard Redis 6.2.22, 7.4.9, 8.6.4 en 8.8.0.
Voor alle vier de ketens is RESTORE vereist. De Streams-ketens hebben ook EVAL en XGROUP nodig; de 8.8.0-keten heeft EVAL en de gebundelde RedisBloom-module nodig. Redis zegt het onderliggende geheugen fouten kunnen leiden tot uitvoering van code op afstand.
Redis 6.2.23, 7.2.15 en 7.4.10 repareren de Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5 en 8.6.5 repareren zowel het Streams-probleem als de RedisBloom- en TDigest-out-of-bounds-schrijfbewerkingen; Redis 8.8.1 repareert de RedisBloom- en TDigest-laders, terwijl de Streams-guard al aanwezig was in Redis 8.8.0.
Twee PoC-doelen, Redis 6.2.22 en 7.4.9, waren de beveiligingsupdates van mei die Redis gebruikers vertelde te installeren, maar die releases bevatten niet de gedeelde NACK-eigendomsbewaking.
Upgrade naar de vaste release voor de geïmplementeerde vertakking. Trek tot die tijd RESTORE in voor accounts die dit niet strikt nodig hebben en blokkeer niet-vertrouwde netwerktoegang. Door RESTORE te beperken, worden beide openbaar gemaakte paden afgesloten.
Noch de release-opmerkingen van Redis van 23 juli, noch de beoordeelde openbare PoC-repository’s maakten melding van exploitatie in het wild vanaf 24 juli 2026.
Twee wegen via RESTORE
Het Redis Streams-pad is een bug met gedeeld eigendom. Een beschadigd RDB-object kan ervoor zorgen dat twee consumenten naar hetzelfde record voor inkomende invoer verwijzen, dus als u beide consumenten verwijdert, wordt hetzelfde object twee keer vrijgegeven.
Het gepubliceerde script is ontworpen om de resulterende geheugenbeschadiging om te zetten in willekeurige geheugentoegang en uiteindelijk system() aan te roepen.
Het RedisBloom-pad is een schrijfbewerking buiten het bereik in de TDigest RDB-lader. De lader wees geheugen toe op basis van één geserialiseerde waarde, maar vertrouwde op een afzonderlijk door de aanvaller gecontroleerd capaciteitsveld bij het beslissen hoeveel gegevens er moesten worden geladen.
Het Redis 8.8.0-script is ontworpen om die mismatch om te zetten in lees- en schrijfprimitieven, Redis- en libc-adressen te lekken en system() aan te roepen.
De Streams Shared-NACK-keten
Het eerste pad bevindt zich in Redis Streams. Een beschadigd RDB-object kan ervoor zorgen dat twee consumenten naar hetzelfde record voor inkomende invoer verwijzen, intern weergegeven door een streamNACK. Als u de eerste consument verwijdert, wordt het object bevrijd en laat de tweede een bungelende aanwijzer achter. De scripts verwijderen vervolgens ook de tweede consument. Eén stuk, twee vrijslagen.
In de releaseopmerkingen van Redis 8.6.4 wordt PR #15081 genoemd. Maar uit een bronnenonderzoek door The Hacker News bleek dat de getagde 8.6.4-bron de dubbele eigendomscontrole mist die door die wijziging is toegevoegd. De bewaker verschijnt in Redis 8.6.5, uitgebracht op 23 juli.
Het gepubliceerde Redis 8.6.4-script is ontworpen om de double-free om te zetten in willekeurige geheugentoegang en vervolgens een database-hashfunctie te vergiftigen, zodat een vervaardigde GET system() aanroept. Het herstelt de aanwijzer en controleert of Redis nog steeds reageert.
De RedisBloom TDigest-keten
Het tweede pad bevindt zich in de RedisBloom TDigest RDB-lader. Het kende zijn zwaartepuntarrays toe op basis van een geserialiseerde compressiewaarde en vertrouwde vervolgens op een afzonderlijk door de aanvaller gecontroleerd capaciteitsveld bij het bepalen hoeveel knooppunten konden worden geladen. Een kleine reële toewijzing gecombineerd met opgeblazen metadata levert een schrijffout op die buiten het bereik valt.
Het Redis 8.8.0-script is ontworpen om het schrijven om te zetten in lees- en schrijfprimitieven, Redis- en libc-adressen te lekken en een database-hashfunctie te vergiftigen, zodat een vervaardigd GET-oproepsysteem () ontstaat. Een afzonderlijk proof of concept publiceerde dezelfde hoofdoorzaak en een geverifieerde RCE-keten tegen Redis 8.8.0.
De juli-oplossing van Redis vereist dat de geladen TDigest-capaciteit overeenkomt met de toewijzing die is afgeleid van de compressiewaarde. Het begrenst ook de samengevoegde en niet-samengevoegde knooppunttellers voordat de arrays worden gelezen.
Zeven releases, geen nieuwe CVE-records
De repository noemt het Streams-probleem onderdeel van een CVE-2026-25589 “onvolledige oplossingsfamilie”, maar Redis wijst die CVE toe aan RedisBloom-geheugencorruptie tijdens RESTORE, en niet aan de gedeelde NACK-fout in Streams. In de release-opmerkingen van Redis voor juli wordt geen CVE- of CVSS-score vermeld voor beide nieuwe bugklassen.
Vanaf 24 juli vonden zoekopdrachten van The Hacker News geen afzonderlijk NVD-record voor de gedeelde NACK- of TDigest-bevindingen van juli. NVD vermeldde nog steeds de mei-records voor CVE-2026-25243 en CVE-2026-25589. Een zoekopdracht in de catalogus met bekende uitgebuite kwetsbaarheden van CISA leverde geen van beide identificatiegegevens op.
De onthulling volgt op een andere door AI ontdekte Redis RCE-fout die in mei is hersteld. Bera Buddies omschrijft zichzelf als ‘AI Agent Research’. Chaofan Shou zei op X dat Kimi K3-agenten 19 Redis zero-days vonden in ongeveer 90 minuten, en zei dat een nieuwe run de Redis 8.8.0-exploit in 27 minuten opleverde.
Deze tellingen, timings en de geclaimde mate van autonomie blijven zelfgerapporteerd. Het openbare record van Redis bevestigt de fouten en oplossingen. Het valideert niet de geclaimde nuldagentelling of hoe onafhankelijk de agenten werkten.
Redis 6.2.22 en 7.4.9 waren de bestemming van mei. In juli hadden beide een nieuwe update nodig. Controleer de exacte branchversie, niet of Redis slechts “recentelijk gepatcht” is.
