CVE-2026-23479: a falha use-after-free de Redis que poderia converter seu servidor em uma porta de execução remota

Um novo exploit para Redis, registrado como CVE-2026-23479, voltou a colocar o foco sobre como falhas sutis em código maduro podem se tornar portas de execução remota em ambientes produtivos. O problema, introduzido no ramo 7.2.0 e presente nos ramos estáveis durante mais de dois anos até os adesivos de 5 de maio, é um clássico use-after-free(CWE-416) na gestão de clientes bloqueados que permite a um atacante com credenciais apropriadas tomar controle do servidor Redis em determinados cenários.

A natureza técnica da falha reside em uma função que desperta comandos bloqueados e reenvia a execução sem verificar se a chamada que processa o comando libertou a estrutura de cliente. Esse acesso posterior à memória já liberada é a porta que abre uma cadeia de exploração de três etapas: fuga de ponteiro de heap via uma chamada EVAL, colocação de uma estrutura de cliente falsa na memória reutilizada, e manipulação da contabilidade de memória para sobrepor um ponteiro de livraria (GOT) e redirigir uma função a system (), conseguindo assim RCE. O exploit publicado demonstra que, com as funções EVAL, CONFIG SET, XREAD/XADD e operações básicas SET/GET— todas contidas em privilégios por defeito—é possível executar comandos arbitrários no host.

As métricas de gravidade não são unívocas: a NVD puntua 8.8 sob CVSS 3.1 ( NVD CVE-2026-23479) enquanto Redis aplica sua própria avaliação com CVSS 4.0 em 7.7, mas o vetor real de risco define a exposição de Redis na nuvem e as configurações por defeito. Análises publicadas por pesquisadores e equipamentos de segurança apontam que uma grande proporção de implantaçãos na nuvem executa Redis sem senha ou com credenciais compartilhadas entre aplicações, o que converte essa falha em um risco prático muito maior do que uma mera pontuação em um CVSS.

Há aspectos de engenharia que merecem atenção editorial: o bug resultou da combinação acidental de duas mudanças separadas em código (ver os pull requests históricos no repositório de Redis, por exemplo PR #11012 e PR #11568), nenhum perigoso por si só. Essa concatenação, e sua permanência após várias revisões de segurança, é uma chamada de atenção sobre as limitações das revisões tradicionais e o valor acrescentado que oferecem análises dinâmicas e fuzzing específicas para memória.

A presença do contêiner oficial de Redis complica o panorama: a imagem Docker oficial deriva em uma redução de mecanismos de proteção em tempo de execução (RELRO parcial), deixando a Global Offset Table modificável em ambiente containerizado e facilitando a etapa final do exploit. Uma vez que o ataque escreve relativamente a uma variável global conhecida em tempo de ligação, mitigações como ASLR/PIE em muitos desdobramentos não bastam por si só.

Acções concretas e priorizadas para administradores: Actualizar imediatamente Às versões alteradas 7.2.14, 7.4.9, 8.2.6, 8.4.3 ou 8.6.3 publicadas em 5 de maio; se não puder corrigir imediatamente, retirar instâncias do acesso público, obrigue TLS, segmente privilégios ACL para que nenhum papel combine @admin, CONFIG e @scripting, e considere negar @scripting se não usar Lua (isto evita a fuga inicial que facilita o exploit). Além disso, rote credenciais compartilhadas, priorize a revisão de instâncias expostas à internet e verifique o calendário de adesivos de seus serviços gerenciados (Redis Cloud e outros podem já ter aplicado correções). Consulte a página oficial de segurança da Redis para avisos e releases: https://redis.io/topics/security.

Também é imprescindível a detecção: procure padrões invulgares como EVAL frequentes desde contas de serviço, alterações de configuração inesperadas (CONFIG SET), uso intensivo ou estranho de streams XADD/XREAD e processos secundários que indiquem execução de comandos do sistema. Para efeitos forenses, recolhemos logs e snapshots de memória quando suspeite compromisso, e analise se há rotações ou acessos invulgares desde contas que antes compartilhavam privilégios elevados.

Finalmente, este achado tem lições mais amplas para a indústria: um erro crítico pode nascer da interação de duas mudanças aparentemente inocuos e permanecer escondido durante anos, e as ferramentas automatizadas – incluindo as de origem AI que caçam padrões de bug em grandes bases de código – já estão jogando um papel real em descobrir vetores sofisticados. A mensagem para equipamentos de desenvolvimento e segurança é clara: priorizar testes de memória, revisões focadas em padrões de liberação/reuso e controles de segurança por defeito menos permissivos reduz a probabilidade de problemas semelhantes chegarem à produção.