HexStrike AI jest świeżym przykładem problemu, który trudno obsłużyć workflow „CVE → wersja podatna → wersja naprawiona → ticket zamknięty”. Dwa rekordy z 14 września — CVE-2026-90619 i CVE-2026-90620 — dotyczą API udostępniającego wykonywanie kodu Pythona i komend shell. Oba mają CVSS 5.5. Jednocześnie publiczne zgłoszenia opisują usługę na 0.0.0.0:8888, brak uwierzytelnienia i endpointy, które przy osiągalności sieciowej zachowują się praktycznie jak remote shell. Do tego projekt jest rolling-release, bez stabilnej historii wydań pozwalającej łatwo ustalić fixed version.
/api/python/execute (skrypt → subprocess) i /api/command (subprocess.Popen(..., shell=True)), bez auth, na 0.0.0.0:8888.Dwa endpointy, dwie prymitywy
HexStrike AI jest narzędziem ofensywnym i może potrzebować mechanizmów wykonywania komend — sam fakt istnienia niebezpiecznej funkcji nie jest podatnością. Security boundary zależy od tego, kto może ją wywołać i skąd: dangerous capability != vulnerability, ale dangerous capability + unintended network reachability + missing authorization = potentially critical attack path. Jeśli API miało być lokalnym backendem operatora, bind do 0.0.0.0 bez auth jest zupełnie inną własnością niż localhost-only. Nie przepisuj oficjalnego score, ale prowadź dwie osie: severity z rekordu (5.5) i operational exploitability (uruchomienie API, bind, routing/firewall, proxy/VPN, uprawnienia procesu, sekrety na hoście, test vs środowisko operacyjne). Na izolowanym laptopie zdalna dostępność bywa zerowa; na współdzielonym serwerze w VLAN security tooling z dostępem do repo, skanerów i poświadczeń — skutki są znacznie poważniejsze niż „Medium”.
Co wpisać jako fixed version?
Nic — nie ma dobrego powodu, by ją wymyślać. Advisory opisuje rolling release, brak wersjonowania i brak tabeli „affected → fixed”. Łatwo tu o data-quality failure: scanner importuje CVE, enrichment przypisuje przypadkową wersję/datę, remediation aktualizuje repo, finding zamknięty bez testu endpointu. Lepszy model zapisuje: źródło twierdzenia, commit/revision reprodukcji, confidence, stan odpowiedzi maintainera, czy istnieje accepted fix, czy jest tagged release z fixem, properties do weryfikacji. Provenance: CVE świeże i oznaczone jako nieweryfikowane w GitHub Advisory Database, issues od researchera — zapisz „researcher-reproduced: tak, CVE assigned: tak, maintainer confirmed: nie, fixed release: nie, active exploitation: brak potwierdzenia”.
Remediation i property-based verification
Bez jednoznacznej poprawki najracjonalniejsze są controls: nie wystawiać portu 8888 poza localhost/zaufany segment, firewall deny-by-default, reverse proxy z silnym auth, VPN/bastion, osobny kontener/VM, minimalne uprawnienia procesu, brak produkcyjnych sekretów na hoście, monitoring requestów do endpointów wykonawczych, blokada zbędnego egress. Closure bez numeru wersji — property-based: dla /api/command request z niezaufanego segmentu nie dochodzi, bez auth dostaje 401/403 (jeśli dołożono), payload nie spawnuje procesu; dla Python execution — endpoint niedostępny z nieautoryzowanej lokalizacji, wykonanie sandboxowane, proces bez sekretów i host FS. Dodatkowo sprawdź listening socket, procesy potomne, politykę kontenera, egress i mounty. Jeśli API na 0.0.0.0:8888 było osiągalne bez auth — firewall dziś nie mówi nic o wczoraj: przejrzyj access logs, requesty do endpointów wykonawczych, procesy potomne, pliki tymczasowe, outbound, persistence.
Powiązane na blogu
- PentestAgent: MCP do host RCE — capability + reachability w narzędziach ofensywnych
- FedML: luka w evidence — provenance i confidence zamiast jednego „vulnerable”
Źródła
- Research issue (Python exec) — github.com
- Research issue (command API) — github.com
- CVE-2026-90619 — cve.org
Nota redakcyjna: stan informacji 14 września 2026. CVE-2026-90619/90620 (HexStrike AI): nieautoryzowane endpointy wykonawcze na 0.0.0.0:8888, rolling-release bez fixed version. CVE oznaczone jako nieweryfikowane; brak potwierdzenia active exploitation. Artykuł zaleca property-based verification i zachowanie provenance.