captain-woof/cve-2026-25243POC stable pour CVE-2026-25243 (double-free RESTORE Redis -> exécution de code à distance)
Vérifié sur Rocky Linux 8.10, aarch64, Redis 8.6.2, jemalloc 5.3.0.
Référence : https://www.zeroday.cloud/blog/redis-cve-2026-25243-deep-dive
TLDR ; Exploit stable, fonctionne avec une grande variété de distributions et d'architectures OS.
Qu'est-ce que c'est ? Une vulnérabilité de corruption mémoire dans Redis qui permet à un attaquant authentifié d'exécuter des commandes arbitraires en tant qu'utilisateur Redis. L'attaque est réelle et ne nécessite qu'une seule commande RESTORE — une opération Redis normale, pas réservée à l'admin. Cet exploit démontre une RCE complète en moins d'une seconde.
Impact ? N'importe quel client Redis authentifié peut la déclencher, et les dégâts sont totaux : exécution de code arbitraire dans le processus Redis (souvent exécuté en root dans les conteneurs). Il n'existe aucun moyen d'atténuation sans corriger Redis lui-même.
Comment ça fonctionne en un coup d'œil ? Redis dispose d'une fonctionnalité de sérialisation (RESTORE) qui prend un blob de données binaires et le reconstruit en tant qu'objet Redis. Le code qui valide le format du blob et le code qui le désérialise ne sont pas d'accord sur la façon d'analyser certaines séquences — un bug que l'attaquant exploite pour corrompre le tas (heap). Une fois le tas corrompu, l'attaquant obtient la capacité de lire et d'écrire n'importe quelle adresse mémoire dans le processus Redis, puis détourne l'état interne du serveur pour exécuter une commande shell.
La véritable technique de l'exploit : Il ne s'agit pas d'un simple crash. C'est une chaîne d'exploitation du tas : corruption → chevauchement → R/W arbitraire → fuite d'informations → localisation de la structure du serveur → détournement des pointeurs de fonction → RCE. L'exploit s'exécute en 9 étapes et nécessite de fuiter plusieurs adresses à l'exécution, d'analyser des structures binaires et de détecter l'aliasing mémoire. Ce qui le fait fonctionner sur plusieurs architectures (x86-64, aarch64, etc.), c'est que toutes les adresses sont fuitées depuis la cible elle-même, et non supposées.
CVE-2026-25243 est une paire de bugs de double-free exploitables depuis une seule commande RESTORE authentifiée. RESTORE key ttl <serialized-value> désérialise un blob RDB contrôlé par l'attaquant ; les deux bugs se situent dans l'écart entre le validateur qui vérifie le blob et le convertisseur qui le matérialise.
Bug 1 — conversion zipmap legacy (CWE-415, le chemin utilisé par cet exploit).
Le validateur zipmap (zipmapValidateIntegrity()) et le convertisseur (zipmapNext()) ne sont pas d'accord sur un encodage de longueur redondant. La petite longueur 4 peut légalement être écrite sous la forme longue de cinq octets FE 04 00 00 00. Le validateur consomme un certain nombre d'octets, le convertisseur un autre — une désynchronisation d'analyse de 4 octets. Le convertisseur parcourt donc une structure différente de celle qui a été validée, lpSafeToAdd() échoue après que le champ a déjà été inséré dans le dictionnaire, et le chemin de nettoyage libère le champ deux fois : une fois via dictRelease() puis à nouveau via sdsfree().
Bug 2 — chargement du PEL des consommateurs de stream (CWE-415). Dans rdbLoadStreamConsumersGroup(), un PEL de consommateur contenant un ID d'entrée en double fait échouer le second raxTryInsert(), qui appelle streamFreeNACK() sur un streamNACK toujours possédé par le PEL global du groupe. Libéré deux fois. (Sélectionnable avec --vuln-type stream.)
Chacun de ces bugs offre à l'attaquant un bloc de mémoire à la fois libre et référencé — le point de départ classique d'un exploit par chevauchement de tas.
Impact : un client Redis authentifié (sans droits admin, RESTORE est une commande de données normale) obtient l'exécution de code arbitraire en tant qu'utilisateur redis — root dans l'image de conteneur par défaut.
Neuf étapes, chacune transformant une primitive plus faible en une primitive plus forte :
| Étape | Primitive obtenue | Mécanisme |
|---|---|---|
| 0 | profil de la cible | INFO server / INFO memory → version, arch, distribution, pid, chemin de l'exécutable, heure de démarrage, allocateur |
| 1 | double-free | RESTORE zipmap (ou stream) malformé |
| 2 | deux clés partageant la mémoire | pulvériser des clés marqueurs sur le bloc libéré, détecter l'aliasing, puis écraser l'en-tête SDS d'une clé via son jumeau pour la gonfler en « memview » de 1 Mo |
| 3 | R/W arbitraire | trouver un objet INCRBYFLOAT dans la memview, détourner son champ ptr : GETRANGE/SETRANGE sur cette clé lit/écrit désormais n'importe quelle adresse |
| 4 | pointeur d'image | scanner le tas à rebours pour trouver une valeur dans l'image redis-server |
| 5 | &server | descendre jusqu'à l'en-tête ELF, analyser les en-têtes de programme, extraire le segment inscriptible, faire correspondre server.pid |
| 6 | payload en mémoire | écrire "/bin/sh", "-c", "<cmd>" plus un tableau argv dans la memview |
| 7 | structure détournée | écraser server.executable, server.exec_argv et 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'
Vérification :
cat /tmp/pwned123.txt
# uid=0(root) gid=0(root) groups=0(root)
Point de départ : l'exploit était exclusivement x86-64 et échouait à l'étape 3 sur la cible aarch64. État final : RCE complète sur aarch64 Rocky Linux 8.10 en moins d'une seconde, 116 commandes Redis.
a) Empreinte de la cible à l'exécution (nouveau, étape 0). Plus rien n'est supposé sur la cible. INFO server + INFO memory fournissent la version de Redis, l'architecture CPU (à partir de la ligne os:), la famille de distribution (déduite de gcc_version), l'allocateur et — surtout — trois ancres de validation : process_id, executable et le stat_starttime exact (server_time_usec/1e6 - uptime_in_seconds). Les étapes suivantes comparent leurs résultats à ces valeurs au lieu de deviner.
b) Disposition mémoire indépendante de l'architecture. Les quatre constantes x86-64 codées en dur (BINARY_ADDR_MIN/MAX, HEAP_ADDR_MIN/MAX) sont remplacées par un tableau par architecture (ARCH_PROFILES) couvrant x86_64, aarch64 (VA de 39 et 48 bits), riscv64, ppc64le et s390x, avec à la fois les emplacements ET_EXEC et ET_DYN pour chacune, plus un large repli générique pour tout ce qui n'est pas listé. C'était la raison réelle de l'échec de l'exploit sur cette cible : le pointeur fuité 0x0000ffff8a5fdf32 est une adresse mmap aarch64 parfaitement valide que la vérification de plage x86-64 rejetait.
c) Validation des fuites par consensus (étape 3). Plutôt que de se fier à une fenêtre de tas codée en dur, l'analyse collecte désormais tous les objets structurellement valides 1337.NNNNNN dans la memview et exige qu'au moins deux d'entre eux aboutissent à la même adresse de base de la memview (ptr - offset_of_value). En pratique, 502 candidats concordent, une preuve qu'aucun tableau de plages ne peut offrir. Le pointeur confirmé calibre ensuite la fenêtre de tas à l'exécution. La validation du format a également été déplacée avant le test de contrôle d'écriture (coûteux en allers-retours).