Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-61500 — Python-PoC und Docker-Lab für CVE-2026-61500: rekonstruiert den PRNG-Zustand von Rejetto HFS V8, um ein Admin-Session-Cookie zu fälschen und RCE über server_code zu erreichen. | Kitploit
Tools/GitHubGitHub/aramosf/cve-2026-61500
PasswortangriffeSchwachstellenanalyseExploitationWebanwendungs-ExploitationSicherheitsvirtualisierungKryptographiePenetrationstestsLernen & BildungRed TeamingLabs & Praxis
GitHubaramosf/cve-2026-61500
vor 1 TagNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2026-61500

Python-PoC und Docker-Lab für CVE-2026-61500: rekonstruiert den PRNG-Zustand von Rejetto HFS V8, um ein Admin-Session-Cookie zu fälschen und RCE über server_code zu erreichen.

Repository anzeigen

CVE-2026-61500: Rejetto HFS Session-Fälschung bis hin zu RCE

Echte Terminal-Demonstration

CVE-2026-61500 ist eine nicht authentifizierte Session-Fälschungsschwachstelle in Rejetto HFS 3.0.0 bis 3.2.0. HFS generierte seinen Koa-Session-Cookie-Signaturschlüssel mit JavaScript Math.random() und gab Ausgaben desselben V8-PRNG im nicht authentifizierten SRP-Login-Handshake preis. Ein Angreifer kann den PRNG-Zustand rekonstruieren, den Signaturschlüssel wiederherstellen, eine Administrator-Session fälschen und die dokumentierte server_code-Konfigurationsfunktion nutzen, um serverseitiges JavaScript auszuführen.

Dieses Repository enthält einen Python-Proof-of-Concept und einen wegwerfbaren Docker- Vergleich mit den offiziellen HFS 3.2.0- und 3.2.1-Images. Der Veröffentlichungs-Build ist absichtlich auf HTTP-Ziele auf der lokalen Loopback-Schnittstelle beschränkt.

Umfang

AussageStatus
Wiederherstellung des V8-xorshift128+-Zustands aus nicht authentifizierten Login-AntwortenBestätigt
Wiederherstellung des aktiven HFS-Cookie-SignaturschlüsselsBestätigt
Fälschung einer als HFS-Administrator akzeptierten SessionBestätigt
Ausführung eines harmlosen server_code-Markers in offiziellem HFS 3.2.0Bestätigt
Erhalt einer Root-Reverse-Shell innerhalb des isolierten Compose-NetzwerksBestätigt
Stopp vor der Session-Fälschung bei offiziellem HFS 3.2.1Bestätigt
Internetweite Zielausrichtung oder PersistenzNicht bereitgestellt oder beansprucht

Ausnutzungsprozess

  1. Senden Sie sechs nicht authentifizierte loginSrp1-API-Anfragen für das bekannte admin- Konto. Jede anfällige Antwort platziert eine numerische loggingIn.sid und ihr signiertes Session-Cookie in Set-Cookie-Headern.
  2. Konvertieren Sie fünf aufeinanderfolgende Doubles in ihre 53 sichtbaren PRNG-Bits und brute forcen Sie die elf ausgelassenen niedrigen Bits. Kehren Sie die xorshift128+-Wiederholung von V8 um und schreiten Sie voran, bis ein interner Zustand jeden beobachteten Wert erfüllt.
  3. Reproduzieren Sie die drei Base-36-Chunks, die von HFS randomId(30) verwendet werden. Das PoC berücksichtigt die V8-Kürzest-String-Rundung und prüft Kandidaten gegen einen beobachteten hfs_http.sig-HMAC, der auch den Start-Offset identifiziert.
  4. Signieren Sie eine synthetische Session, die username: admin enthält, und rufen Sie dann get_config auf, um zu beweisen, dass das gefälschte Cookie Administratorzugriff hat.
  5. Rufen Sie set_config mit einem kleinen server_code-Modul auf. Die Standard-Payload schreibt einen harmlosen Marker in /data; ist nur für das Loopback-Docker-Lab verfügbar.

Dies ist eine Black-Box-HTTP-Kette: Das PoC liest keine Dateien, Speicher, Umgebungs- variablen oder Prozesszustand vom Ziel. Quellcode-Kenntnisse werden verwendet, um den anfälligen Algorithmus zu modellieren.

Betroffene und behobene Versionen

  • Betroffen: HFS 3.0.0 bis 3.2.0.
  • Erste behobene Version: HFS 3.2.1.
  • Fix: 59472e534bf7e056d708382d02935c2eaf956927.

Der Fix ersetzt den Signaturschlüssel durch 32 Bytes aus Node.js randomBytes() und ersetzt den exponierten numerischen Login-Identifikator durch randomUUID(). Die Angabe eines expliziten starken COOKIE_SIGN_KEYS-Werts mildert die Vorhersage des Signaturschlüssels ab, aber ein Upgrade bleibt die empfohlene Behebung.

Validierte Umgebung

  • Host: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64.
  • Docker 29.7.2; Docker Compose v5.5.0; Python 3.14.4.
  • Anfälliges Image: rejetto/hfs:v3.2.0, Digest sha256:d6765e93b68de222583be7788afad699695fd08aa2f56377337f5139779e0746.
  • Behobenes Image: rejetto/hfs:v3.2.1, Digest sha256:61db4da1f494df254aa7f48889c676b424b413e45b7b92cf4276f4b8e632aaec.
  • Demo-Callback-Image: python:3.13-alpine, Digest sha256:1a63a53928ce53d2b0baf08092a703f4840ac5dfbd61fd48802dbf48e08c801e.
  • Testdatum: 2026-09-26.

Beide HFS-Dienste binden nur an Host-Loopback; der Callback veröffentlicht keinen Port. Das Lab erstellt einen synthetischen Administrator, da loginSrp1 für einen existierenden Benutzernamen aufgerufen werden muss; das Passwort ist weder bekannt noch wird es vom Exploit verwendet.

Den wegwerfbaren Vergleich ausführen

Voraussetzungen sind Docker mit Compose, Python 3.10 oder neuer und curl.

root@kitploit:~
./verify.sh

Der Verifier entfernt nur lab/runtime/vulnerable und lab/runtime/fixed, startet beide digest-gepinnten Images, führt die Positiv- und Negativkontrollen aus und stoppt die Container standardmäßig. Verwenden Sie KEEP_LAB=1 ./verify.sh, um das Lab zur Inspektion weiterlaufen zu lassen.

Mit beibehaltenem Lab ist der direkte Aufruf des harmlosen Markers:

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

Um die Befehlsausführung innerhalb des eigenen Lab-Containers zu demonstrieren:

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

Jeder Nicht-Loopback-Hostname, HTTPS-Ziel oder Remote-IP wird durch die Argument- validierung abgelehnt. Der Exploit modifiziert HFS server_code; verwenden Sie nur das wegwerfbare Lab oder ein System, für das Sie eine ausdrückliche Autorisierung haben.

Die aufgezeichnete Demo geht einen Schritt weiter: demo.sh startet den nicht exponierten callback-Dienst im Compose-Netzwerk und verwendet --command, um eine Bash- Reverse-Shell damit zu verbinden. Der Callback sendet nur id, uname -a, pwd und exit, zeichnet das Transkript unter dem ignorierten lab/runtime/ auf und schließt. Es wird kein Callback-Port an den Host gebunden.

Reproduziertes Ergebnis

Der echte Lauf vom 2026-09-26 stellte einen PRNG-Zustand und seinen Signaturschlüssel wieder her, erhielt HTTP 200 für ein gefälschtes administratives get_config, installierte die Marker-Payload und beobachtete CVE_2026_61500_RCE_CONFIRMED im anfälligen Container. Eine separate --command 'id > /data/cve-command-output.txt'-Kontrolle erzeugte uid=0(root) gid=0(root) groups=0(root) innerhalb dieses offiziellen Containers. Die aufgezeichnete Docker-only-Reverse-Shell gab unabhängig dieselbe Root-Identität und dasselbe /data-Arbeitsverzeichnis zurück. Gegen 3.2.1 enthielt die erste Login-Antwort eine undurchsichtige UUID und das PoC beendete sich mit Status 3, bevor es die Session-Fälschung versuchte. Siehe docs/example-output.txt und docs/e2e-results.json.

Suche nach öffentlichen Exploits

Am 2026-09-26 wurden exakte CVE- und Exploit/PoC-Suchen gegen SearchSploit (lokaler Exploit-DB-Index), GitHub-indexierte Web-Ergebnisse, Packet Storm, Exploit-DB und das allgemeine Web durchgeführt. Zu diesem Zeitpunkt wurde kein funktionierender öffentlicher Exploit identifiziert; die Ergebnisse fanden nur CVE-/Advisory-Metadaten und Exploit-Tracking-Seiten. Dies ist ein datiertes Best-Effort-Ergebnis, keine Behauptung, dass kein Exploit anderswo existieren oder später auftauchen kann.

Danksagungen

  • Exploit: A. Ramos <[email protected]> (Twitter: @aramosf).
  • Schwachstellenentdeckung: Zach Hanley (@hacks_zach) von Horizon3.ai, in Zusammenarbeit mit Claude und Anthropic Research.
  • Fix: Massimo Melina / Rejetto.

Referenzen

  • VulnCheck-Advisory
  • HFS 3.2.1-Release
  • Upstream-Fix-Commit
  • CVE-2026-61500-Eintrag

Rechtlicher Hinweis

Nur für autorisierte Sicherheitsforschung, defensive Validierung und Bildung. Sie sind dafür verantwortlich, die Erlaubnis einzuholen und geltendes Recht einzuhalten.

Tool herunterladen
--command