Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2026-61500 — PoC en Python y laboratorio Docker para CVE-2026-61500: recupera el estado del PRNG de Rejetto HFS V8 para falsificar una cookie de sesión de administrador y lograr RCE mediante server_code. | Kitploit
Herramientas/GitHubGitHub/aramosf/cve-2026-61500
Ataques de ContraseñasAnálisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebVirtualización de SeguridadCriptografíaPruebas de PenetraciónAprendizaje y EducaciónRed TeamingLabs y Práctica
GitHub
hace 1 díaAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
aramosf/cve-2026-61500

CVE-2026-61500

PoC en Python y laboratorio Docker para CVE-2026-61500: recupera el estado del PRNG de Rejetto HFS V8 para falsificar una cookie de sesión de administrador y lograr RCE mediante server_code.

Ver Repositorio

CVE-2026-61500: Falsificación de sesión en Rejetto HFS hasta RCE

Demostración real en terminal

CVE-2026-61500 es una vulnerabilidad de falsificación de sesión no autenticada en Rejetto HFS 3.0.0 hasta 3.2.0. HFS generaba su clave de firma de cookies de sesión de Koa con JavaScript Math.random() y exponía salidas del mismo PRNG de V8 en el handshake de inicio de sesión SRP no autenticado. Un atacante puede reconstruir el estado del PRNG, recuperar la clave de firma, falsificar una sesión de administrador y usar la característica documentada de configuración server_code para ejecutar JavaScript del lado del servidor.

Este repositorio contiene una prueba de concepto en Python y una comparación desechable en Docker usando las imágenes oficiales de HFS 3.2.0 y 3.2.1. La compilación de publicación está intencionalmente restringida a objetivos HTTP en la interfaz de loopback local.

Alcance

DeclaraciónEstado
Recuperar el estado xorshift128+ de V8 a partir de respuestas de inicio de sesión no autenticadasConfirmado
Recuperar la clave de firma de cookies activa de HFSConfirmado
Falsificar una sesión aceptada como administrador de HFSConfirmado
Ejecutar un marcador server_code benigno en HFS 3.2.0 oficialConfirmado
Recibir una reverse shell de root dentro de la red Compose aisladaConfirmado
Detenerse antes de la falsificación de sesión en HFS 3.2.1 oficialConfirmado
Dirigirse a Internet o persistenciaNo proporcionado ni reclamado

Proceso de explotación

  1. Enviar seis solicitudes no autenticadas a la API loginSrp1 para la cuenta conocida admin. Cada respuesta vulnerable coloca un loggingIn.sid numérico y su cookie de sesión firmada en las cabeceras Set-Cookie.
  2. Convertir cinco dobles consecutivos a sus 53 bits visibles del PRNG y forzar por fuerza bruta los once bits bajos omitidos. Invertir y avanzar la recurrencia xorshift128+ de V8 hasta que un estado interno satisfaga cada valor observado.
  3. Reproducir los tres fragmentos en base 36 usados por HFS randomId(30). El PoC tiene en cuenta el redondeo de cadena más corta de V8 y verifica los candidatos contra un HMAC hfs_http.sig observado, que también identifica el desplazamiento de inicio.
  4. Firmar una sesión sintética que contenga username: admin, luego llamar a get_config para probar que la cookie falsificada tiene acceso de administrador.
  5. Llamar a set_config con un pequeño módulo server_code. La carga útil predeterminada escribe un marcador benigno en /data; está disponible solo para el laboratorio Docker en loopback.

Esta es una cadena HTTP de caja negra: el PoC no lee archivos, memoria, variables de entorno ni estado de procesos del objetivo. El conocimiento del código fuente se usa para modelar el algoritmo vulnerable.

Versiones afectadas y corregidas

  • Afectadas: HFS 3.0.0 hasta 3.2.0.
  • Primera versión corregida: HFS 3.2.1.
  • Corrección: 59472e534bf7e056d708382d02935c2eaf956927.

La corrección reemplaza la clave de firma con 32 bytes de randomBytes() de Node.js y reemplaza el identificador de inicio de sesión numérico expuesto con randomUUID(). Proporcionar un valor explícito y fuerte de COOKIE_SIGN_KEYS mitiga la predicción de la clave de firma, pero actualizar sigue siendo la remediación recomendada.

Entorno validado

  • Host: Linux 6.18.33.2-microsoft-standard-WSL2, x86_64.
  • Docker 29.7.2; Docker Compose v5.5.0; Python 3.14.4.
  • Imagen vulnerable: rejetto/hfs:v3.2.0, digest sha256:d6765e93b68de222583be7788afad699695fd08aa2f56377337f5139779e0746.
  • Imagen corregida: rejetto/hfs:v3.2.1, digest sha256:61db4da1f494df254aa7f48889c676b424b413e45b7b92cf4276f4b8e632aaec.
  • Imagen de callback de demostración: python:3.13-alpine, digest sha256:1a63a53928ce53d2b0baf08092a703f4840ac5dfbd61fd48802dbf48e08c801e.
  • Fecha de prueba: 2026-09-26.

Ambos servicios HFS se enlazan solo al loopback del host; el callback no publica ningún puerto. El laboratorio crea un administrador sintético porque loginSrp1 debe invocarse para un nombre de usuario existente; la contraseña no es conocida ni usada por el exploit.

Ejecutar la comparación desechable

Los requisitos son Docker con Compose, Python 3.10 o superior y curl.

root@kitploit:~
./verify.sh

El verificador elimina solo lab/runtime/vulnerable y lab/runtime/fixed, inicia ambas imágenes fijadas por digest, ejecuta los controles positivos y negativos, y detiene los contenedores de forma predeterminada. Use KEEP_LAB=1 ./verify.sh para dejar el laboratorio en ejecución para inspección.

Con el laboratorio retenido, la invocación directa del marcador benigno es:

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

Para demostrar la ejecución de comandos dentro del contenedor de laboratorio propio:

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

Cualquier nombre de host que no sea loopback, objetivo HTTPS o IP remota es rechazado por la validación de argumentos. El exploit modifica server_code de HFS; use solo el laboratorio desechable o un sistema para el cual tenga autorización explícita.

La demostración grabada va un paso más allá: demo.sh inicia el servicio callback no expuesto en la red Compose y usa --command para conectar una reverse shell de Bash a él. El callback envía solo id, uname -a, pwd y exit, registra la transcripción bajo lab/runtime/ ignorado y cierra. Ningún puerto de callback está enlazado al host.

Resultado reproducido

La ejecución real del 2026-09-26 recuperó un estado del PRNG y su clave de firma, recibió HTTP 200 para un get_config administrativo falsificado, instaló la carga útil del marcador, y observó CVE_2026_61500_RCE_CONFIRMED en el contenedor vulnerable. Un control separado --command 'id > /data/cve-command-output.txt' produjo uid=0(root) gid=0(root) groups=0(root) dentro de ese contenedor oficial. La reverse shell grabada solo con Docker devolvió independientemente la misma identidad de root y el directorio de trabajo /data. Contra 3.2.1, la primera respuesta de inicio de sesión contenía un UUID opaco y el PoC salió con estado 3 antes de intentar la falsificación de sesión. Consulte docs/example-output.txt y docs/e2e-results.json.

Búsqueda de exploits públicos

El 2026-09-26, se ejecutaron búsquedas exactas de CVE y exploit/PoC contra SearchSploit (índice local de Exploit-DB), resultados web indexados por GitHub, Packet Storm, Exploit-DB, y la web general. No se identificó ningún exploit público funcional en ese momento; los resultados encontraron solo metadatos de CVE/aviso y páginas de seguimiento de exploits. Este es un resultado con fecha y de mejor esfuerzo, no una afirmación de que no pueda existir otro exploit en otro lugar o aparecer más tarde.

Créditos

  • Exploit: A. Ramos <[email protected]> (Twitter: @aramosf).
  • Descubrimiento de la vulnerabilidad: Zach Hanley (@hacks_zach) de Horizon3.ai, en colaboración con Claude y Anthropic Research.
  • Corrección: Massimo Melina / Rejetto.

Referencias

  • Aviso de VulnCheck
  • Lanzamiento de HFS 3.2.1
  • Commit de corrección upstream
  • Registro de CVE-2026-61500

Aviso legal

Solo para investigación de seguridad autorizada, validación defensiva y educación. Usted es responsable de obtener permiso y cumplir con la ley aplicable.

Descargar herramienta
--command