CVE-2026-44595 w YAMCS: luka w IAM API umożliwia enumerację użytkowników i grup

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

W projekcie YAMCS ujawniono podatność oznaczoną jako CVE-2026-44595, która dotyczy komponentu yamcs-core w wersjach wcześniejszych niż 5.12.7. Problem wynika z niewłaściwej kontroli autoryzacji w interfejsie IAM API i prowadzi do ujawnienia informacji o użytkownikach, grupach oraz statusie uprzywilejowania kont.

Podatność ma charakter information disclosure i nie wymaga uprawnień administracyjnych. Wystarczy konto uwierzytelnionego użytkownika o niskim poziomie dostępu, aby odpytywać wybrane endpointy administracyjne i pozyskiwać metadane pomocne w dalszym rozpoznaniu środowiska.

W skrócie

Podatność została oznaczona jako CVE-2026-44595.
Dotyczy yamcs-core w wersjach wcześniejszych niż 5.12.7.
Źródłem problemu jest brak właściwego egzekwowania uprawnienia administracyjnego w IAM API.
Skutkiem jest możliwość enumeracji użytkowników, grup i statusu superusera.
Luka nie prowadzi bezpośrednio do wykonania kodu, ale znacząco ułatwia rekonesans.

Kontekst / historia

YAMCS jest platformą wykorzystywaną do przetwarzania danych telemetrycznych oraz wspierania operacji w środowiskach technicznych, gdzie poprawna separacja uprawnień ma duże znaczenie bezpieczeństwa. W takich systemach nawet pozornie ograniczony wyciek informacji administracyjnych może zwiększyć ekspozycję na kolejne etapy ataku.

Publiczny opis podatności pojawił się pod koniec maja 2026 roku i wskazał, że problem obejmuje wersje wcześniejsze niż 5.12.7. Opublikowane materiały opisują brak wymuszenia uprawnienia SystemPrivilege.ControlAccess dla wybranych metod IAM API, co pozwala zwykłym użytkownikom uzyskiwać odpowiedzi z endpointów przeznaczonych dla funkcji administracyjnych.

Analiza techniczna

Sednem problemu jest broken access control po stronie backendu. Mechanizm autoryzacji nie wymusza w wybranych miejscach odpowiedniego sprawdzenia uprawnień, mimo że dane zwracane przez API mają charakter administracyjny. W rezultacie poprawnie zalogowany użytkownik może odczytać informacje, które powinny być ograniczone do uprzywilejowanych operatorów.

W opisie podatności wskazano następujące ścieżki jako podatne:

GET /api/iam/users
GET /api/iam/users/{name}
GET /api/iam/groups
GET /api/iam/groups/{name}

Przykładowy scenariusz ataku jest prosty. Atakujący loguje się na konto o niskich uprawnieniach, uzyskuje token dostępu, a następnie wysyła żądania do endpointów IAM. Jeśli instancja pozostaje podatna, serwer zwraca poprawne odpowiedzi z danymi użytkowników i grup, zamiast odmówić dostępu kodem 403 Forbidden.

Z punktu widzenia bezpieczeństwa takie informacje mogą być bardzo cenne. Umożliwiają identyfikację kont uprzywilejowanych, mapowanie struktury grup, rozpoznanie modelu delegacji dostępu oraz przygotowanie bardziej skutecznych działań socjotechnicznych lub prób wykorzystania poświadczeń.

Konsekwencje / ryzyko

Choć luka nie daje bezpośrednio możliwości przejęcia systemu ani modyfikacji konfiguracji, jej wpływ operacyjny nie powinien być bagatelizowany. Enumeracja użytkowników i grup obniża koszt rekonesansu po stronie atakującego i zwiększa prawdopodobieństwo powodzenia kolejnych działań ofensywnych.

Ułatwienie rozpoznania wewnętrznego po uzyskaniu dostępu do zwykłego konta.
Identyfikacja użytkowników z podwyższonymi uprawnieniami.
Wsparcie dla phishingu ukierunkowanego, password sprayingu i credential stuffingu.
Ujawnienie struktury organizacyjnej lub sposobu zarządzania dostępem.
Zwiększenie ryzyka lateral movement w środowiskach zintegrowanych.

W środowiskach operacyjnych i telemetrycznych nawet wyciek metadanych może mieć wymierne skutki, szczególnie gdy system jest dostępny z mniej zaufanych segmentów sieci lub współdzielonych stref laboratoryjnych. Dlatego podatność należy traktować jako istotny problem związany z kontrolą dostępu.

Rekomendacje

Najważniejszym działaniem naprawczym jest aktualizacja yamcs-core do wersji 5.12.7 lub nowszej. Organizacje, które nie mogą wdrożyć poprawki natychmiast, powinny zastosować dodatkowe zabezpieczenia ograniczające możliwość nadużycia podatnych endpointów.

Niezwłocznie zaktualizować instancje YAMCS do wersji zawierającej poprawkę.
Ograniczyć dostęp do IAM API wyłącznie do zaufanych segmentów sieci.
Zweryfikować, czy konta o niskich uprawnieniach nie mają dostępu do danych administracyjnych.
Monitorować logi pod kątem wywołań endpointów /api/iam/users i /api/iam/groups.
Przeprowadzić przegląd konfiguracji RBAC oraz przypisania ról i uprawnień.
Usunąć lub ograniczyć konta testowe, serwisowe i rzadko używane.
Wzmocnić uwierzytelnianie dla kont mających dostęp do środowisk YAMCS.
Po aktualizacji wykonać testy regresyjne i potwierdzić, że nieuprzywilejowani użytkownicy otrzymują 403 Forbidden.

Warto również potraktować ten przypadek jako sygnał do szerszego audytu autoryzacji w API. Błędy kontroli dostępu często nie występują pojedynczo i mogą obejmować kilka metod lub modułów aplikacji.

Podsumowanie

CVE-2026-44595 to podatność w YAMCS związana z niewłaściwym egzekwowaniem autoryzacji w IAM API. Uwierzytelniony użytkownik o niskich uprawnieniach może uzyskać informacje o kontach, grupach i statusie uprzywilejowania, co znacząco ułatwia rekonesans i przygotowanie dalszych działań ofensywnych.

Mimo że luka nie prowadzi bezpośrednio do zdalnego wykonania kodu, jej znaczenie dla bezpieczeństwa środowiska pozostaje realne. Kluczowe działania to szybka aktualizacja do wersji 5.12.7 lub nowszej, ograniczenie ekspozycji interfejsów IAM oraz weryfikacja poprawności egzekwowania zasad RBAC.