Des chercheurs de Wiz ont découvert une faille sévère dans les instances de Redis aboutissant à l’exécution de code à distance. L’éditeur de la base de données en mémoire vient de livrer un correctif à appliquer rapidement.
A l’occasion du Pwn2own de Berlin qui s’est déroulé mai dernier, des chercheurs de Wiz (racheté par Google) ont découvert et utilisé une vulnérabilité critique pour pirater les instances Redis. Référencée CVE-2025-49844 ou identifiée sous l’appellation RediShell, la faille est un bug de corruption de mémoire « use-after-free » présent dans le code source de Redis depuis 13 ans environ.
Les experts de Wiz soulignent l’importance de cette brèche de sécurité. « Étant donné que Redis est utilisé dans près de 75 % des environnements cloud, l’impact potentiel est considérable », expliquent-ils. Tout en estimant qu’environ 60 000 instances exposées sur Internet sont vulnérables. Redis vient de corriger cette faille, ainsi que trois autres référencées 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.
Contournement du bac à sable Lua
Pour expliquer la faille, il faut savoir qu’en plus d’être un data store, Redis sert à exécuter des scripts écrits dans le langage de programmation Lua. Cette fonctionnalité propose aux applications d’exécuter certaines de leurs logiques liées aux données directement dans la base de données. Les scripts tournent dans un bac à sable, mais la faille CVE-2025-49844 permet aux attaquants de contourner 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 de 10 sur l’échelle CVSS. Dans le PoC démontré par Wiz, les pirates exploitent cette vulnérabilité pour lancer un shell inversé et ainsi exécuter des commandes supplémentaires. L’attaque peut conduire au vol d’identifiants dans l’environnement, en particulier des clés SSH, des jetons AWS IAM et des certificats. Elle peut également conduire au déploiement de logiciels malveillants et des mineurs de cryptomonnaies.
Une absence d’authentification très répandue
Les chercheurs pointent du doigt la façon dont les utilisateurs déploient Redis sans authentification en interne, mais aussi de manière visible sur Internet. Par exemple, ils ont noté que dans 57% des environnements cloud, Redis est mis en place sous forme d’image de conteneur et que le conteneur Redis officiel sur Docker Hub n’a pas d’authentification activée par défaut. « L’absence d’authentification combinée à l’exposition à Internet est extrêmement dangereuse, car elle donne la possibilité à n’importe qui d’interroger l’instance Redis et, plus précisément, d’envoyer des scripts Lua (qui sont activés par défaut) », ont fait remarquer les chercheurs. Ils ajoutent « les pirates peuvent donc exploiter la vulnérabilité et exécuter du code à distance (Remote Code Execution, RCE) dans l’environnement. »
Environ 300 000 instances Redis sont exposées à Internet et on estime que 60 000 d’entre elles ne disposent pas d’authentification. Beaucoup d’autres sont probablement déployées 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 courante, au même titre que d’autres technologies natives du cloud, pour les groupes qui déploient des cryptomineurs sur des serveurs. Dans le passé, d’autres vulnérabilités d’échappement du bac à sable Redis Lua, comme la vulnérabilité CVE-2022-0543 affectant spécifiquement le paquet Debian Redis, ont été exploitées par des vers diffusés par les protocoles peer-to-peer.