> ## 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.

# RediShell (CVE-2025-49844) : évasion du sandbox Lua de Redis vers RCE

> Un script Lua malveillant exploite un use-after-free dans le moteur intégré de Redis pour exécuter du code natif sur l'hôte. PoC public.

*Publié le 21 octobre 2025*

<Warning>
  **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.
</Warning>

## 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 Redis | Version corrigée minimale |
| ------------- | ------------------------- |
| 6.2           | 6.2.20                    |
| 7.2           | 7.2.11                    |
| 7.4           | 7.4.6                     |
| 8.0           | 8.0.4                     |
| 8.2           | 8.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 :

```redis theme={null}
# 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

```bash theme={null}
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](https://onetsolutions.net).