Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

Publié le 21 octobre 2025
CVE-2025-49844 — “RediShell”. Un client Redis disposant de la commande EVAL peut s’évader du sandbox Lua et exécuter du code natif sur l’hôte. Avec une instance Redis mal configurée (sans requirepass, exposée au LAN ou à Internet), l’attaque devient pré-authentification de fait.

​
Le mécanisme

Le moteur Lua embarqué dans Redis isole théoriquement les scripts utilisateurs dans une sandbox. La faille tient en deux étapes :
  1. Corruption mémoire. Un script Lua spécialement crafté manipule le garbage collector de Lua pour libérer un objet encore référencé par un autre.
  2. Évasion. L’utilisation après libération (use-after-free) qui en découle permet à l’attaquant de sortir de l’interpréteur Lua et d’exécuter du code en natif dans le process redis-server.
À partir de là, l’attaquant tient le process Redis avec ses droits. Sur la majorité des déploiements, ces droits sont suffisants pour lire les données, accéder au filesystem du conteneur ou de la VM, et tenter un mouvement latéral vers d’autres services accessibles depuis l’hôte.

​
Pourquoi le critère “authentifié” est trompeur

Le bulletin parle d’un attaquant authentifié — mais en pratique :
  • Beaucoup de Redis tournent sans requirepass, sur des réseaux supposés “de confiance”.
  • D’autres exposent des credentials stockés en clair dans des backups, des images Docker ou des variables d’environnement leakées.
  • Une simple SSRF dans une application qui parle à un Redis interne suffit à devenir “authentifié” du point de vue de Redis.
Bref : l’exposition réelle est très large.

​
Correctifs

Mettez Redis à jour vers (au minimum) la version corrigée de votre branche :
Branche RedisVersion corrigée minimale
6.26.2.20
7.27.2.11
7.47.4.6
8.08.0.4
8.28.2.2

​
Mitigation si vous ne pouvez pas patcher tout de suite

Désactivez les commandes Lua via les ACL Redis. Ce n’est pas idéal (certaines applications en dépendent) mais ça ferme la voie d’attaque : 
# Pour le user par défaut
ACL SETUSER default -eval -evalsha -fcall -fcall_ro -function

# Vérification
ACL LIST
Côté réseau :
  • Liez Redis à 127.0.0.1 ou à un réseau strictement interne (bind dans redis.conf).
  • Activez requirepass ou des ACL nommées.
  • Bloquez le port 6379 côté firewall pour tout sauf vos clients applicatifs.

​
Vérifier sa version

redis-cli INFO server | grep redis_version

​
À retenir

  • Patcher est la bonne réponse. Si vous différez : ACL -eval + restriction réseau, en attendant.
  • Profitez du redémarrage pour resserrer la configuration : binding, requirepass, dangerous commands renommées.
  • Un PoC est public, l’exploitation est triviale une fois EVAL accessible — ne traînez pas.
Pour toute aide, ouvrez un ticket depuis votre espace client OnetSolutions.