🧨 RediShell — la faille qui expose des dizaines de milliers de Redis

Un défaut critique dans le moteur de scripting Lua embarqué dans Redis — surnommé RediShell et suivi sous CVE-2025-49844 — a déclenché une alerte générale début octobre 2025. Il s’agit d’un use-after-free dans l’implémentation du ramasse-miette Lua qui, dans certaines conditions, permet à un script Lua spécialement forgé d’échapper au sandbox et d’exécuter du code natif sur l’hôte. Redis a publié un correctif (version 8.2.2) et la vulnérabilité reçoit la note maximale sur l’échelle CVSS. Redis

⚙️ Mécanique de l’attaque — pas à pas

1. Prérequis : accès authentifié. L’attaque exige que l’adversaire puisse exécuter un script Lua sur l’instance Redis — typiquement via EVAL/EVALSHA. Cela nécessite un accès réseau au service Redis avec des identifiants valides ou une ACL permissive. Dans de nombreux environnements mal configurés, Redis est exposé ou protégé par des mots de passe faibles. NVD
2. Livraison du payload Lua. L’attaquant envoie un script Lua spécialement conçu qui manipule la politique de libération mémoire du moteur Lua (garbage collector). Le script provoque une situation où un objet est libéré mais une référence est encore utilisée — le classique use-after-free. wiz.io
3. Évasion du sandbox. La corruption mémoire permet de corrompre des structures internes du runtime Lua et d’obtenir l’exécution d’instructions arbitraires hors du contexte Lua — autrement dit : RCE (Remote Code Execution). Une fois la RCE obtenue, l’attaquant peut déposer des backdoors, voler des clés, ou pivoter vers d’autres ressources du réseau. ZeroPath

🔥 Exploitation active et portée

Des scans publics et des rapports du secteur évoquent des dizaines à plusieurs centaines de milliers d’instancespotentiellement vulnérables selon la méthode de comptage (exposition publique, instances mal configurées, etc.). Certains articles citent un chiffre d’environ 60 000 instances à risque — mais ce nombre varie selon les sources et la méthode de mesure. Plus préoccupant : des preuves d’exploitation active ont été observées peu après la divulgation, avec des laboratoires et chercheurs publiant des preuves de concept et des environnements de test. En clair : la vulnérabilité est activement exploitée et provoque une fenêtre d’urgence opérationnelle. infosecurity-magazine.com

🕵️‍♂️ Indicateurs de compromission (IoC) à rechercher

• Logs Redis montrant des appels EVAL/EVALSHA depuis des IP externes ou inhabituelles.
• Scripts Lua chargés (commande SCRIPT LOAD) qui ne sont pas attendus dans votre environnement.
• Crashes récurrents du processus redis-server ou traces stack liées au moteur Lua / garbage collector.
• Connexions sortantes anormales depuis l’hôte Redis (reverse shells), nouvelles clés SSH, binaires déposés.
  Sur ces points, activer la journalisation des commandes Redis et corréler avec le réseau/IDS est indispensable. 

🛡️ Mesures d’atténuation immédiates (ordre de priorité)

1. PATCH : appliquer le correctif officiel Redis 8.2.2 sur toutes les instances dès que possible — c’est la mitigation définitive. Redis
2. Workaround temporaire : si vous ne pouvez pas patcher immédiatement, interdire l’exécution de scripts Lua(bloquer EVAL/EVALSHA) via ACLs ou configuration, ce que Redis documente comme solution de contournement. NVD
3. Restreindre l’accès réseau : binder Redis sur localhost ou entrez-le derrière firewall / security groups ; ne jamais exposer Redis directement à Internet.
4. Vérifier accounts & ACLs : forcer la rotation des mots de passe Redis, supprimer comptes non nécessaires, et limiter les permissions d’exécution de commandes. X (formerly Twitter)
5. Hunting & forensique : pour toute machine potentiellement touchée, considérer l’hôte comme compromis — prendre snapshot/collecter preuve, isoler, et procéder à rebuild/recovery à partir d’images saines après enquête.

🧭 Conseils opérationnels pour les SOC / admins

• Déployer des règles de détection (SIEM) sur l’usage de EVAL, sur les crashs Redis et sur les créations de fichiers/binaires inhabituels depuis les hôtes Redis.
• Prioriser le patching des instances exposées et celles servant d’éléments critiques (cache auth, sessions, tokens).
• Sur les environnements cloud, vérifier les snapshots/AMI et les images machine : un attaquant qui obtient RCE peut avoir persisté une backdoor dans ces artefacts.

⚠️ Conclusion

RediShell est une vulnérabilité critique avec exploitabilité réelle : le vecteur est simple (exécution de scripts Lua) mais l’impact est maximal (RCE complète). Si vous gérez des instances Redis, traitez-la comme une urgence opérationnelle — patch, restriction d’accès, et chasse aux compromis. Les équipes doivent considérer toute instance vulnérable comme potentiellement compromise tant qu’un forensique rigoureux n’a pas démontré le contraire. 

Souhaites-tu que je complète cet article avec : (A) un encadré « checklist SOC » imprimable, (B) des règles Sigma/YARA/YARA-like pour détection, ou (C) un mail d’alerte technique prêt à envoyer aux infra/ops ?

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com