Luka oznaczona jako CVE-2026-48827 [^1] otrzymała ocenę 7.1 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki). Dotyczy komponentu sshd-git w bibliotece Apache MINA SSHD, używanej do budowy serwerów SSH (Secure Shell) w języku Java. [^2] Problem umożliwia uwierzytelnionemu atakującemu odczyt danych z repozytoriów Git znajdujących się poza skonfigurowanym katalogiem głównym. [^3]

TL;DR

  • Produkt: Apache MINA SSHD, komponent org.apache.sshd:sshd-git. [^2]
  • Wektor: Path Traversal. Brak walidacji ścieżek w operacjach Git pozwala na wyjście poza katalog główny serwera. [^3]
  • Identyfikator: CVE-2026-48827 [^1] (CVSS: 7.1, High).
  • Wskaźnik kompromitacji: Użycie biblioteki org.apache.sshd:sshd-git w wersji starszej niż 2.18.0 [^4] lub w wersjach deweloperskich od 3.0.0-M1 do 3.0.0-M3. [^5]
  • Kogo dotyczy: Aplikacje, które używają sshd-git do udostępniania repozytoriów przez SSH. [^2] Dotyczy to zwłaszcza niestandardowych systemów CI/CD, wewnętrznych narzędzi deweloperskich oraz potencjalnie komercyjnych produktów opartych o tę bibliotekę. Polskie software house’y i działy IT utrzymujące własną infrastrukturę deweloperską powinny potraktować ten alert priorytetowo.
  • Pierwszy ruch: Identyfikacja podatnych komponentów w projektach i natychmiastowa aktualizacja do wersji 2.18.0 [^4] lub 3.0.0-M4. [^6]

Wektor ataku

Zaobserwowano lukę typu Path Traversal w komponencie sshd-git biblioteki Apache MINA SSHD. [^1] Jest to błąd klasy CWE-22, polegający na niewystarczającej walidacji danych wejściowych, które są używane do konstruowania ścieżki do pliku lub katalogu. W tym przypadku atakujący może użyć sekwencji znaków ../ do nawigacji w górę struktury katalogów serwera.

Problem leży w braku odpowiedniej walidacji ścieżki w obsłudze poleceń takich jak git-upload-pack i git-receive-pack. [^3] Uwierzytelniony użytkownik, który ma dostęp do serwera SSH opartego o podatną bibliotekę, może spreparować żądanie dostępu do repozytorium, które wskazuje na lokalizację poza zdefiniowanym katalogiem głównym dla repozytoriów Git. [^3]

Przykładowo, jeśli serwer jest skonfigurowany do obsługi repozytoriów z /srv/git/, atakujący może zażądać dostępu do ../../etc/secret-project.git. Jeśli proces serwera ma uprawnienia do odczytu tego katalogu, atakujący uzyska dostęp do repozytorium, do którego nie powinien mieć dostępu.

Podatność dotyczy wyłącznie aplikacji, które aktywnie wykorzystują komponent org.apache.sshd:sshd-git. [^2] Aplikacje korzystające z Apache MINA SSHD do innych celów, bez integracji z Gitem, nie są zagrożone. [^7]

Wskaźniki kompromitacji

Ta podatność nie jest związana z konkretną kampanią malware, więc nie publikujemy wskaźników takich jak adresy IP serwerów C2 (Command and Control) czy hashe plików. Wskaźnikiem jest tutaj sama obecność podatnego oprogramowania w systemie.

Zespoły deweloperskie i administratorzy powinni przeszukać swoje projekty i systemy pod kątem użycia podatnej biblioteki. Kluczowe jest zidentyfikowanie zależności w plikach konfiguracyjnych systemów budowania, takich jak pom.xml (Maven) czy build.gradle (Gradle).

# Podatny komponent (Maven/Gradle)
org.apache.sshd:sshd-git

Podatne są wszystkie wersje przed 2.18.0. [^4] Dodatkowo, problem zidentyfikowano w deweloperskich wersjach zapoznawczych od 3.0.0-M1 do 3.0.0-M3. [^5]

Co zrobić w 24-48h

Rekomendowane podejście zakłada trzy główne kroki. Działania te nie zastępują pełnego audytu bezpieczeństwa, ale stanowią pierwszą linię obrony.

  1. Identyfikacja i weryfikacja. Należy niezwłocznie przeskanować wszystkie projekty oparte o technologie Java w poszukiwaniu zależności org.apache.sshd:sshd-git. Narzędzia typu Software Composition Analysis (SCA) mogą zautomatyzować ten proces.

  2. Natychmiastowa aktualizacja. Po zidentyfikowaniu podatnych aplikacji, należy bezwzględnie zaktualizować bibliotekę do bezpiecznej wersji. Dla stabilnej gałęzi produkcyjnej jest to wersja 2.18.0. [^4] Dla zespołów pracujących na wersji deweloperskiej, wymagana jest aktualizacja do 3.0.0-M4. [^6]

  3. Wzmocnienie konfiguracji (działanie długofalowe). Niezależnie od załatania tej konkretnej luki, incydent ten podkreśla fundamentalną zasadę. Profesjonalnie zarządzany serwer Git nie powinien opierać swojej logiki dostępu wyłącznie na uprawnieniach systemu plików. [^8] Zaleca się wdrożenie dodatkowych warstw kontroli, takich jak listy kontroli dostępu (ACL) na poziomie aplikacji, szczegółowe logowanie operacji oraz regularne audyty uprawnień. Dla podmiotów kluczowych i ważnych w Polsce, objętych dyrektywą NIS2, posiadanie takich wielowarstwowych zabezpieczeń jest nie tylko dobrą praktyką, ale staje się wymogiem regulacyjnym.

Zobacz też