Katalog podatności CVE

Podatność w Prowler (wersje 5.4.0 do 5.35.0) pozwala nieuwierzytelnionemu atakującemu na przejęcie konta użytkownika, który nie ukończył jeszcze rejestracji. Dzieje się tak, ponieważ logowanie przez Google lub GitHub jest automatycznie łączone z istniejącym lokalnym kontem o tym samym adresie e-mail, bez weryfikacji, że adres należy do tej samej osoby. Atakujący może zarejestrować konto z adresem e-mail ofiary, a następnie uzyskać trwały dostęp do jej danych, w tym poświadczeń chmury, wyników skanów i członkostw w dzierżawach.

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 Plus i NGINX Open Source mają podatność w module ngx_http_core_module. Gdy asynchroniczne I/O plików (AIO) jest włączone w niektórych konfiguracjach, przetwarzanie strony Server Side Includes (SSI) zawierającej polecenia „include virtual” może wywołać Use-After-Free (UAF) w procesie roboczym NGINX. Może to spowodować uszkodzenie pamięci lub awarię procesu roboczego. Dodatkowo atakujący mogą wykonać kod w systemach z wyłączonym Address Space Layout Randomization (ASLR) lub gdy atakujący może obejść ASLR.

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.

Podatność w F5 NGINX Kubernetes Ingress Controller (NIC) przy użyciu polityki ExternalAuth lub zewnętrznego uwierzytelniania Ingress. Nagłówki X-Forwarded-Prefix, X-Forwarded-URI, X-Original-URI i X-Forwarded-Method są przekazywane bez sanityzacji do wewnętrznego podżądania uwierzytelniającego, co pozwala nieuwierzytelnionemu atakującemu na podszywanie się pod atrybuty żądania oceniane przez zewnętrznego dostawcę uwierzytelniania.

Podatność w NGINX Plus i NGINX Open Source, gdy dyrektywa map używa dopasowania regex, a dyrektywa root lub format logu dostępu odwołuje się do zmiennych przechwytywania regex przed zmienną wyjściową mapy. Nieuwierzytelniony atakujący może wysłać spreparowane żądania HTTP, powodując przepełnienie sterty w procesie roboczym NGINX, co prowadzi do restartu lub potencjalnie wykonania kodu.

Podatność w NGINX Gateway Fabric, gdzie pole spec.basic.realm (i spec.jwt.realm) w namespaced AuthenticationFilter jest renderowane bez escape i walidacji do wspólnego nginx.conf jako auth_basic "<realm>";. Uwierzytelniony atakujący z dostępem do namespace może wstrzyknąć dowolne dyrektywy NGINX do konfiguracji warstwy danych bramy.

Niekompletna poprawka dla CVE-2026-12996. Use-after-free w OpenVPN 2.6.0 do 2.6.22 oraz 2.7_alpha1 do 2.7.7 pozwala zdalnym uwierzytelnionym peerom na potencjalne spowodowanie denial-of-service lub wycieku pamięci poprzez spreparowane pakiety podczas promocji lub wygaśnięcia sesji TLS.

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.

W Gitea token z zakresem write:user może zarejestrować kontrolowany przez atakującego klucz publiczny SSH na koncie właściciela tokenu. Żądania API podpisane odpowiadającym kluczem prywatnym uwierzytelniają się jako to konto przez HTTP Signature bez informacji o zakresie tokenu API, co pomija sprawdzanie zakresu na poziomie trasy.

W Gitea Runner opcje kontenera kontrolowane przez workflow są przekazywane do konfiguracji kontenera zadań Docker, mimo że tryb uprzywilejowany jest wyłączony. Ustawienia przestrzeni nazw hosta, rozszerzone uprawnienia i nadpisania profilu bezpieczeństwa mogą pozostać aktywne, umożliwiając dostęp do przestrzeni nazw hosta i wykonanie poleceń jako root na hoście runnera.

W Gitea lokalne pliki wielokrotnego użytku workflow są rozwiązywane z commita head forka, gdy zaufany workflow gałęzi bazowej jest uruchamiany dla zdarzenia pull_request_target. Autor forka może zmodyfikować przywoływany workflow wielokrotnego użytku, aby wykonać kontrolowany przez atakującego kod z sekretami repozytorium i organizacji dostępnymi dla tego zdarzenia.

Gitea podstawia adres URL pochodzący z pola Context znaczników do szablonów poleceń zewnętrznego renderera bez escapowania ścieżki referencyjnej przed podziałem argumentów w stylu powłoki. Spreparowany Context może wstrzyknąć dodatkowe argumenty renderera, w tym opcje ładujące wykonywalne pliki filtrów. W środowiskach używających podatnego zewnętrznego renderera, takiego jak pandoc, użytkownik mogący umieścić plik filtra w dostępnej ścieżce może doprowadzić do jego wykonania jako konto usługi Gitea, a publiczny endpoint znaczników repozytorium może być osiągalny bez uwierzytelnienia.

Handler OpenID Connect w Gitea akceptuje hasło użytkownika bez wymuszenia weryfikacji zarejestrowanego TOTP lub WebAuthn przed zakończeniem logowania i powiązaniem identyfikatora OpenID. Gdy logowanie OpenID jest włączone, atakujący znający hasło ofiary może uzyskać sesję i powiązać kontrolowany przez siebie identyfikator. Atakujący może następnie logować się przez ten identyfikator bez hasła ofiary ani drugiego czynnika, a zmiana hasła nie usuwa powiązania.

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ść.