Redis en cloud : limiter l'exposition avant incident

Une vulnérabilité Redis expose une partie critique de l'infrastructure Cloud

Ce qu'il faut retenir

L'étude de Wiz Research quantifie l'ampleur du phénomène : pas moins de 330 000 instances Redis seraient directement exposées sur Internet.

Parmi elles, environ 60 000 instances fonctionneraient sans le moindre mécanisme d'authentification, laissant les données qu'elles contiennent et les serveurs sous-jacents accessibles sans aucune restriction.

Cet incident rappelle une réalité souvent sous-estimée

les fondations de l'infrastructure cloud moderne reposent sur un nombre restreint de composants open source essentiels.

Leur efficacité et leur omniprésence peuvent toutefois faire oublier leur fragilité potentielle. Des précédents comme la faille Log4Shell (affectant des millions de serveurs Java en 2021), Heartbleed dans OpenSSL (2014), ou la backdoor XZ Utils évitée de justesse en 2024, illustrent ce risque systémique récurrent.

Dans chacun de ces cas, une vulnérabilité découverte dans une brique logicielle critique, maintenue par une petite équipe souvent bénévole, a menacé l'intégrité d'une partie significative de l'écosystème numérique mondial.

Corriger et durcir

Face à cette menace, l'éditeur Redis a réagi promptement en publiant des correctifs pour toutes ses versions maintenues. Une mise à jour urgente est donc impérative pour toute instance déployée.

Au-delà de l'application des correctifs, il est crucial de renforcer la posture de sécurité des instances Redis :

• Activer l'authentification via la directive requirepass.
• Désactiver les commandes Lua si elles ne sont pas nécessaires à l'application, soit via les ACL Redis, soit en révoquant les permissions de scripting.

Réduire l'exposition réseau en production

La faille RediShell rappelle surtout une règle simple : Redis ne doit jamais être accessible depuis Internet sans contrôle strict. En pratique :

• Placer l'instance dans un sous-réseau privé, joignable uniquement par l'application qui en a besoin.
• Fermer le port 6379 (ou l'équivalent managé) dans les groupes de sécurité cloud et les pare-feu hôtes.
• Activer TLS pour les connexions entre application et Redis lorsque le fournisseur le propose.
• Éviter les mots de passe par défaut ; préférer des secrets injectés via le gestionnaire de secrets du cloud.

Les scans récurrents (Shodan, outils internes) permettent de détecter une exposition accidentelle avant qu'un attaquant ne la trouve. Sur AWS, Azure ou GCP, les offres Redis managées intègrent en général l'authentification et l'isolation réseau : les utiliser réduit la surface d'erreur par rapport à une installation manuelle mal durcie.

Une gestion responsable de la divulgation

La faille, baptisée RediShell, a été découverte par Wiz Research lors de l'édition de mai 2025 du concours Pwn2Own à Berlin.

Après en avoir été informé, Redis a publié un avis de sécurité le 3 octobre, suivi par la divulgation publique des détails techniques par Wiz le 6 octobre.

Cette chronologie démontre le bon déroulement d'un processus de divulgation responsable, limitant les risques pour la communauté.

Conclusion : un écosystème à consolider

Si la réponse à court terme a été efficace, cet événement souligne la nécessité d'une réflexion à long terme sur la sécurisation des biens communs numériques. Un soutien financier et technique accru de la part des grands acteurs du cloud envers les mainteneurs de ces logiciels essentiels, ainsi que le financement d'audits réguliers sous l'égide de l'OpenSSF, seraient des leviers déterminants.

Aujourd'hui Redis est patché, mais dans un écosystème aussi interdépendant, la prochaine faille critique n'est malheureusement qu'une question de temps. La véritable résilience résidera dans notre capacité collective à renforcer ces fondations avant que la crise ne survienne.

Source : Wiz