O Redis disponibilizou sete atualizações de segurança em 23 de julho, depois que pesquisadores publicaram provas de conceito (PoCs) de execução remota de código autenticado (RCE) para as versões padrão do Redis 6.2.22, 7.4.9, 8.6.4 e 8.8.0.
Todas as quatro cadeias de exploit exigem o comando RESTORE. As cadeias baseadas em Streams também precisam de EVAL e XGROUP; a cadeia para a versão 8.8.0 precisa de EVAL e do módulo RedisBloom, distribuído junto com o Redis. O Redis afirma que as falhas de memória subjacentes podem levar à execução remota de código.
As versões Redis 6.2.23, 7.2.15 e 7.4.10 corrigem o use-after-free (uso após liberação) de NACK (notificação de não confirmação) compartilhado do Streams; as versões Redis 8.2.8, 8.4.5 e 8.6.5 corrigem tanto o problema do Streams quanto as escritas fora dos limites (out-of-bounds writes) do RedisBloom e do TDigest; o Redis 8.8.1 corrige os carregadores do RedisBloom e do TDigest, enquanto a proteção do Streams já estava presente no Redis 8.8.0.
Dois alvos das PoCs, o Redis 6.2.22 e o 7.4.9, foram as atualizações de segurança de maio que o Redis recomendou aos usuários instalarem, mas essas versões não incluíam a proteção de propriedade do NACK compartilhado.
Faça a atualização para a versão corrigida da branch implantada. Até lá, revogue o acesso ao comando RESTORE de contas que não precisem estritamente dele e bloqueie o acesso de rede não confiável. Restringir o RESTORE interrompe ambos os caminhos de exploit divulgados.
Nem as notas de lançamento do Redis de 23 de julho nem os repositórios públicos de PoCs analisados relataram exploração em ambiente real até 24 de julho de 2026.
Dois caminhos através do RESTORE
O caminho via Redis Streams é um bug de propriedade compartilhada. Um objeto RDB (arquivo de banco de dados do Redis) corrompido pode fazer dois consumidores apontarem para o mesmo registro de entrada pendente; ao remover ambos os consumidores, o mesmo objeto é liberado duas vezes.
O script publicado foi projetado para transformar a corrupção de memória resultante em acesso arbitrário à memória e, por fim, invocar a função system().
O caminho via RedisBloom é uma escrita fora dos limites no carregador RDB do TDigest. O carregador alocou memória a partir de um valor serializado, mas confiou em um campo de capacidade separado, controlado pelo atacante, ao decidir quanto dado carregar.
O script para o Redis 8.8.0 foi projetado para transformar esse descasamento em primitivas de leitura e escrita, vazar endereços do Redis e da libc (biblioteca padrão da linguagem C) e chamar a função system().
A cadeia de NACK compartilhado do Streams
O primeiro caminho está no Redis Streams. Um objeto RDB corrompido pode fazer dois consumidores apontarem para o mesmo registro de entrada pendente, representado internamente por um streamNACK. Remover o primeiro consumidor libera o objeto e deixa o segundo com um ponteiro pendente (dangling pointer). Os scripts então removem também o segundo consumidor. Um único bloco, duas liberações.
As notas de lançamento do Redis 8.6.4 citam o PR #15081. Mas uma análise do código-fonte feita pelo The Hacker News descobriu que o código-fonte marcado como 8.6.4 não contém a verificação de propriedade duplicada adicionada por essa alteração. A proteção aparece no Redis 8.6.5, lançado em 23 de julho.
O script publicado para o Redis 8.6.4 foi projetado para transformar a liberação dupla (double-free) em acesso arbitrário à memória e, em seguida, envenenar uma função hash do banco de dados para que um comando GET (obtenção de chave) manipulado invoque a função system(). O script restaura o ponteiro e verifica se o Redis ainda responde.
A cadeia TDigest do RedisBloom
O segundo caminho está no carregador RDB do TDigest do RedisBloom. Ele alocou seus arrays de centroides a partir de um valor de compressão serializado e, em seguida, confiou em um campo de capacidade separado, controlado pelo atacante, ao decidir quantos nós poderiam ser carregados. Uma alocação real pequena combinada com metadados inflados produz uma escrita fora dos limites.
O script para o Redis 8.8.0 foi projetado para transformar a escrita em primitivas de leitura e escrita, vazar endereços do Redis e da libc e envenenar uma função hash do banco de dados para que um comando GET manipulado chame a função system(). Uma prova de conceito separada, publicada na mesma época, trata da mesma causa raiz e apresenta uma cadeia de RCE autenticado contra o Redis 8.8.0.
A correção de julho do Redis exige que a capacidade do TDigest carregado corresponda à alocação derivada do valor de compressão. A correção também limita os contadores de nós mesclados e não mesclados antes da leitura dos arrays.
Sete lançamentos, sem novos registros de CVE
O repositório classifica o problema do Streams como parte de uma "família de correções incompletas" do CVE-2026-25589, mas o Redis associa esse CVE (Vulnerabilidades e Exposições Comuns) à corrupção de memória do RedisBloom durante o RESTORE, e não à falha de NACK compartilhado do Streams. As notas de lançamento de julho do Redis não listam nenhum CVE nem pontuação CVSS (Sistema Comum de Pontuação de Vulnerabilidades) para nenhuma das novas classes de bug.
Até 24 de julho, buscas feitas pelo The Hacker News não encontraram nenhum registro separado no NVD (Banco Nacional de Vulnerabilidades dos EUA) para as descobertas de julho sobre NACK compartilhado ou TDigest. O NVD ainda listava os registros de maio para o CVE-2026-25243 e o CVE-2026-25589. Uma busca no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA (Agência de Segurança Cibernética e Infraestrutura dos EUA) não retornou nenhuma entrada para nenhum dos identificadores.
A divulgação ocorre após outra falha de RCE no Redis descoberta por inteligência artificial (IA), corrigida em maio. O Bera Buddies se descreve como "AI Agent Research" (Pesquisa com Agentes de IA). Chaofan Shou disse no X que agentes do Kimi K3 encontraram 19 zero-days no Redis em cerca de 90 minutos, e afirmou em outro post que uma execução diferente produziu o exploit para o Redis 8.8.0 em 27 minutos.
Essas contagens, tempos e o suposto grau de autonomia são autorrelatados. O registro público do Redis confirma as falhas e as correções, mas não valida a contagem de zero-days declarada nem o grau de independência com que os agentes trabalharam.
As versões Redis 6.2.22 e 7.4.9 eram o destino de maio. Em julho, ambas precisavam de outra atualização. Verifique a versão exata da branch, e não apenas se o Redis foi "recentemente corrigido".
