### Une menace RCE découverte par IA pèse sur les déploiements Redis Une vulnérabilité critique d'exécution de code à distance (RCE), référencée **CVE-2026-23479**, a été corrigée dans le populaire magasin de données en mémoire open-source, **Redis**. Cette faille use-after-free permet à un attaquant authentifié d'exécuter des commandes arbitraires du système d'exploitation sur la machine hébergeant la base de données, présentant un risque de sécurité important pour les systèmes affectés. La vulnérabilité a été découverte de manière unique par **Xint Code**, un outil de sécurité IA autonome développé par **Theori** et rapporté par **Team Xint Code**. Cela met en évidence le paysage évolutif de la recherche de vulnérabilités, où l'IA joue de plus en plus un rôle dans l'identification de bugs complexes dans de grandes bases de code.  ### La vulnérabilité : CVE-2026-23479 expliquée Le bug use-after-free réside dans la fonction `unblockClientOnKey()` dans `src/blocked.c`, qui est déclenchée lorsqu'un événement de clé réveille une commande bloquée. La fonction distribue la commande mise en file d'attente via `processCommandAndResetClient()`. De manière cruciale, `processCommandAndResetClient()` peut, comme effet secondaire, libérer le pointeur client qu'il reçoit. Cependant, l'appelant `unblockClientOnKey()` continue ensuite d'utiliser ce pointeur client maintenant libéré, conduisant à une condition use-after-free classique (CWE-416). Cette faille a été introduite dans **Redis** 7.2.0 et est restée présente dans toutes les branches stables jusqu'à sa correction le 5 mai, étant passée inaperçue pendant plus de deux ans. La National Vulnerability Database (NVD) la note 8.8 sous CVSS 3.1, tandis que **Redis** lui-même la classe 7.7 sous CVSS 4.0. Une analyse technique détaillée a été rendue publique par **Wiz**. ### Comment l'exploit se déroule La chaîne d'exploit, démontrée par **Team Xint Code** lors de la compétition ZeroDay.Cloud 2025 de **Wiz**, est sophistiquée et implique plusieurs étapes : 1. **Fuite d'adresse du tas** : Un script Lua d'une seule ligne (`EVAL "return tostring(redis.call)" 0`) est utilisé pour fuir un pointeur du tas. 2. **Manipulation de mémoire et injection de faux client** : L'attaquant manipule les limites de mémoire du client, place un client volumineux sur un flux, puis réduit les limites et le réveille. Cela amène **Redis** à libérer le client bloqué en plein appel. Une commande `SET` pipelinée récupère immédiatement l'emplacement mémoire libéré avec une structure de faux client conçue. 3. **Écrasement du pointeur de fonction** : La comptabilité mémoire de routine de **Redis** dans `updateClientMemoryUsage()` est ensuite utilisée pour effectuer un décrément hors limites à l'aide de champs contrôlés par l'attaquant. Cela cible la Global Offset Table (GOT) pour rediriger le pointeur de fonction `strcasecmp()` vers `system()`. La commande suivante analysée par **Redis** est alors exécutée comme une commande shell. L'image **Redis Docker** par défaut simplifie encore l'étape finale en ne fournissant qu'un RELRO partiel, laissant la GOT inscriptible à l'exécution. ### Prérequis et exposition dans le cloud L'exploitation de **CVE-2026-23479** nécessite une session authentifiée avec des catégories ACL spécifiques : `@admin`, `CONFIG SET`, `EVAL`, commandes de flux (`XREAD`/`XADD`), et `SET`/`GET` de base. Bien que cela puisse sembler restrictif, dans de nombreux déploiements **Redis** par défaut, l'utilisateur par défaut possède tous ces privilèges. L'analyse de **Wiz** met en évidence une préoccupation majeure : une grande majorité des instances **Redis** dans les environnements cloud fonctionnent sans mot de passe. Cette configuration généralisée augmente considérablement la surface d'attaque, car un attaquant n'a besoin que d'obtenir un accès initial à l'instance **Redis** pour potentiellement obtenir une RCE.  ### Action immédiate requise : Patching et atténuation **Redis** a publié des correctifs pour cette vulnérabilité, et des mises à niveau immédiates sont fortement recommandées. Les branches affectées et leurs versions corrigées correspondantes sont : | Branche | Versions affectées | Version corrigée | | :------ | :------------------ | :------------ | | 7.2.x | 7.2.0 à 7.2.13 | 7.2.14 | | 7.4.x | 7.4.0 à 7.4.8 | 7.4.9 | | 8.2.x | 8.2.0 à 8.2.5 | 8.2.6 | | 8.4.x | 8.4.0 à 8.4.2 | 8.4.3 | | 8.6.x | 8.6.0 à 8.6.2 | 8.6.3 | Les mises à niveau mineures au sein d'une série sont conçues pour être des remplacements directs. Les services **Redis** gérés déploient les correctifs selon leurs propres calendriers, **Redis Cloud** étant déjà mis à jour. Si le patching immédiat n'est pas réalisable, mettez en œuvre les atténuations suivantes : * **Segmentation réseau** : Gardez les instances **Redis** hors de l'Internet public et derrière des pare-feux robustes. * **Chiffrement TLS** : Assurez-vous que toutes les communications **Redis** sont sécurisées avec TLS. * **ACL strictes** : Renforcez les listes de contrôle d'accès (ACL) pour empêcher tout rôle unique de détenir simultanément les privilèges `@admin`, `CONFIG`, et `@scripting`. * **Désactiver le scripting Lua** : S'il n'est pas activement utilisé, refusez la catégorie ACL `@scripting`, ce qui empêche la fuite du tas de l'étape 1. * **Rotation des identifiants** : Faites pivoter tous les identifiants **Redis** largement partagés. Priorisez le patching et l'atténuation pour les instances exposées sur Internet, celles avec des identifiants d'application partagés, et tous les rôles qui combinent `CONFIG`, le scripting et l'accès aux flux. ### Un contexte plus large **CVE-2026-23479** est l'une des cinq failles RCE de **Redis** divulguées le mois dernier, et elle fait suite à la faille **RediShell** de 2025, une autre use-after-free authentifiée impliquant le scripting Lua. Le fait qu'un outil IA, plutôt qu'une revue de code traditionnelle, ait identifié cette vulnérabilité de longue date souligne la nécessité d'une innovation continue en matière de sécurité et de méthodologies de test robustes dans les logiciels critiques. Bien qu'il n'y ait aucune preuve publique d'exploitation en cours, les détails techniques complets sont désormais publics, ce qui augmente considérablement le risque.