captain-woof/cve-2026-25243POC estável para CVE-2026-25243 (Redis RESTORE double-free -> execução remota de código)
Verificado contra Rocky Linux 8.10, aarch64, Redis 8.6.2, jemalloc 5.3.0.
Referência: https://www.zeroday.cloud/blog/redis-cve-2026-25243-deep-dive
TLDR; Exploit estável, funciona contra uma variedade de distribuições de SO e arquiteturas.
O que é isto? Uma vulnerabilidade de corrupção de memória no Redis que permite a um atacante autenticado executar comandos arbitrários como o usuário Redis. O ataque é do mundo real e requer apenas um único comando RESTORE — uma operação normal do Redis, não restrita a administradores. Este exploit demonstra RCE completo em menos de um segundo.
Impacto? Qualquer cliente Redis autenticado pode acioná-la, e o dano é total: execução arbitrária de código no processo Redis (frequentemente executando como root em contêineres). Não há como mitigar sem aplicar patch no próprio Redis.
Como funciona em resumo? O Redis tem um recurso de serialização (RESTORE) que pega um blob de dados binários e o reconstrói como um objeto Redis. O código que valida o formato do blob e o código que o desserializa discordam sobre como analisar certas sequências — uma falha que o atacante explora para corromper a heap. Uma vez que a heap é corrompida, o atacante ganha a capacidade de ler e escrever qualquer endereço de memória no processo Redis e, a partir daí, sequestra o estado interno do servidor para executar um comando shell.
A técnica real do exploit: Isto não é um simples crash. É uma cadeia de exploração de heap: corromper → sobrepor → R/W arbitrário → vazamento de informações → encontrar a struct do servidor → sequestrar ponteiros de função → RCE. O exploit executa 9 estágios e exige vazar múltiplos endereços em tempo de execução, analisar estruturas binárias e detectar aliasing de memória. O que o faz funcionar em diferentes arquiteturas (x86-64, aarch64, etc.) é que todos os endereços são vazados do próprio alvo, não presumidos.
CVE-2026-25243 é um par de bugs de double-free alcançáveis a partir de um único comando RESTORE autenticado. RESTORE key ttl <serialized-value> desserializa um blob RDB controlado pelo atacante; ambos os bugs vivem na lacuna entre o validador que verifica o blob e o conversor que o materializa.
Bug 1 — conversão zipmap legada (CWE-415, o caminho que este exploit usa). O validador zipmap (zipmapValidateIntegrity()) e o conversor (zipmapNext()) discordam sobre uma codificação de comprimento redundante. O comprimento pequeno 4 pode ser legalmente escrito na forma longa de cinco bytes FE 04 00 00 00. O validador consome um número de bytes, o conversor outro — uma dessincronização de análise de 4 bytes. O conversor portanto percorre uma estrutura diferente daquela que foi validada, lpSafeToAdd() falha depois que o campo já foi inserido no dicionário, e o caminho de limpeza libera o campo duas vezes: uma via dictRelease() e outra via sdsfree().
Bug 2 — carregamento do PEL do consumidor de stream (CWE-415). Em rdbLoadStreamConsumersGroup(), um PEL de consumidor contendo um ID de entrada duplicado faz a segunda chamada raxTryInsert() falhar, o que chama streamFreeNACK() em um streamNACK que ainda é de propriedade do PEL global do grupo. Liberado duas vezes. (Selecionável com --vuln-type stream.)
Qualquer um dos bugs entrega ao atacante um pedaço de memória que está simultaneamente livre e referenciado — o ponto de partida clássico para um exploit de sobreposição de heap.
Impacto: um cliente Redis autenticado (sem direitos de administrador, RESTORE é um comando de dados normal) obtém execução arbitrária de código como o usuário redis — root na imagem de contêiner padrão.
Nove estágios, cada um dos quais transforma uma primitiva mais fraca em uma mais forte:
| Estágio | Primitiva obtida | Mecanismo |
|---|---|---|
| 0 | perfil do alvo | INFO server / INFO memory → versão, arquitetura, distribuição, pid, caminho do executável, hora de início, alocador |
| 1 | double free | zipmap malformado (ou stream) RESTORE |
| 2 | duas chaves compartilhando memória | espalhar chaves marcadoras sobre o pedaço liberado, detectar aliasing, então sobrescrever o cabeçalho SDS de uma chave através de sua gêmea para inflá-lo para uma "memview" de 1 MB |
| 3 | R/W arbitrário | encontrar um objeto INCRBYFLOAT dentro da memview, sequestrar seu campo ptr: GETRANGE/SETRANGE nessa chave agora lê/escreve qualquer endereço |
| 4 | ponteiro de imagem | escanear a heap de trás para frente em busca de um valor dentro da imagem do redis-server |
| 5 | &server | descer até o cabeçalho ELF, analisar os program headers, despejar o segmento gravável, corresponder a server.pid |
| 6 | payload na memória | escrever "/bin/sh", "-c", "<cmd>" mais um array argv na memview |
| 7 | struct sequestrada | sobrescrever server.executable, server.exec_argv e server.enable_debug_cmd |
| 8 | RCE | DEBUG CRASH-AND-RECOVER → restartServer() → execve(server.executable, server.exec_argv, environ) |
python3 exploit.py --host 127.0.0.1 --port 6379 \
--password mypassword --cmd 'id > /tmp/pwned123.txt'
Verifique:
cat /tmp/pwned123.txt
# uid=0(root) gid=0(root) groups=0(root)
Ponto de partida: o exploit era exclusivo para x86-64 e morria no estágio 3 no alvo aarch64. Estado final: RCE completo em aarch64 Rocky Linux 8.10 em menos de um segundo, 116 comandos Redis.
a) Identificação de impressão digital do alvo em tempo de execução (novo, estágio 0). Nada sobre o alvo é mais presumido. INFO server + INFO memory fornecem a versão do Redis, a arquitetura da CPU (da linha os:), a família da distribuição (inferida de gcc_version), o alocador e — o mais importante — três âncoras de validação: process_id, executable e o stat_starttime exato (server_time_usec/1e6 - uptime_in_seconds). Estágios posteriores comparam com essas em vez de adivinhar.
b) Layout de memória independente de arquitetura. As quatro constantes x86-64 fixas (BINARY_ADDR_MIN/MAX, HEAP_ADDR_MIN/MAX) são substituídas por uma tabela por arquitetura (ARCH_PROFILES) que cobre x86_64, aarch64 (VA de 39 e 48 bits), riscv64, ppc64le e s390x, com ambas as disposições ET_EXEC e ET_DYN para cada uma, além de um amplo fallback genérico para qualquer item não listado. Esse foi o motivo real da falha do exploit neste alvo: o ponteiro vazado 0x0000ffff8a5fdf32 é um endereço mmap aarch64 perfeitamente válido que a verificação de faixa do x86-64 rejeitou.
c) Validação de vazamento baseada em consenso (estágio 3). Em vez de confiar em uma janela de heap fixa, a varredura agora coleta todos os objetos estruturalmente válidos 1337.NNNNNN na memview e exige que pelo menos dois deles derivem o mesmo endereço base da memview (ptr - offset_of_value). Na prática, 502 candidatos concordam, o que é uma prova que nenhuma tabela de faixas pode oferecer. O ponteiro confirmado então calibra a janela de heap em tempo de execução. A validação de formato também foi movida para antes do teste de controle de escrita (caro em round-trips).
d) Limite da varredura do estágio 3 (correção de bug). A varredura ia até os 10 MB fixos enquanto a memview tem 1 MB, então lia além do final, obtinha uma resposta vazia e abortava com AssertionError: Empty data from memview. Agora ela é limitada pelo STRLEN real da memview, lê 256 KB por round-trip em vez de 64 KB, e o inútil loop de retry-sleep de 6×1s foi removido.