📰 Informação fresquinha chegando para você!
Leia, comente e fique sempre atualizado!
Apoie esse projeto de divulgacao de noticias! Clique aqui
O Redis lançou sete versões de segurança em 23 de julho, depois que os pesquisadores publicaram PoCs RCE autenticados para o estoque Redis 6.2.22, 7.4.9, 8.6.4 e 8.8.0.
Todas as quatro cadeias requerem RESTORE. As cadeias Streams também precisam de EVAL e XGROUP; a cadeia 8.8.0 precisa de EVAL e do módulo RedisBloom incluído. Redis diz que as falhas de memória subjacentes podem levar à execução remota de código.
Redis 6.2.23, 7.2.15 e 7.4.10 corrigem o Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5 e 8.6.5 corrigem o problema de Streams e as gravações fora dos limites do RedisBloom e TDigest; O Redis 8.8.1 corrige os carregadores RedisBloom e TDigest, enquanto a proteção Streams já estava presente no Redis 8.8.0.
Dois alvos PoC, Redis 6.2.22 e 7.4.9, foram as atualizações de segurança de maio que o Redis instruiu os usuários a instalar, mas essas versões não incluíam a proteção de propriedade NACK compartilhada.
Atualize para a versão fixa da ramificação implantada. Até então, revogue RESTORE de contas que não precisam estritamente dele e bloqueie o acesso à rede não confiável. Restringir RESTORE corta ambos os caminhos divulgados.
Nem as notas de lançamento do Redis de 23 de julho nem os repositórios PoC públicos revisados relataram exploração em estado selvagem em 24 de julho de 2026.
Dois caminhos através do RESTORE
O caminho do Redis Streams é um bug de propriedade compartilhada. Um objeto RDB corrompido pode fazer com que dois consumidores apontem para o mesmo registro de entrada pendente, portanto, a remoção de ambos os consumidores libera o mesmo objeto 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 system().
O caminho RedisBloom é uma gravação fora dos limites no carregador RDB TDigest. O carregador alocou memória de um valor serializado, mas confiou em um campo de capacidade separado controlado pelo invasor ao decidir quantos dados carregar.
O script Redis 8.8.0 foi projetado para transformar essa incompatibilidade em primitivas de leitura e gravação, vazar endereços Redis e libc e chamar system().
A cadeia Streams Shared-NACK
O primeiro caminho está em Redis Streams. Um objeto RDB corrompido pode fazer com que dois consumidores apontem 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 segurando um ponteiro pendurado. Os scripts também removem o segundo consumidor. Um pedaço, dois livres.
As notas de lançamento do Redis 8.6.4 citam PR #15081. Mas uma revisão da fonte feita pelo The Hacker News descobriu que a fonte 8.6.4 marcada não possui a verificação de propriedade duplicada adicionada por essa mudança. A guarda aparece no Redis 8.6.5, lançado em 23 de julho.
O script Redis 8.6.4 publicado foi projetado para transformar a liberação dupla em acesso arbitrário à memória e, em seguida, envenenar uma função hash de banco de dados para que um GET criado invoque system(). Ele restaura o ponteiro e verifica se o Redis ainda responde.
A cadeia RedisBloom TDigest
O segundo caminho fica no carregador RedisBloom TDigest RDB. Ele alocou suas matrizes centróides a partir de um valor de compactação serializado e, em seguida, confiou em um campo de capacidade separado controlado pelo invasor ao decidir quantos nós poderiam ser carregados. Uma pequena alocação real combinada com metadados inflacionados produz uma gravação fora dos limites.
O script Redis 8.8.0 foi projetado para transformar a gravação em primitivas de leitura e gravação, vazar endereços Redis e libc e envenenar uma função hash de banco de dados para que um GET criado chame system(). Uma prova de conceito separada publicou a mesma causa raiz e uma cadeia RCE autenticada no Redis 8.8.0.
A correção de julho do Redis exige que a capacidade carregada do TDigest corresponda à alocação derivada do valor de compactação. Ele também limita os contadores de nós mesclados e não mesclados antes de ler as matrizes.
Sete lançamentos, nenhum novo registro CVE
O repositório chama o problema do Streams de parte de uma "família de correção incompleta" CVE-2026-25589, mas o Redis mapeia esse CVE para a corrupção da memória RedisBloom durante o RESTORE, não a falha NACK compartilhada do Streams. As notas de versão de julho do Redis não listam nenhuma pontuação CVE ou CVSS para nenhuma das novas classes de bug.
Em 24 de julho, as pesquisas do The Hacker News não encontraram nenhum registro NVD separado para as descobertas compartilhadas de julho do NACK ou TDigest. O NVD ainda listou os registros de maio para CVE-2026-25243 e CVE-2026-25589. Uma pesquisa no catálogo de vulnerabilidades exploradas conhecidas da CISA não retornou nenhuma entrada para nenhum dos identificadores.
A divulgação segue outra falha do Redis RCE descoberta pela IA e corrigida em maio. Bera Buddies se descreve como “Pesquisa de Agente de IA”. Chaofan Shou disse no X que os agentes Kimi K3 encontraram 19 dias zero do Redis em cerca de 90 minutos, e disse que outra execução produziu a exploração do Redis 8.8.0 em 27 minutos.
Essas contagens, horários e o grau de autonomia alegado permanecem auto-relatados. O registro público do Redis confirma as falhas e correções. Ele não valida a contagem de dia zero reivindicada ou a independência com que os agentes trabalharam.
Redis 6.2.22 e 7.4.9 foram o destino de maio. Em julho, ambos precisavam de outra atualização. Verifique a versão exata do branch, não se o Redis foi
Todas as quatro cadeias requerem RESTORE. As cadeias Streams também precisam de EVAL e XGROUP; a cadeia 8.8.0 precisa de EVAL e do módulo RedisBloom incluído. Redis diz que as falhas de memória subjacentes podem levar à execução remota de código.
Redis 6.2.23, 7.2.15 e 7.4.10 corrigem o Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5 e 8.6.5 corrigem o problema de Streams e as gravações fora dos limites do RedisBloom e TDigest; O Redis 8.8.1 corrige os carregadores RedisBloom e TDigest, enquanto a proteção Streams já estava presente no Redis 8.8.0.
Dois alvos PoC, Redis 6.2.22 e 7.4.9, foram as atualizações de segurança de maio que o Redis instruiu os usuários a instalar, mas essas versões não incluíam a proteção de propriedade NACK compartilhada.
Atualize para a versão fixa da ramificação implantada. Até então, revogue RESTORE de contas que não precisam estritamente dele e bloqueie o acesso à rede não confiável. Restringir RESTORE corta ambos os caminhos divulgados.
Nem as notas de lançamento do Redis de 23 de julho nem os repositórios PoC públicos revisados relataram exploração em estado selvagem em 24 de julho de 2026.
Dois caminhos através do RESTORE
O caminho do Redis Streams é um bug de propriedade compartilhada. Um objeto RDB corrompido pode fazer com que dois consumidores apontem para o mesmo registro de entrada pendente, portanto, a remoção de ambos os consumidores libera o mesmo objeto 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 system().
O caminho RedisBloom é uma gravação fora dos limites no carregador RDB TDigest. O carregador alocou memória de um valor serializado, mas confiou em um campo de capacidade separado controlado pelo invasor ao decidir quantos dados carregar.
O script Redis 8.8.0 foi projetado para transformar essa incompatibilidade em primitivas de leitura e gravação, vazar endereços Redis e libc e chamar system().
A cadeia Streams Shared-NACK
O primeiro caminho está em Redis Streams. Um objeto RDB corrompido pode fazer com que dois consumidores apontem 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 segurando um ponteiro pendurado. Os scripts também removem o segundo consumidor. Um pedaço, dois livres.
As notas de lançamento do Redis 8.6.4 citam PR #15081. Mas uma revisão da fonte feita pelo The Hacker News descobriu que a fonte 8.6.4 marcada não possui a verificação de propriedade duplicada adicionada por essa mudança. A guarda aparece no Redis 8.6.5, lançado em 23 de julho.
O script Redis 8.6.4 publicado foi projetado para transformar a liberação dupla em acesso arbitrário à memória e, em seguida, envenenar uma função hash de banco de dados para que um GET criado invoque system(). Ele restaura o ponteiro e verifica se o Redis ainda responde.
A cadeia RedisBloom TDigest
O segundo caminho fica no carregador RedisBloom TDigest RDB. Ele alocou suas matrizes centróides a partir de um valor de compactação serializado e, em seguida, confiou em um campo de capacidade separado controlado pelo invasor ao decidir quantos nós poderiam ser carregados. Uma pequena alocação real combinada com metadados inflacionados produz uma gravação fora dos limites.
O script Redis 8.8.0 foi projetado para transformar a gravação em primitivas de leitura e gravação, vazar endereços Redis e libc e envenenar uma função hash de banco de dados para que um GET criado chame system(). Uma prova de conceito separada publicou a mesma causa raiz e uma cadeia RCE autenticada no Redis 8.8.0.
A correção de julho do Redis exige que a capacidade carregada do TDigest corresponda à alocação derivada do valor de compactação. Ele também limita os contadores de nós mesclados e não mesclados antes de ler as matrizes.
Sete lançamentos, nenhum novo registro CVE
O repositório chama o problema do Streams de parte de uma "família de correção incompleta" CVE-2026-25589, mas o Redis mapeia esse CVE para a corrupção da memória RedisBloom durante o RESTORE, não a falha NACK compartilhada do Streams. As notas de versão de julho do Redis não listam nenhuma pontuação CVE ou CVSS para nenhuma das novas classes de bug.
Em 24 de julho, as pesquisas do The Hacker News não encontraram nenhum registro NVD separado para as descobertas compartilhadas de julho do NACK ou TDigest. O NVD ainda listou os registros de maio para CVE-2026-25243 e CVE-2026-25589. Uma pesquisa no catálogo de vulnerabilidades exploradas conhecidas da CISA não retornou nenhuma entrada para nenhum dos identificadores.
A divulgação segue outra falha do Redis RCE descoberta pela IA e corrigida em maio. Bera Buddies se descreve como “Pesquisa de Agente de IA”. Chaofan Shou disse no X que os agentes Kimi K3 encontraram 19 dias zero do Redis em cerca de 90 minutos, e disse que outra execução produziu a exploração do Redis 8.8.0 em 27 minutos.
Essas contagens, horários e o grau de autonomia alegado permanecem auto-relatados. O registro público do Redis confirma as falhas e correções. Ele não valida a contagem de dia zero reivindicada ou a independência com que os agentes trabalharam.
Redis 6.2.22 e 7.4.9 foram o destino de maio. Em julho, ambos precisavam de outra atualização. Verifique a versão exata do branch, não se o Redis foi
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #agentes #kimi #k3 #encontraram #redis #zerodays #e #criaram #exploração #rce, #dizem #pesquisadores
💡 Compartilhe e ajude nosso projeto a crescer!
Postar um comentário