Prueba de concepto en Python para CVE-2026-8065: identifica dispositivos Hitachi Energy RTU500 y sondea los endpoints de actualización de firmware en busca de cargas no autenticadas, con modos de verificación, explotación y escaneo masivo.
PoC en Python 3 para CVE-2026-8065 — Firmware CMU de la serie RTU500 de Hitachi Energy — omisión de autenticación (CWE-306) en el endpoint HTTP de actualización de firmware. CVSS 3.1 9.1 Crítica (IoT/OT).
| PoCbit | https://pocbit.org/pocs/cve-2026-8065 |
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-8065 |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H |
| CWE | CWE-306 Autenticación faltante para función crítica |
| Impacto | Carga arbitraria de firmware no autenticada → integridad / disponibilidad de la RTU de subestación |
RTU500 es la familia de Remote Terminal Unit (unidad terminal remota) utilizada en el ámbito de la transmisión/distribución de energía; la gestión del firmware CMU se realiza a través del servidor web. En CVE-2026-8065, el punto final de actualización de firmware queda accesible sin autenticación (o mediante bypass con un POST manipulado); un atacante puede cargar firmware arbitrario, alterando la función del dispositivo, comprometiendo su integridad o provocando un DoS.
Esto implica un impacto OT crítico remoto con PR:N en la red de automatización — debe probarse únicamente en un laboratorio de aislamiento autorizado o en el marco de un pentest aprobado por el proveedor.
Proveedor (CNA) afectado: RTU500 Series CMU Firmware — líneas de versión 9.0 y 12.0 (versionado personalizado; consulte el aviso actual y las notas del parche 13.8.2+).
Hitachi Energy asignó CVE-2026-8065 (publicado el 2026-09-29):
Una vulnerabilidad de omisión de autenticación en el endpoint de actualización de firmware de Hitachi Energy RTU500 permite a un atacante no autenticado cargar firmware arbitrario mediante una solicitud POST manipulada.
A diferencia de CVE-2024-2617 (usuario autenticado que omite la actualización segura cuando está deshabilitada), CVE-2026-8065 es acceso no autenticado a la función de actualización en sí — una brecha completa de CWE-306 en una superficie OT crítica para la seguridad.
Es posible que los avisos públicos aún no listen la URI exacta; la documentación de RTU500 describe el manejo de firmware mediante Configuration Management / transferencia de archivos del servidor web. Esta PoC identifica la RTU500 y sondea una lista seleccionada de rutas POST de firmware probables, luego (modo exploit) envía un blob de sondeo no de producción (POCBIT-8065-FW-PROBE) para detectar respuestas de aceptación no autenticada.
| Modo | Comportamiento |
|---|---|
| check | Sondeo HTTP(S) multipuerto, marcadores HTML de RTU500, regex de versión CMU, sondeo GET en rutas de firmware |
| exploit | POST multipart de un .fw falso sin cookie de sesión; exploited si 2xx + heurísticas de aceptación |
| mass | --list + -j; hits.txt / exploited.txt |
--dry-run | Exploit: solo sondeo GET de ruta de firmware (sin POST) |
--lab | RTU500 simulado local — debe mostrar exploited: true (verificación de cordura) |
--force | Exploit sin huella HTML de RTU500 |
--firmware-paths | Sobrescribir la lista de rutas (separadas por comas) cuando se conoce la ruta del proveedor |
JSONL: pocbit, pocbit_catalog, pocbit_page, cve, vendor, product.
Seguridad: La carga útil de exploit predeterminada no es una imagen flash CMU válida — solo un marcador + relleno para detección. Nunca apunte el modo exploit a equipos de red en vivo sin aislamiento y coordinación con el proveedor.
cd CVE-2026-8065
pip install -r requirements.txt
python poc.py -u https://192.168.1.10 --mode check
python poc.py -u https://192.168.1.10 --mode exploit --dry-run
python poc.py -u https://192.168.1.10 --mode exploit
python poc.py -u https://192.168.1.10 --mode exploit --firmware-paths /api/firmware/update
Con --list --mode check bulk activado por defecto: 1–2 GET por objetivo (URL de lista + http/https si es necesario), sin escaneo de 16 rutas de firmware, timeout corto (4s connect, 10s read), -j 32 por defecto.
python _format_fofa.py fofa_csv_1000.csv
python poc.py --list fofa_targets_rtu_priority.txt --mode check -j 40
python poc.py --list fofa_csv_1000.csv --mode check -j 50 --timeout 8
python poc.py --list targets.txt --mode check --full -j 20 # yavaş: çoklu port + tüm firmware GET
python poc.py --list hits.txt --mode exploit -j 8 --timeout 25
Progreso en CLI: [done/total hedef/s]; los hits se escriben al instante como HIT.
La lista FOFA cert="Hitachi" tiene mucho ruido; en el CSV escanee primero la lista de prioridad con rtu_priority. Check hit ≠ RTU real: las SPA corporativas en las que solo aparece hitachi energy se convierten en vendor_branding_only / vendor_branding_spa_false_positive; para el exploit se requiere una huella strong como rtu500 / rtutil500 / cmu firmware (si no, --force).
python poc.py --lab
python poc.py --list fofa_targets_rtu_priority.txt --mode check --full -j 20
python poc.py --list hits.txt --mode exploit --dry-run -j 8
El PoC rota (comprobación GET / explotación POST):
/api/firmware/update, /api/firmware/upload, /api/v1/firmware/update/firmware/update, /firmware/upload, /ws/firmware/update/CMU/firmware/upload, /ConfigurationManagement/Firmware/configuration/management/firmware, /FileUpload/Firmware/scripts/firmwareUpload, /cgi-bin/firmware, /admin/firmware/uploadCuando Hitachi publique la ruta exacta, establezca --firmware-paths únicamente a ese URI.