CVE-2026-90621 powinno uruchomić alarm nie dlatego, że ma najwyższy CVSS, lecz dlatego, że skrót w rekordzie nie opisuje wprost tego samego attack path, co pierwotny report. Rekord opisuje podatność w ssh_run_command jako OS command injection do wykorzystania zdalnie. Tymczasem issue #150 przedstawia ciekawszy mechanizm: atakujący kontrolujący cel testów umieszcza instrukcje prompt-injection w outapucie SSH; ten output bez taint marking trafia do historii konwersacji LLM, model generuje kolejną komendę, a HackingBuddyGPT może przekazać ją przez tmux send-keys do lokalnego terminala operatora.
ssh_run_command, zdalnie (CWE-78).tmux send-keys → shell operatora.Attack path według źródła
Cztery elementy: raw output SSH bez sanitizacji/taint marking; output dokładany do historii i przekazywany modelowi; odpowiedź modelu z lekkim post-processing, bez polityki allow/deny; komenda wykonywana na stacji operatora przez tmux, poza zdalnym targetem. To nieintuicyjna zmiana kierunku zaufania: host, który pentester traktuje jako wrogi, może wpłynąć na agenta z dostępem do lokalnego środowiska pentestera.
Dlaczego opis CVE bywa zbyt płaski
Jeśli VM zapisze tylko CVE-2026-90621 → CWE-78 → command injection → Medium, gubi trzy ważniejsze informacje: źródłem danych jest atakowany target (wejście z definicji nieufne); decyzję o komendzie podejmuje LLM podatny na prompt injection; końcowy sink może być na stacji operatora. Klasyczna linia source → sink musi zyskać warstwę modelu: untrusted tool output → model context → model decision → privileged tool/action. Nie dopisuj active exploitation — publiczny PoC ≠ kampania; rozdziel severity rekordu, public exploitability, environmental exploitability (czy local shell/tmux jest aktywny), asset context (stacja operatora: SSH keys, VPN, cloud credentials, CI/CD).
Remediation, weryfikacja, provenance
Nie filtr regexem (prompt injection nie wymaga jednego słowa kluczowego), lecz przebudowa granicy zaufania: oznaczanie output tooli jako untrusted data, rozdzielenie danych od instrukcji, sandbox dla komend LLM, allowlista operacji, deterministyczna autoryzacja tool calli poza modelem, human approval dla high-impact, brak automatycznego local-shell po kontakcie z nieufnym output, minimalne uprawnienia i osobny profil credential. Weryfikacja property-based: kontrolowany host testowy zwraca tekst-instrukcję z bezpiecznym znacznikiem; sprawdź, czy output oznaczony jako dane, czy model może zaproponować niedozwoloną akcję, czy execution layer ją blokuje niezależnie od modelu, czy nic nie trafia automatycznie do tmux, czy log pokazuje odrzuconą próbę, czy approval wymagany. Finding zamknięty, gdy nieufne dane z celu nie mogą samodzielnie doprowadzić do wykonania lokalnej akcji. Jeśli feed mówi „command injection”, a źródło „target output → LLM → tmux → operator”, przechowuj obie informacje: CVE synopsis, researcher root cause, attack path, affected capability, execution location, confidence/provenance.
Powiązane na blogu
- Cochise: 3.7 → prompt injection — ta sama klasa trust-boundary w agentach
- GitPython: dane stają się kodem - nieoczywista granica wejścia
Źródła
- Researcher report (issue #150) — github.com
- NVD — CVE-2026-90621 — nvd.nist.gov
Nota redakcyjna: stan informacji 14 września 2026. CVE-2026-90621 (HackingBuddyGPT) opisany jako command injection; źródło pokazuje target prompt injection → tmux → shell operatora. Brak potwierdzenia active exploitation. Artykuł zaleca zachowanie provenance attack path (synopsis vs root cause vs execution location).