Strona główna / Blog / OpenHop: localhost ≠ nieosiągalne

Blog · case study

OpenHop CVE-2026-59179: „tylko localhost” nie znaczy „nieosiągalne z Internetu”

CVE-2026-59179 (GHSA-g72f-jw3w-mgh7) dotyczy @openhop/server przed 0.3.6. Niesanitowany parametr id trafia do path.join() przy budowaniu ścieżek do plików YAML — skutkiem jest wyjście poza katalog flow i odczyt/usunięcie plików .yaml dostępnych dla procesu. Sam path traversal jest znany; ciekawszy jest kontekst reachability: lokalny serwer bywa osiągalny z przeglądarki ofiary (CORS origin: true), a w oficjalnym Dockerze HOST=0.0.0.0 daje bezpośrednią ekspozycję sieciową.

CVE-2026-59179 (CVSS 8.3): path traversal (read/delete .yaml) przez id w path.join(); confidentiality ograniczona rozszerzeniem, ale integrity/availability istotne.
Reachability: lokalnie — browser pivot przez CORS origin: true; w Dockerze — bezpośrednia ekspozycja przez HOST=0.0.0.0.

Attack path: wariant lokalny

user uruchamia openhop serve (loopback) -> odwiedza zlosliwa strone -> CORS dopuszcza origin atakujacego -> browser wysyla request do lokalnej instancji -> ..%2F... dekodowane do traversal path -> path.join() normalizuje poza katalog flow -> odczyt/usuniecie osiagalnego pliku .yaml

W tym modelu „network exposed = false” nie oznacza „remote exploit impossible” — browser jest proxy między Internetem a usługą na localhost. W kontenerze default wiąże serwer z 0.0.0.0: nie trzeba browser pivotu, unauthenticated attacker używa GET/DELETE bezpośrednio. Affectedness i exploitability zależą od deployment mode.

Kontekst zamiast samego CVSS

Priorytetu nie sprowadzaj do 8.3. Ustal: gdzie działa proces, jakie ma filesystem permissions, które YAML-e zawierają sekrety/konfigurację, czy serwer wiąże localhost czy 0.0.0.0, czy port jest publikowany przez Docker/Kubernetes i czy browser-based reachability pozostaje możliwa. Typowy scanner uzna usługę za niewystawioną (nie widzi portu z zewnątrz), a browser użytkownika ma dostęp do loopbacku — to dobry przykład false negative z błędnego modelu reachability.

Fix i weryfikacja

Wersja 0.3.6 naprawia problem. Potwierdź nie tylko wersję npm, ale image digest i realnie uruchomiony container/image. Blokada portu lub ograniczenie permissions to compensating controls, nie pełny fix — pivot CORS/localhost oznacza, że samo „bind 127.0.0.1” nie zawsze wystarcza jako dowód bezpieczeństwa. Dla kontenerów: package ≥0.3.6, rebuilt image, rollout nowych podów, brak starych workloadów, port exposure zgodny z intencją. Dla lokalnych instalacji: runtime ≥0.3.6, restart procesu, potwierdzenie, że permissive behavior nie jest już dostępna.

Powiązane na blogu

Źródła

  • GitHub Security Advisory GHSA-g72f-jw3w-mgh7 — github.com

Nota redakcyjna: stan informacji 10 września 2026. CVE-2026-59179 (@openhop/server <0.3.6, CVSS 8.3): path traversal z dwoma modelami reachability (browser pivot przez CORS, bezpośrednia ekspozycja w Dockerze). Artykuł podkreśla, że reachability nie jest binarna i że weryfikacja musi objąć image digest oraz runtime.

Zapamiętaj jedno

Reachability nie jest binarną właściwością „Internet / nie Internet”. W erze browser pivotów, agentów i lokalnych control plane trzeba modelować pośredników, którzy potrafią dostarczyć request do lokalnego endpointu.