A Redis lançou sete atualizações de segurança em 23/07, depois que pesquisadores publicaram provas de conceito de RCE autenticado para as versões padrão do Redis 6.2.22, 7.4.9, 8.6.4 e 8.8.0.
As quatro cadeias de ataque exigem o comando RESTORE.
As cadeias ligadas a Streams também precisam de EVAL e XGROUP; a cadeia do 8.8.0 depende de EVAL e do módulo RedisBloom, que vem integrado.
Segundo a Redis, as falhas subjacentes de memória podem levar à execução remota de código.
As versões Redis 6.2.23, 7.2.15 e 7.4.10 corrigem o uso após liberação no mecanismo shared-NACK de Streams.
Já o Redis 8.2.8, 8.4.5 e 8.6.5 corrigem tanto esse problema quanto as gravações fora dos limites no RedisBloom e no TDigest.
O Redis 8.8.1 corrige os carregadores do RedisBloom e do TDigest, enquanto a proteção em Streams já estava presente no Redis 8.8.0.
Dois alvos das provas de conceito, Redis 6.2.22 e 7.4.9, eram justamente as atualizações de segurança de maio que a Redis havia recomendado aos usuários, mas essas versões não incluíam a proteção de propriedade compartilhada do shared-NACK.
A recomendação é atualizar para a versão corrigida da ramificação em uso.
Até lá, revogue o RESTORE de contas que não precisem dele de forma estrita e bloqueie acesso de rede não confiável.
Limitar o RESTORE corta os dois caminhos divulgados.
Nem as notas de lançamento da Redis de 23/07 nem os repositórios públicos das provas de conceito analisados relataram exploração ativa em ambiente real até 24/07/2026.
Dois caminhos via RESTORE
O caminho em Redis Streams é uma falha de propriedade compartilhada.
Um objeto RDB corrompido pode fazer dois consumidores apontarem para o mesmo registro de entrada pendente, de modo que a remoção dos dois consumidores libera o mesmo objeto duas vezes.
O script publicado foi criado para transformar essa corrupção de memória em acesso arbitrário à memória e, por fim, acionar system().
O caminho via RedisBloom é uma gravação fora dos limites no carregador RDB do TDigest.
O carregador alocava memória com base em um valor serializado, mas confiava em um campo de capacidade separado, controlado pelo atacante, ao decidir quanto dado carregar.
O script do Redis 8.8.0 foi criado para transformar essa divergência em primitivas de leitura e escrita, vazar endereços do Redis e do libc e chamar system().
A cadeia shared-NACK em Streams
O primeiro caminho está em Redis Streams.
Um objeto RDB corrompido pode fazer dois consumidores apontarem para o mesmo registro de entrada pendente, representado internamente por um streamNACK.
A remoção do primeiro consumidor libera o objeto e deixa o segundo com um ponteiro pendurado.
Os scripts então removem o segundo consumidor também.
Um bloco, duas liberações.
As notas de lançamento do Redis 8.6.4 citam a PR #15081.
Mas uma análise de código encontrou, no código-fonte marcado do 8.6.4, a ausência da verificação de propriedade duplicada adicionada por essa mudança.
A proteção aparece no Redis 8.6.5, lançado em 23/07.
O script publicado para o Redis 8.6.4 foi projetado para transformar o double free em acesso arbitrário à memória e, em seguida, corromper uma função de hash do banco de dados para que um GET preparado acione system().
O código também restaura o ponteiro e verifica se o Redis continua respondendo.
A cadeia do RedisBloom e do TDigest
O segundo caminho está no carregador RDB do TDigest do RedisBloom.
Ele alocava seus vetores de centróides com base em um valor de compressão serializado e, depois, confiava em um campo separado de capacidade, controlado pelo atacante, para decidir quantos nós poderiam ser carregados.
Uma alocação real pequena combinada com metadados inflados produz uma gravação fora dos limites.
O script do Redis 8.8.0 foi criado para transformar a gravação em primitivas de leitura e escrita, vazar endereços do Redis e do libc e corromper uma função de hash do banco de dados para que um GET preparado chame system().
Uma prova de conceito separada publicou a mesma causa raiz e uma cadeia de RCE autenticado contra o Redis 8.8.0.
A correção de julho da Redis exige que a capacidade do TDigest carregado corresponda à alocação derivada do valor de compressão.
Ela também limita os contadores de nós mesclados e não mesclados antes de ler os vetores.
Sete versões, sem novos registros de CVE
O repositório chama o problema de Streams de parte de uma “família de correção incompleta” do
CVE-2026-25589
, mas a Redis associa esse CVE à corrupção de memória no RedisBloom durante o RESTORE, e não à falha shared-NACK em Streams.
As notas de lançamento de julho da Redis não trazem CVE nem pontuação CVSS para nenhuma das duas novas classes de bugs.
Em 24/07, não encontraram registro separado no NVD para as descobertas de julho em shared-NACK ou TDigest.
O NVD ainda listava os registros de maio para
CVE-2026-25243
e
CVE-2026-25589
.
Uma consulta ao catálogo Known Exploited Vulnerabilities da CISA não retornou entrada para nenhum dos identificadores.
A divulgação ocorre depois de outra falha de RCE no Redis descoberta por IA e corrigida em maio.
A Bera Buddies se descreve como “AI Agent Research”.
Chaofan Shou disse no X que agentes do Kimi K3 encontraram 19 zero-days no Redis em cerca de 90 minutos e afirmou que outra execução produziu o exploit do Redis 8.8.0 em 27 minutos.
Esses números, tempos e o grau de autonomia alegado continuam sendo autorrelatados.
O registro público da Redis confirma as falhas e as correções, mas não valida a contagem de zero-days nem o nível de independência dos agentes.
Redis 6.2.22 e 7.4.9 eram o destino em maio.
Em julho, ambos já exigiam outra atualização.
Verifique a versão exata da ramificação, e não apenas se o Redis foi “recentemente corrigido”.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...