redis-cve-2026-23479-check

You do you. I do me. We share contexts.

Votre Redis reste le vôtre ; le vérificateur lit une seule ligne INFO et ne change rien.

Un vérificateur de version sûr et en lecture seule pour CVE-2026-23479 — le use-after-free dans le code de client bloquant de Redis qui permet à un utilisateur authentifié d'atteindre l'exécution de code à distance sur l'hôte.

Il n'exploite pas la faille. Il se connecte, s'authentifie éventuellement, exécute un seul INFO server en lecture seule, analyse la version et la compare à la liste des versions corrigées. Il n'envoie jamais de commande bloquante et ne touche jamais au chemin de code vulnérable. Utilisez-le uniquement contre des instances que vous possédez ou que vous êtes explicitement autorisé à tester.

Pourquoi c'est important

« Authentifié » sonne rassurant jusqu'à ce que vous vous rappeliez comment Redis est réellement déployé : pendant des années, la valeur par défaut était sans mot de passe, et même aujourd'hui c'est la boîte de cache/file/session de confiance que personne ne filtre en interne. Une RCE authentifiée sur un composant que chaque serveur d'application peut déjà atteindre, sur un réseau plat, c'est une autoroute pour le mouvement latéral. Et à l'heure où nous écrivons, il n'existe aucun PoC public — ce qui signifie que vous êtes en amont de l'explosion. C'est l'endroit le moins coûteux où un défenseur puisse jamais se trouver. Profitez-en : trouvez vos instances exposées et patchez avant que l'exploit n'arrive.

La faille

• CVE-2026-23479 · use-after-free dans la gestion des clients bloquants. Lorsqu'un client bloqué est évincé pendant la ré-exécution d'une commande bloquante, un utilisateur authentifié peut déclencher un UAF → RCE potentielle.
• Introduite dans : Redis 7.2.0. Présente dans toutes les branches stables jusqu'aux correctifs du 2026-05-05.
• CVSS : 8.8 (NVD, CVSS 3.1) · 7.7 (Redis, CVSS 4.0).
• Corrigée dans : 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, 8.6.3.

Utilisation

Aucune dépendance — juste Python 3.

python3 check.py <host> [-p PORT] [-a PASSWORD] [--user ACL_USER] [--tls] [--insecure]

Exemples :

python3 check.py 127.0.0.1
python3 check.py redis.internal -p 6380 -a "$REDIS_PASSWORD"
python3 check.py redis.example.com --tls            # cert verified by default
python3 check.py redis.internal --tls --insecure    # self-signed internal cert (opt-in)

Le code de sortie est 0 lorsque corrigé/non affecté et 1 lorsqu'une action est nécessaire (vulnérable / à vérifier), ce qui l'intègre directement dans la CI :

python3 check.py "$REDIS_HOST" -a "$REDIS_PASSWORD" || echo "::warning::Redis needs the CVE-2026-23479 patch"

Si le résultat est VULNERABLE

1. Mettez à niveau vers la version corrigée de votre branche (ci-dessus).
2. Sur tout ce que vous ne pouvez pas patcher immédiatement : exigez l'authentification et faites tourner le mot de passe, et placez le port Redis derrière une politique réseau afin que seuls les services qui en ont besoin puissent l'atteindre — pas tout le VLAN. Si un attaquant ne peut pas atteindre le port et ne peut pas s'authentifier, un UAF authentifié est une faille qu'il ne peut pas toucher.

Détecter l'exploitation

Voir detection/redis-cve-2026-23479.sigma.yml — une règle Sigma basée sur l'hôte qui capture le résultat de toute RCE Redis (le processus redis-server lançant un shell ou un processus enfant inattendu), ce qui est bien plus robuste que d'essayer d'identifier les paquets exacts de l'exploit.

---

Par DugganUSA : du renseignement sur les menaces que vous pouvez vérifier. DugganUSA Feed (STIX 2.1, offre gratuite, compteurs en direct). Enregistrez une clé gratuite · nous livrons le bouclier, pas l'épée.