Katalog podatności CVE

W mise przed wersją 2026.7.14, w domyślnym trybie non-safe, mise ładuje .mise.toml [settings] z niezaufanego lokalnego projektu przed zatwierdzeniem zaufania, a strip_local_only_settings usuwa tylko pola oznaczone jako global_only. Ustawienia unix_default_file_shell_args, unix_default_inline_shell_args, windows_default_file_shell_args i windows_default_inline_shell_args nie były oznaczone jako global_only, co pozwala repozytorium zastąpić domyślne argumenty interpretera używane przez zaufane zadania bez jawnego shella, dyrektywy postinstall, operacje exec szablonów lub hooki, które korzystają z domyślnego shella. Gdy mise dołącza zaufane polecenie po argumentach interpretera kontrolowanych przez atakującego, wybrane przez atakującego polecenie może zostać wykonane jako pierwsze z uprawnieniami konta dewelopera, mimo że lokalna konfiguracja nigdy nie została zaufana.

W OmniFaces w wersjach przed 1.14.3, 2.7.33, 3.14.23, 4.7.12 i 5.4.2, CombinedResourceHandler akceptuje strukturalnie poprawne, zdeflowane i zakodowane w base64 połączone ID zasobu bez weryfikacji, czy zostało ono wydane przez serwer. Sfałszowane ID może spowodować nieograniczone wyjście po dekodowaniu, dodanie unikalnych zrekonstruowanych ID do cache'u o czasie życia procesu lub łączenie zasobów innych niż arkusze stylów i skrypty. Ponieważ jakarta.faces.RESOURCE_EXCLUDES nie jest stosowane przez tę niestandardową ścieżkę rozwiązywania, sfałszowane ID może ujawnić źródło Facelets z drzewa zasobów aplikacji webowej lub META-INF/resources. W konfiguracji z mapowaniem CDN z symbolem wieloznacznym, sfałszowane ID wybierające omnifaces.graphic może również spowodować ślepe, zależne od wdrożenia pobranie po stronie serwera, którego cel częściowo pochodzi z nagłówka Host żądania. Luka nie zapewnia dowolnego odczytu plików ani nie ustanawia SSRF o dowolnym schemacie lub celu. Wspólna awaria autentyczności pozwala na wyczerpanie pamięci i ograniczone ujawnienie zasobów.

W Angular przed wersjami 20.3.32, 21.2.24 i 22.2.0 parser URL @angular/router przechowuje numeryczne nazwy parametrów macierzy i numeryczne nazwy outletów jako właściwości na początkowo pustych obiektach JavaScript podczas renderowania po stronie serwera w Node.js. V8 może interpretować te klucze pochodzące z URL jako indeksy tablicy i alokować gęste magazyny o rozmiarze odpowiadającym wysokim wartościom numerycznym, więc powtarzające się małe segmenty ścieżki powodują nieproporcjonalne zużycie sterty na segment. Nieuwierzytelniony atakujący może wysyłać nakładające się żądania zawierające powtarzające się numeryczne parametry macierzy, gdy SSR jest włączone, router bezpośrednio parsuje URL żądania, a proxy nadrzędne zezwalają na średniki i wiele segmentów ścieżki, ostatecznie wyczerpując stertę old-space Node.js i kończąc proces roboczy SSR. Czysto klienckie aplikacje Angular nie są dotknięte.

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

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

W Gitea, notyfikator przeglądu pull request nie dołącza pull requesta do powiadomienia Actions, przez co bramka zatwierdzania dla forków nie rozpoznaje uruchomienia jako pochodzącego z forka. Zdarzenia komentarzy i zatwierdzeń/odrzuceń przeglądu mogą załadować kod workflow z forka i uruchomić go na runnerach bazowego repozytorium bez wymaganego zatwierdzenia przez opiekuna.

W Gitea, wymóg zatwierdzenia dla pierwszego kontrybutora z forka jest egzekwowany przez blokowanie zadań, ale niektóre ścieżki przejść i wysyłek nie sprawdzają ponownie wymogu zatwierdzenia. Osobne uruchomienie współdzielące grupę concurrency na poziomie zadania może anulować oczekujące zadanie i spowodować ponowne wyemitowanie i wysłanie zablokowanych zadań bez zatwierdzenia.

Podatność w util-linux w wersjach 2.17 do 2.41.6, 2.42 do 2.42.3 oraz 2.42.4 gdy używana jest legacy ścieżka mount(2) bez /proc. Ograniczone żądania mount od nie-roota walidują cel /etc/fstab przed ponownym rozwiązywaniem ścieżki. Lokalny użytkownik z niskimi uprawnieniami, autoryzowany przez wpis fstab z opcją user lub users, może użyć renameat2(RENAME_EXCHANGE) do podmiany komponentu ścieżki i przekierować autoryzowany mount do lokalizacji należącej do roota, np. montując zawartość kontrolowaną przez atakującego nad /etc/sudoers.d, uzyskując uprawnienia roota.

Podatność w util-linux w wersjach 2.39 do 2.41.4 oraz 2.42 do 2.42.1. SUID mount utility w hook_owner.c wykonuje operacje chmod() i lchown() oparte na ścieżce na wcześniej zwalidowanym celu montowania. Lokalny użytkownik z niskimi uprawnieniami, autoryzowany przez wpis /etc/fstab z opcją user lub users oraz opcją X-mount.mode, X-mount.owner lub X-mount.group, może użyć renameat2(RENAME_EXCHANGE) do wyścigu z zapisywalnym przodkiem celu i przekierować uprzywilejowaną zmianę właściciela lub trybu do ścieżki należącej do roota, potencjalnie uzyskując uprawnienia roota.

Podatność w NGINX Plus i NGINX Open Source, gdy lokalizacja używa dyrektywy alias wraz z rewrite oraz set lub return odwołującym się do zmiennej $request_filename. Alternatywnie, ten sam efekt można osiągnąć, gdy $request_filename jest używany w dyrektywie formatu logu dostępu. 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 @offactory/compress-fonts przed wersją 1.1.1 zawiera wstrzykiwanie poleceń systemu operacyjnego, umożliwiając atakującym wykonanie poleceń powłoki poprzez dostarczenie plików czcionek z spreparowanymi nazwami. Ścieżki czcionek są interpolowane bez cudzysłowów do polecenia FontForge uruchamianego przez child_process.execSync, więc metaznaki powłoki w nazwach plików wykonują polecenia z uprawnieniami procesu Node.js.