Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
CVE-2026-61500 — PoC Python et lab Docker pour CVE-2026-61500 : récupère l'état du PRNG de Rejetto HFS V8 pour forger un cookie de session administrateur et obtenir une RCE via server_code. | Kitploit
Outils/GitHubGitHub/aramosf/cve-2026-61500
Attaques de Mots de PasseAnalyse des VulnérabilitésExploitationExploitation d'Applications WebVirtualisation de SécuritéCryptographieTests d'IntrusionApprentissage et ÉducationRed TeamingLabs et Pratique
GitHub
il y a 1 jourPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
aramosf/cve-2026-61500

CVE-2026-61500

PoC Python et lab Docker pour CVE-2026-61500 : récupère l'état du PRNG de Rejetto HFS V8 pour forger un cookie de session administrateur et obtenir une RCE via server_code.

Voir le dépôt

CVE-2026-61500 : Falsification de session Rejetto HFS menant à une RCE

Démonstration réelle dans un terminal

CVE-2026-61500 est une vulnérabilité de falsification de session non authentifiée dans Rejetto HFS 3.0.0 jusqu'à 3.2.0. HFS générait sa clé de signature de cookie de session Koa avec le Math.random() de JavaScript et exposait des sorties du même PRNG V8 dans la poignée de main de connexion SRP non authentifiée. Un attaquant peut reconstruire l'état du PRNG, récupérer la clé de signature, falsifier une session administrateur et utiliser la fonctionnalité documentée de configuration server_code pour exécuter du JavaScript côté serveur.

Ce dépôt contient une preuve de concept en Python et une comparaison Docker jetable utilisant les images officielles HFS 3.2.0 et 3.2.1. La version de publication est intentionnellement restreinte aux cibles HTTP sur l'interface de bouclage locale.

Périmètre

AffirmationStatut
Récupérer l'état V8 xorshift128+ à partir des réponses de connexion non authentifiéesConfirmé
Récupérer la clé de signature de cookie HFS activeConfirmé
Falsifier une session acceptée comme administrateur HFSConfirmé
Exécuter un marqueur server_code bénin dans HFS 3.2.0 officielConfirmé
Obtenir un reverse shell root dans le réseau Compose isoléConfirmé
S'arrêter avant la falsification de session sur HFS 3.2.1 officielConfirmé
Ciblage ou persistance à l'échelle d'InternetNon fourni ni revendiqué

Processus d'exploitation

  1. Envoyer six requêtes API loginSrp1 non authentifiées pour le compte admin connu. Chaque réponse vulnérable place un loggingIn.sid numérique et son cookie de session signé dans les en-têtes Set-Cookie.
  2. Convertir cinq doubles consécutifs en leurs 53 bits visibles du PRNG et forcer par force brute les onze bits de poids faible omis. Inverser et avancer la récurrence xorshift128+ de V8 jusqu'à ce qu'un état interne satisfasse chaque valeur observée.
  3. Reproduire les trois blocs en base 36 utilisés par HFS randomId(30). Le PoC tient compte de l'arrondi de la chaîne la plus courte de V8 et vérifie les candidats par rapport à un HMAC hfs_http.sig observé, ce qui identifie également le décalage de démarrage.
  4. Signer une session synthétique contenant username: admin, puis appeler get_config pour prouver que le cookie falsifié dispose d'un accès administrateur.
  5. Appeler set_config avec un petit module server_code. La charge utile par défaut écrit un marqueur bénin dans /data ; n'est disponible que pour le laboratoire Docker en bouclage.

Il s'agit d'une chaîne HTTP en boîte noire : le PoC ne lit ni fichiers, ni mémoire, ni variables d'environnement, ni état de processus depuis la cible. La connaissance du code source est utilisée pour modéliser l'algorithme vulnérable.

Versions affectées et corrigées

  • Affectées : HFS 3.0.0 jusqu'à 3.2.0.
  • Première version corrigée : HFS 3.2.1.
  • Correctif : 59472e534bf7e056d708382d02935c2eaf956927.

Le correctif remplace la clé de signature par 32 octets issus de randomBytes() de Node.js et remplace l'identifiant de connexion numérique exposé par randomUUID(). Fournir une valeur COOKIE_SIGN_KEYS forte explicite atténue la prédiction de la clé de signature, mais la mise à niveau reste la remédiation recommandée.

Environnement validé

  • Hôte : Linux 6.18.33.2-microsoft-standard-WSL2, x86_64.
  • Docker 29.7.2 ; Docker Compose v5.5.0 ; Python 3.14.4.
  • Image vulnérable : rejetto/hfs:v3.2.0, digest sha256:d6765e93b68de222583be7788afad699695fd08aa2f56377337f5139779e0746.
  • Image corrigée : rejetto/hfs:v3.2.1, digest sha256:61db4da1f494df254aa7f48889c676b424b413e45b7b92cf4276f4b8e632aaec.
  • Image de rappel de démonstration : python:3.13-alpine, digest sha256:1a63a53928ce53d2b0baf08092a703f4840ac5dfbd61fd48802dbf48e08c801e.
  • Date de test : 2026-09-26.

Les deux services HFS ne se lient qu'à la boucle locale de l'hôte ; le rappel ne publie aucun port. Le laboratoire crée un administrateur synthétique car loginSrp1 doit être invoqué pour un nom d'utilisateur existant ; le mot de passe n'est ni connu ni utilisé par l'exploit.

Exécuter la comparaison jetable

Les prérequis sont Docker avec Compose, Python 3.10 ou plus récent, et curl.

root@kitploit:~
./verify.sh

Le vérificateur supprime uniquement lab/runtime/vulnerable et lab/runtime/fixed, démarre les deux images épinglées par digest, exécute les contrôles positifs et négatifs, et arrête les conteneurs par défaut. Utilisez KEEP_LAB=1 ./verify.sh pour laisser le laboratoire en cours d'exécution pour inspection.

Avec le laboratoire conservé, l'invocation directe du marqueur bénin est :

root@kitploit:~
python3 cve-2026-61500-poc.py \
  --target http://127.0.0.1:28182 \
  --marker cve-2026-61500-rce-marker.txt

Pour démontrer l'exécution de commandes à l'intérieur du conteneur de laboratoire possédé :

root@kitploit:~
python3 cve-2026-61500-poc.py \
  --target http://127.0.0.1:28182 \
  --command 'id > /data/cve-command-output.txt'

Tout nom d'hôte non-loopback, cible HTTPS ou IP distante est rejeté par la validation des arguments. L'exploit modifie le server_code de HFS ; utilisez uniquement le laboratoire jetable ou un système pour lequel vous disposez d'une autorisation explicite.

La démonstration enregistrée va plus loin : demo.sh démarre le service callback non exposé sur le réseau Compose et utilise --command pour y connecter un reverse shell Bash. Le rappel envoie uniquement id, uname -a, pwd et exit, enregistre la transcription sous lab/runtime/ ignoré, puis se ferme. Aucun port de rappel n'est lié à l'hôte.

Résultat reproduit

L'exécution réelle du 2026-09-26 a récupéré un état de PRNG et sa clé de signature, reçu un HTTP 200 pour un get_config administratif falsifié, installé la charge utile marqueur, et observé CVE_2026_61500_RCE_CONFIRMED dans le conteneur vulnérable. Un contrôle séparé --command 'id > /data/cve-command-output.txt' a produit uid=0(root) gid=0(root) groups=0(root) à l'intérieur de ce conteneur officiel. Le reverse shell enregistré, limité à Docker, a indépendamment renvoyé la même identité root et le répertoire de travail /data. Contre 3.2.1, la première réponse de connexion contenait un UUID opaque et le PoC s'est terminé avec le statut 3 avant de tenter la falsification de session. Voir docs/example-output.txt et docs/e2e-results.json.

Recherche d'exploit public

Le 2026-09-26, des recherches exactes de CVE et d'exploit/PoC ont été effectuées sur SearchSploit (index local Exploit-DB), les résultats web indexés par GitHub, Packet Storm, Exploit-DB, et le web général. Aucun exploit public fonctionnel n'a été identifié à ce moment-là ; les résultats ne trouvaient que des métadonnées de CVE/avis et des pages de suivi d'exploits. Il s'agit d'un résultat daté et au mieux, et non d'une affirmation qu'aucun exploit ne peut exister ailleurs ou apparaître plus tard.

Crédits

  • Exploit : A. Ramos <[email protected]> (Twitter : @aramosf).
  • Découverte de la vulnérabilité : Zach Hanley (@hacks_zach) de Horizon3.ai, en collaboration avec Claude et Anthropic Research.
  • Correctif : Massimo Melina / Rejetto.

Références

  • Avis VulnCheck
  • Version HFS 3.2.1
  • Commit de correction amont
  • Fiche CVE-2026-61500

Avis juridique

Pour la recherche en sécurité autorisée, la validation défensive et l'éducation uniquement. Vous êtes responsable de l'obtention des autorisations et du respect des lois applicables.

Télécharger l’outil
--command