Katalog podatności CVE

Podatność eskalacji uprawnień w agencie OnGuard Linux ClearPass Policy Manager pozwala złośliwym użytkownikom na podniesienie uprawnień do root na dotkniętym kliencie Linux.

Podatność wstrzykiwania komend w API ClearPass Policy Manager pozwala uwierzytelnionemu zdalnemu atakującemu na eskalację uprawnień i uzyskanie administracyjnej kontroli nad systemem.

Podatność wstrzykiwania komend w oprogramowaniu klienckim ClearPass Policy Manager pozwala atakującemu, który może dostarczyć spreparowane dane wejściowe, na wykonanie dowolnych komend z podwyższonymi uprawnieniami na dotkniętym hoście.

Podatność path traversal w interfejsie wiersza poleceń ClearPass Policy Manager pozwala uwierzytelnionemu zdalnemu atakującemu o niskich uprawnieniach na wykonanie dowolnego kodu z podwyższonymi uprawnieniami na systemie operacyjnym.

Podatność w interfejsie zarządzania opartym na sieci ClearPass Policy Manager pozwala nieuwierzytelnionemu zdalnemu atakującemu na przeprowadzenie ataku XSS (przechowywanego) przeciwko użytkownikowi administracyjnemu, co umożliwia wykonanie dowolnego skryptu w przeglądarce ofiary.

Podatność nieprawidłowej kontroli dostępu w aplikacji klienckiej Android dla HPE Networking ClearPass Policy Manager pozwala nieuwierzytelnionemu zdalnemu atakującemu, przy interakcji użytkownika, na uzyskanie wrażliwych informacji od użytkownika.

Podatność eskalacji uprawnień w API AOS-S pozwala uwierzytelnionemu użytkownikowi z uprawnieniami tylko do odczytu na eskalację uprawnień i uzyskanie administracyjnego dostępu do systemu.

Gitea sprawdza nazwę hosta migracji repozytorium względem list dozwolonych i zablokowanych przed wywołaniem Git, ale podproces Git niezależnie rozwiązuje nazwę hosta podczas łączenia. Atakujący, który może rozpocząć migrację i kontrolować DNS celu, może zmienić adres między walidacją a połączeniem, aby dotrzeć do zablokowanego wewnętrznego adresu. Dotknięta ścieżka to operacja klonowania Git; walidacja w dialerze klienta HTTP migracji nie chroni niezależnie łączącego się podprocesu Git.

Biblioteka yawkat LZ4 Java w wersjach od 1.7.0 do 1.11.4 zawiera podatność polegającą na niebezpiecznym tworzeniu pliku tymczasowego. Atakujący z dostępem do wspólnego katalogu tymczasowego może podmienić plik biblioteki natywnej przed jej załadowaniem, co może prowadzić do wykonania kodu w kontekście ofiary.

Biblioteka StableLib przed wersją 2.0.4 zawiera podatność w dekoderze CBOR, która pozwala atakującemu na wstrzyknięcie klucza '__proto__' do obiektu JavaScript. Powoduje to nadpisanie prototypu obiektu, co może prowadzić do podejmowania decyzji bezpieczeństwa na podstawie danych kontrolowanych przez atakującego.

Biblioteka StableLib przed wersją 2.0.4 zawiera podatność w dekoderze CBOR, która nie ogranicza głębokości zagnieżdżenia struktur danych. Zbyt głęboka struktura może spowodować przepełnienie stosu JavaScript, prowadząc do awarii procesu lub usługi.

Gitea sprawdza początkowy zdalny URL dla mirrorów push, zdalnych kontroli wiki i pobierania głów pull requestów migracji, ale późniejsze operacje Git podążają za przekierowaniami HTTP bez ponownej walidacji celu. Administrator repozytorium używający dozwolonego punktu końcowego, który przekierowuje, może sprawić, że klient Git Gitea wyśle żądania na adres, który polityka hostów wychodzących w przeciwnym razie zablokowałaby. Wpływ zależy od skonfigurowanej polityki i wewnętrznych usług dostępnych z serwera.

Gitea Actions blokuje zadania przebiegów workflow z pull requestów od pierwszego kontrybutora z forka, dopóki opiekun nie zatwierdzi przebiegu. Ścieżka ponownego uruchomienia wymagała tylko, aby przebieg był zakończony, i budowała zadania nowej próby bez uwzględnienia oczekującego zatwierdzenia, więc gdy użytkownik z uprawnieniami zapisu do Actions anulował przebieg oczekujący na zatwierdzenie, a następnie uruchomił go ponownie, nowe zadania zostały utworzone jako oczekujące, a nie zablokowane, podczas gdy przebieg nadal rejestrował, że wymagane jest zatwierdzenie. Anulowanie i ponowne uruchamianie starych kontroli z forka jest rutynową czynnością, która nie obejmuje kontroli zatwierdzenia, więc tam, gdzie Actions jest włączone i zarejestrowany jest pasujący runner, kod workflow pobrany z głowy pull requesta z forka może zostać uruchomiony na runnerach repozytorium bez wyraźnego zatwierdzenia.

Użytkownik, który może otworzyć pull request z forka, może umieścić treść workflow ze współdzieloną grupą współbieżności na poziomie przebiegu w przebiegu Gitea Actions oczekującym na zatwierdzenie. Gdy późniejszy przebieg w tej grupie anuluje zablokowane zadanie, przebieg staje się terminalny, ale nadal oznaczony jako wymagający zatwierdzenia. Jeśli opiekun później zatwierdzi przebieg, Gitea przekazał już anulowane zadanie z powrotem przez przygotowanie współbieżności, ustawił je na oczekujące i umożliwił przejęcie przez pasujący runner, wykonując kod workflow kontrolowany przez fork. Wykorzystanie wymaga późniejszego zatwierdzenia przez opiekuna, włączonych Actions i runnera akceptującego zadania repozytorium.

Gdy wstawiano przebieg Gitea Actions, starsze przebiegi w tej samej grupie współbieżności na poziomie workflow były anulowane bez sprawdzania, czy nowy przebieg nadal wymaga zatwierdzenia. Ponieważ przebiegi z pull requestów z forków są wstawiane pod repozytorium bazowym, użytkownik, który może otworzyć pull request z forka, może anulować zaufane trwające przebiegi, które dzielą grupę współbieżności z włączoną opcją `cancel-in-progress`, bez zatwierdzenia i bez uruchamiania żadnego kodu. Na self-hosted runnerach może to przerwać wdrożenia i pozostawić częściowy stan.

Zmiana uprawnień zespołu organizacji przez API z tylko polem `permission` nie odbudowywała dostępu per-jednostka zespołu, a żądany poziom nie był stosowany jako limit. Po tym, jak właściciel organizacji zdegradował zespół, na przykład z admina do read, członkowie zespołu zachowali poprzednie uprawnienia jednostek, w tym dostęp do zapisu do repozytoriów zespołu. Formularz internetowy nie był dotknięty.

Elasticsearch zawiera podatność polegającą na obejściu autoryzacji w modelu Remote Cluster Security (RCS) 2.0. Atakujący z ważnym kluczem API może wysłać specjalnie spreparowane żądanie cross-cluster search, które autoryzuje dostęp do jednego indeksu, ale faktycznie operuje na innym, nieautoryzowanym indeksie, ujawniając jego dane.

Elasticsearch zawiera podatność nieprawidłowej autoryzacji w opcjonalnym uprawnieniu delegowanym, które pozwala administratorowi na ograniczone zarządzanie rolami. Z powodu niepełnego egzekwowania zakresu, użytkownik z tym uprawnieniem może rozszerzyć swój dostęp do indeksów, które powinny pozostać ograniczone, w tym do wewnętrznych danych bezpieczeństwa.

Kibana zawiera podatność obejścia autoryzacji w procesie instalacji pakietów Fleet. Użytkownik z delegowanymi uprawnieniami do zarządzania pakietami może przejąć identyfikator strumienia danych należący do innego dzierżawcy, przekierowując dane ofiary do infrastruktury kontrolowanej przez atakującego.

Punkty dostępowe Arista Wi-Fi zawierają podatność uszkodzenia pamięci w przewodowych interfejsach sieciowych. Nieuwierzytelniony atakujący z dostępem do tego samego segmentu sieci może doprowadzić do awarii usługi czujnika lub potencjalnie zdalnego wykonania kodu.