Katalog podatności CVE

Nezha Monitoring w wersjach od 2.2.7 do 2.2.11 zawiera błąd wyścigu w ServiceSentinel.worker, gdzie wskaźniki serviceStatusToday i serviceCurrentStatusData są używane bez ponownej walidacji po usunięciu usługi przez ServiceSentinel.Delete. Współbieżne zgłoszenie wyników TCP/ICMP i usunięcie usługi powoduje dereferencję pustego wskaźnika, a brak interceptora odzyskiwania w serwerze gRPC prowadzi do zatrzymania całego procesu dashboardu.

NGINX Plus i NGINX Open Source skonfigurowane z ssl_session_cache shared:name:size bez jawnych dyrektyw ssl_session_ticket_key do automatycznej rotacji kluczy biletów sesji SSL pozwalają zdalnemu nieuwierzytelnionemu atakującemu na fałszowanie sesji klienta SSL w nieprzewidywalny sposób. Atakujący może wykorzystać tę podatność do obejścia weryfikacji certyfikatów klienta.

NGINX Gateway Fabric skonfigurowany z Gateway CRD i uwierzytelnionym połączeniem gRPC z NGINX Agent pozwala uwierzytelnionemu atakującemu z dostępem do konta usługi podszyć się pod połączenie gRPC agenta i odczytać prywatne klucze TLS wdrożeń Gateway w innej przestrzeni nazw.

NGINX Plus i NGINX Open Source mają podatność w module ngx_http_v3_module. Przy używaniu HTTP/3 z dyrektywą proxy_request_buffering on nieuwierzytelniony atakujący może wstrzyknąć dane do przekazywanego żądania.

W Gitea mechanizm obsługi załączników pomija sprawdzanie własności między repozytoriami dla załączników utworzonych przed 16 stycznia 2026 i sprawdza uprawnienia względem repozytorium z adresu URL żądania. Nieuwierzytelniony atakujący znający UUID prywatnego załącznika może pobrać jego zawartość przez ścieżkę publicznego repozytorium.

Gdy w Gitea włączone jest logowanie OpenID, aplikacja przetwarza nieuwierzytelnione parametry asercji i wysyła żądanie HTTP POST do wskazanego przez wywołującego punktu końcowego dostawcy OpenID podczas weryfikacji. Atakujący kontroluje cel i większość treści formularza, co umożliwia interakcję z wewnętrznymi usługami HTTP osiągalnymi z serwera Gitea.

W Gitea punkt końcowy trybu dostępu współpracy akceptuje tryb Owner od uwierzytelnionego współpracownika repozytorium z uprawnieniami Admin. Współpracownik może podnieść swoje uprawnienia z Admin do Owner i wykonywać operacje zastrzeżone dla właściciela, w tym przenieść repozytorium na własne konto.

Gitea w obsłudze przesyłania pakietów Maven wczytuje przesłane sumy kontrolne w całości do pamięci i kończy przetwarzanie przed egzekwowaniem limitów rozmiaru pakietów. Uwierzytelniony użytkownik z uprawnieniem do publikowania pakietów może przesłać zbyt duże ciało żądania do punktu końcowego sumy kontrolnej, omijając limit i wyczerpując pamięć serwera.

Gitea używa niespójnych predykatów widoczności repozytoriów, a warunek stosowany przez niektóre punkty końcowe listowania repozytoriów dopuszcza repozytoria, których właściciele są ukryci przed przeglądającym. Listowania ujawniają metadane repozytoriów, mimo że bezpośrednie trasy poprawnie odmawiają dostępu z odpowiedzią 404.

Gitea nie ogranicza długości pola gitignores przyjmowanego przez formularze tworzenia repozytoriów oraz API. Inicjalizacja repozytorium dzieli to pole na nazwy szablonów, wielokrotnie odczytuje wskazane szablony i buforuje ich zawartość w pamięci. Atakujący mogący tworzyć repozytoria może przesłać zbyt dużą wartość, aby wzmocnić odczyty szablonów i zużycie pamięci, pogarszając dostępność.

Endpoint Gitea odpowiedzialny za odznakę statusu workflow Actions nie egzekwuje zakresu odczytu repozytorium ani ograniczenia wyłącznie do publicznych repozytoriów dla tokenu uwierzytelniającego żądanie. Token bez uprawnienia read:repository lub ograniczony do repozytoriów publicznych może pobrać najnowszy status workflow prywatnego repozytorium dostępnego dla jego właściciela. Ujawnia to prywatny status workflow poza zamierzonymi uprawnieniami delegowanymi tokenu.

Endpoint Gitea do renderowania znaczników repozytorium rozwiązuje odwołania do pull requestów w tym samym repozytorium bez egzekwowania uprawnienia Pull Requests przeglądającego. Członek z dostępem tylko do Wiki w prywatnym repozytorium może wysłać żądanie podglądu znaczników i pobrać tytuł oraz ikonę stanu prywatnego pull requesta, mimo braku dostępu do Issues i Pull Requests. Ujawnia to metadane pull requestów w poprzek uprawnień jednostek repozytorium.

API listy organizacji w Gitea nie egzekwuje zakresu tokenu read:organization. Token ograniczony do innej kategorii, np. read:misc, może pobrać metadane organizacji widoczne dla jego właściciela. W przypadku tokenu administratora serwisu odpowiedź może zawierać organizacje Limited i prywatne, omijając zamierzone ograniczenie delegowanego dostępu tokenu.

Współdzielony helper porównywania w Gitea pomija sprawdzenie dostępu tokenu do repozytorium stosowane przy aktualizacji pull requestów. Token public-only z zakresem read:repository może przeprowadzić porównanie lub utworzenie pull requesta przez publiczne repozytorium bazowe i pobrać historię commitów oraz różnice z prywatnego repozytorium head dostępnego dla właściciela tokenu. Omija to ograniczenie public-only tokenu; nie usuwa to podstawowych sprawdzeń uprawnień repozytorium konta.

Gitea tworzy katalogi i skrypty hooków Git po stronie serwera z uprawnieniami 0777 i polega na umask procesu w celu ograniczenia dostępu. Przy permisywnym umask, takim jak 0000 lub 0002, inny lokalny użytkownik mogący dotrzeć do magazynu repozytorium może zmodyfikować hook lub dodać plik wykonywalny do zapisywalnego katalogu hooków. Późniejsza operacja Git może wykonać ten plik jako konto usługi Gitea.

API migracji repozytoriów w Gitea akceptuje token public-only, gdy żądanie określa utworzenie prywatnego repozytorium. Delegowany token przeznaczony do działania tylko na zasobach publicznych może utworzyć prywatne repozytorium i zadanie migracji na koncie autoryzującym lub w organizacji, w której ten użytkownik ma niezbędne uprawnienia. Zwykła ścieżka tworzenia prywatnego repozytorium odrzuca ten sam token, ale ścieżka migracji pomija to ograniczenie.

API tworzenia repozytoriów organizacji w Gitea wymaga zakresu write:organization, ale pomija zakres tokenu write:repository wymuszany przez inne trasy tworzenia repozytoriów. Token osobistego dostępu lub token aplikacji OAuth bez zakresu zapisu do repozytoriów może zatem tworzyć repozytoria należące do organizacji, jeśli autoryzujący użytkownik ma do tego uprawnienia. Omija to granicę delegowanego zakresu tokenu, pozostając jednocześnie ograniczonym uprawnieniami organizacyjnymi użytkownika.

Endpointy API Gitea do listy kluczy SSH i GPG użytkownika pomijają sprawdzenie widoczności profilu stosowane przez ich odpowiedniki webowe. Konto o ograniczonym dostępie może pobrać klucze publiczne, tytuły kluczy, odciski palców oraz adresy e-mail osadzone w GPG należące do użytkowników o widoczności Limited. Ujawnienie dotyczy materiału kluczy publicznych i powiązanych metadanych, a nie prywatnych kluczy kryptograficznych.

Ścieżki wyszukiwania zgłoszeń w API i interfejsie webowym Gitea nie traktują kont o ograniczonym dostępie jako anonimowych przeglądających przy ocenie właścicieli repozytoriów o widoczności Limited. Użytkownik o ograniczonym dostępie może wyszukiwać i pobierać tytuły oraz treści zgłoszeń, które powinny być ukryte przez politykę widoczności właściciela. Dopasowanie słów kluczowych może również ujawnić, że ukryta treść zgłoszenia lub komentarze zawierają podany termin.

Handlery API Gitea do kanału aktywności i mapy cieplnej wkładu nie stosują sprawdzenia widoczności profilu dla kont o ograniczonym dostępie przeglądających użytkowników o widoczności Limited. Użytkownik o ograniczonym dostępie może pobrać zapisy aktywności i znaczniki czasu wkładu, których odmawiają odpowiadające ścieżki profilu. Ujawniona aktywność może obejmować nazwy repozytoriów, wiadomości commitów oraz zdarzenia zgłoszeń lub pull requestów powiązane z kwalifikującą się aktywnością w publicznych repozytoriach.