Uma vulnerabilidade batizada de DarkReplica (CVE-2026-23631) permite que atacantes autenticados executem código arbitrário em servidores Redis ao explorar uma falha use-after-free no subsistema de replicação. A vulnerabilidade, descoberta pelo pesquisador Yoni Sherez durante a competição ZeroDay In the Cloud 2025, foi corrigida em 5 de maio de 2026 com patches para todas as versões suportadas do banco de dados em memória.
Como o ataque funciona
O ataque explora a interação entre o mecanismo de replicação do Redis e seu engine de execução Lua. O Redis suporta dois modelos de execução de scripts Lua: o legado (EVAL/EVALSHA) e o mais recente functions engine (FUNCTION LOAD/FCALL). Este último é central na exploração porque funções registradas por ele são persistentes e sincronizadas entre nós do cluster.
O atacante precisa de credenciais válidas de autenticação no servidor Redis. Com isso, ele executa o comando SLAVEOF para forçar a instância-alvo a se tornar réplica de um servidor controlado pelo atacante. A partir daí, ele manipula o processo de sincronização para acionar um comportamento inseguro na engine de funções Lua.
O Redis usa uma arquitetura single-threaded. Para evitar que scripts longos bloqueiem o servidor, há um mecanismo de hook Lua que verifica timeouts e processa eventos pendentes via processEventsWhileBlocked(). A falha está numa omissão: enquanto a maioria dos comandos de cliente é restrita durante a execução de um script, o tráfego de replicação do servidor controlador continua sendo processado sem validar se uma função Lua está em execução.
Detalhes técnicos da exploração
O atacante executa uma função Lua deliberadamente lenta — como um loop infinito — e então dispara um FULLRESYNC a partir do servidor malicioso. Durante a sincronização, o Redis limpa os contextos de função usando functionsLibCtxClearCurrent(), que libera o objeto global lua_State. Quando o controle retorna à função Lua ainda em execução, ela continua operando sobre memória já liberada — uma condição clássica de use-after-free.
Para obter execução de código, o atacante manipula o heap — o Redis usa jemalloc — por meio de primitivas Lua como tostring() para vazar endereços e alocações controladas para reconquistar regiões de memória liberadas. Um caminho confiável de exploração envolve sobrescrever o ponteiro lua_State->l_G->frealloc, redirecionando-o para system() com argumento controlado, alcançando execução de comandos no contexto do processo Redis.
Essa cadeia de exploração demonstra como a convergência entre replicação e execução de scripts em bancos de dados em memória pode criar superfícies de ataque não óbvias. Falhas semelhantes que permitem execução remota de código em plataformas de infraestrutura têm se tornado alvos recorrentes de pesquisadores de segurança.
Versões afetadas e patches
O Redis lançou correções em 5 de maio de 2026 para todas as versões suportadas. A tabela abaixo resume as versões impactadas e suas respectivas correções:
| Versão afetada | Versão corrigida |
|---|---|
| 7.2.0 até 7.2.13 | 7.2.14 |
| 7.4.0 até 7.4.8 | 7.4.9 |
| 8.2.0 até 8.2.5 | 8.2.6 |
| 8.4.0 até 8.4.2 | 8.4.3 |
| 8.6.0 até 8.6.2 | 8.6.3 |
A vulnerabilidade recebeu pontuação CVSS 6.1 (média). Apesar da classificação moderada, o impacto real pode ser crítico em ambientes de produção onde o Redis é usado como camada de cache, fila de mensagens ou store de sessões — cenários comuns em arquiteturas cloud-native e microserviços. O acesso ao servidor Redis pode servir como ponto de pivô para movimentação lateral e escalada de privilégios na infraestrutura.
Como mitigar o risco
Organizações que executam instância própria do Redis devem adotar as seguintes medidas de forma imediata:
- Aplicar os patches released em maio de 2026 — atualizar para 7.2.14, 7.4.9, 8.2.6, 8.4.3 ou 8.6.3, conforme a branch em uso.
- Restringir comandos de replicação — desabilitar ou limitar o uso de SLAVEOF/REPLICAOF apenas a conexões administrativas confiáveis.
- Isolar o Redis em rede privada — nunca expor instâncias Redis diretamente à internet. Use VPNs ou túneis SSH para acesso remoto.
- Desabilitar funções Lua desnecessárias — se o uso de Lua não for requisito da aplicação, desative o functions engine para reduzir a superfície de ataque.
- Monitorar logs de replicação — configurar alertas para eventos inesperados de FULLRESYNC ou mudanças de role (master para slave) em ambientes de produção.
- Usar autenticação forte e rotação de credenciais — a exploração exige autenticação prévia. Implemente ACLs granulares e rote senhas regularmente.
Para instâncias gerenciadas em provedores de nuvem (AWS ElastiCache, Azure Cache for Redis, Google Cloud Memorystore), verifique se o provedor já aplicou os patches automaticamente ou se é necessária uma atualização manual da versão.