Cette vulnérabilité critique permet aux attaques de s’échapper du bac à sable Lua du magasin de données en mémoire et d’exécuter ensuite du code arbitraire sur le serveur sous-jacent.
Le populaire magasin de données en mémoire Redis a reçu un correctif pour une vulnérabilité critique qui conduit à l’exécution de code à distance sur le serveur hébergeant la base de données. Bien que l’exploitation de la faille nécessite une authentification, de nombreuses instances Redis n’ont pas d’authentification configurée et environ 60 000 d’entre elles sont exposées à Internet dans cette configuration.
« Étant donné que Redis est utilisé dans environ 75 % des environnements cloud, l’impact potentiel est considérable », ont déclaré les chercheurs de Wiz qui ont découvert la faille dans un rapport. « Les organisations sont fortement invitées à corriger immédiatement les instances en donnant la priorité à celles qui sont exposées à Internet. »
La vulnérabilité, identifiée comme CVE-2025-49844 ou RediShell, est un bogue de corruption de mémoire utilisée après libération qui existe dans la base de code Redis depuis environ 13 ans. Il a été découvert par les chercheurs de Wiz et utilisé lors du concours Pwn2Own Berlin en mai.
Redis a corrigé la faille, ainsi que trois autres vulnérabilités – CVE-2025-46817, CVE-2025-46818 et CVE-2025-46819 – dans les versions 6.2.20, 7.2.11, 7.4.6, 8.0.4 et 8.2.2, publiées le 3 octobre.
Échapper au bac à sable du script Lua
En plus d’être un magasin de données, Redis permet aux utilisateurs d’exécuter des scripts écrits dans le langage de programmation Lua. Cette fonctionnalité puissante permet aux applications d’exécuter une partie de leur logique liée aux données directement dans la base de données, améliorant ainsi les performances.
Les scripts Lua sont exécutés dans un bac à sable, mais CVE-2025-49844 permet aux attaquants d’échapper à cette contrainte et d’exécuter du code arbitraire directement sur le serveur sous-jacent. Pour cette raison, la vulnérabilité a reçu la note de gravité la plus élevée, soit 10, sur l’échelle CVSS.
Dans l’attaque de preuve de concept démontrée par Wiz, les attaquants exploitent cette vulnérabilité pour lancer un shell inversé qui leur permet d’exécuter des commandes supplémentaires. Cela peut entraîner le vol d’informations d’identification dans l’environnement, telles que les clés SSH, les jetons AWS IAM et les certificats. Cela peut également conduire au déploiement de logiciels malveillants et de cryptomineurs.
Le manque d’authentification Redis est un problème répandu
Si Redis prend en charge l’authentification, il est souvent déployé sans celle-ci, notamment sur les réseaux internes, mais aussi sur internet. Par exemple, les chercheurs de Wiz notent que dans 57 % des environnements cloud, Redis est déployé en tant qu’image de conteneur et que le conteneur Redis officiel sur Docker Hub n’a pas d’authentification activée par défaut.
« La combinaison de l’absence d’authentification et de l’exposition à Internet est très dangereuse, car elle permet à quiconque d’interroger l’instance Redis et, en particulier, d’envoyer des scripts Lua (qui sont activés par défaut) », notent les chercheurs. « Cela permet aux attaquants d’exploiter la vulnérabilité et d’atteindre le RCE dans l’environnement. »
Environ 300 000 instances Redis sont exposées à Internet et on estime que l’authentification n’est pas activée pour 60 000 d’entre elles. Beaucoup d’autres sont probablement déployés sur des réseaux internes sans renforcement supplémentaire de la sécurité, où n’importe quel hôte interne peut s’y connecter.
Les serveurs Redis sont une cible commune, avec d’autres technologies cloud natives, pour les groupes qui déploient des cryptomineurs sur des serveurs. Dans le passé, d’autres vulnérabilités d’évasion du bac à sable Redis Lua, telles que CVE-2022-0543, qui affectaient spécifiquement le paquet Debian Redis, étaient exploitées par des vers peer-to-peer.
