Redis corrige RCE crítico CVE-2026-23479 que ficou dois anos invisível e foi achado por ferramenta autônoma de IA

A Redis publicou em 4 de junho cinco avisos de segurança para o servidor de cache mais usado em aplicações corporativas, com destaque para a CVE-2026-23479, falha de execução remota de código no caminho de desbloqueio de clientes. O bug recebeu CVSS 3.1 de 8.8 e CVSS 4.0 de 7.7, e estava presente desde a versão 7.2.0, lançada em agosto de 2023. Passou mais de dois anos sem ser detectado.

A descoberta veio de uma ferramenta autônoma de bug bounty assistida por IA, segundo a Team Xint Code, que demonstrou uma cadeia completa de exploração. A função vulnerável é a unblockClientOnKey(), em src/blocked.c. A lógica que reexecuta comandos bloqueados não trata erro de processCommandAndResetClient e segue usando um ponteiro de cliente já liberado. O exploit publicado começa com um script Lua que vaza um ponteiro de heap, manipula a memória do cliente para forçar o use-after-free e termina sobrescrevendo um ponteiro de função na Global Offset Table para redirecionar a execução para system().

A exploração não é trivial, mas o impacto é

A exploração exige sessão autenticada contra o servidor Redis e a capacidade de emitir comandos bloqueantes como BLPOP ou XREAD. Em ambientes corretamente segmentados isso limita o vetor a atacantes que já têm credenciais válidas. Para Cassio Goldschmidt, ex-líder de produto de segurança da Symantec hoje em uma consultoria de application security, esse é um cenário comum em ataques pós-acesso inicial, em que o atacante já obteve credencial de aplicação por phishing ou por chave AWS exposta em repositório.

Na maioria das implantações de produção, o Redis fica em redes internas e é acessado por contas de serviço com permissões amplas. Versões afetadas vão de 7.2.x a 8.6.x, o que cobre praticamente todo Redis em produção que recebeu atualização desde 2023. As versões corrigidas são 7.2.14, 7.4.9, 8.2.6, 8.4.3 e 8.6.3.

Outras quatro CVEs no mesmo aviso

Além da CVE-2026-23479, a Redis tratou no mesmo aviso CVE-2026-25243, CVE-2026-25588, CVE-2026-25589 e CVE-2026-23631. Nenhuma chega ao mesmo CVSS, mas três delas também afetam o servidor principal e exigem patch coordenado. A combinação faz da janela atual um dos eventos de remediação mais relevantes do ano para times de plataforma, comparável ao aviso da Atlassian de janeiro, que afetou Confluence Data Center.

A forma como a vulnerabilidade foi achada importa tanto quanto a falha em si. O fluxo unblockClientOnKey é exatamente o tipo de caminho de borda que escapa de auditoria humana: depende de uma sequência incomum de comandos, de timing entre threads e de tratamento de erro pouco exercitado em fuzzers tradicionais. O grupo da Xint Code descreve em seu writeup uma execução autônoma que cobriu meses de auditoria em horas. "O custo marginal de auditar código aberto caiu de forma desproporcional para quem opera essas ferramentas", escreveu a equipe.

O que muda para os times de plataforma

A Redis Inc. distribui o servidor core sob licença RSAL e SSPL desde 2024, mas a maior parte das instalações corporativas roda imagens construídas internamente ou pacotes mantidos por times de plataforma. Isso significa que o ciclo de remediação não passa por um vendor única vez; cada cluster precisa ser atualizado por seu próprio time, na velocidade do seu próprio change management. Para Goldman Sachs, Itaú, UBS e qualquer banco que mantém centenas de instâncias Redis para cache de sessões e filas de processamento, isso é semanas de janela aberta.

A implicação operacional aparece em três frentes. Operadores de SaaS B2B com Redis multi-tenant precisam patchear antes que credenciais comprometidas de um cliente virem RCE no host inteiro. Times de plataforma em bancos e varejo precisam acelerar o release de imagens corrigidas, sob o desafio conhecido de que BLPOP e XREAD são primitivas de filas amplamente usadas em produção. Provedores gerenciados, incluindo AWS ElastiCache, Google Memorystore e Azure Cache for Redis, ainda não publicaram cronograma público de aplicação automática, e clientes que rodam versões self-managed estão por conta própria.

O caso oferece um dado novo para CISOs que estão escolhendo onde colocar seus orçamentos de ferramentas autônomas de segurança. A Team Xint Code mostrou que o caminho é viável para descoberta de zero-day em código maduro. O contraponto pertinente, levantado por Tavis Ormandy no Google Project Zero ao longo de 2025, é que essas ferramentas ainda precisam de validação humana significativa antes de virar relatório aceito por upstream. A próxima semana mostrará se outros mantenedores recebem o mesmo tipo de divulgação coordenada da Xint para outros projetos críticos.