Katalog podatności CVE

W dotkniętych wersjach Nexus Repository 3 endpoint wykonania skryptów (POST /service/rest/v1/script/{name}/run) nie weryfikował, czy wykonanie skryptów zostało administracyjnie wyłączone. Konto z uprawnieniem do wykonywania skryptów mogło nadal uruchamiać wcześniej utworzone skrypty nawet po ustawieniu nexus.scripts.allowCreation=false, co podważa oczekiwanie, że to ustawienie całkowicie blokuje wykonywanie skryptów.

W Nexus Repository 3 wykryto podatność ujawniania wrażliwych informacji w API odczytu możliwości (capability read API). Konto posiadające uprawnienie nexus:capabilities:read może pobrać jawny tekst wspólnego sekretu skonfigurowanego w możliwości webhook, który powinien być maskowany we wszystkich odpowiedziach API. Problem dotyczy wersji od 3.2.0 do 3.95.x i został naprawiony w wersji 3.96.0.

W Sonatype Nexus Repository 3 wykryto wadę autoryzacji w punkcie końcowym REST API szczegółów repozytorium (GET /service/rest/v1/repositories/{repositoryName}). Konto posiadające uprawnienie odczytu lub przeglądania w repozytorium grupowym mogło pobrać metadane repozytoriów członkowskich, na które nie miało bezpośredniego uprawnienia, poprzez bezpośrednie żądanie do punktu końcowego z nazwą repozytorium członkowskiego. Dla repozytoriów proxy ujawniane metadane obejmują skonfigurowany zdalny adres URL, co może ujawnić wewnętrzne nazwy hostów.

Użytkownik z uprawnieniami do wdrażania artefaktów w hostowanym repozytorium Maven może przesłać plik POM zawierający nadmiernie duże pole metadanych. Powoduje to trwałą awarię prób wyświetlenia listy lub przeglądania komponentów tego repozytorium, dopóki administrator nie naprawi danych. Tylko to repozytorium jest dotknięte; inne repozytoria i ogólna kondycja serwera pozostają bez zmian.

W Submariner w trybie cert-auth konfiguracja połączenia jest budowana z niesprawdzonych ciągów znaków z definicji CRD. Złośliwy klaster może opublikować CableName zawierający znaki nowej linii i dyrektywy ipsec.conf, co pozwala na wstrzyknięcie dowolnych parametrów konfiguracyjnych lub wykonanie poleceń przez hooki leftupdown, prowadząc do zdalnego wykonania kodu jako root na węźle bramy.

Boruta, samodzielny serwer autoryzacyjny implementujący OAuth 2.0 i OpenID Connect, przed wersją 0.10.0 logował wrażliwe wartości w dziennikach zdarzeń biznesowych. Mogły to być tokeny dostępu, odświeżania, autoryzacyjne, agenta, kody direct-post, tokeny ID, VP oraz tokeny przesyłane do punktów introspection lub revocation. Osoba z dostępem do logów mogła odzyskać te poświadczenia i używać ich do wygaśnięcia lub unieważnienia.

W wersjach PREVAIL przed 0.2.4 weryfikator eBPF akceptuje instrukcje ALU32 ADD i SUB działające na rejestrach typu wskaźnik bez sprawdzania flagi is64. Ponieważ arytmetyka ALU32 zeruje górną połowę 32-bitowego wyniku, górna część wskaźnika jest niszczona w czasie wykonania, a PREVAIL oznacza program jako bezpieczny. Każdy, kto może przesłać program eBPF do weryfikacji, może wygenerować program, który przechodzi weryfikację, ale powoduje błędy w czasie wykonania. Problem naprawiono w wersji 0.2.4.

W weryfikatorze eBPF PREVAIL przed wersją 0.2.4 abstrakcyjny transformer traktuje zapisy przez rejestr bazowy typu T_CTX jako cichą operację no-op. Atakujący może stworzyć program eBPF, który nadpisuje pole kontekstu (np. ctx->data), przeładowuje je jako T_PACKET i dereferencjonuje adres kontrolowany przez atakującego, a PREVAIL uzna program za bezpieczny.

W weryfikatorze eBPF PREVAIL przed wersją 0.2.4 funkcja EbpfTransformer::add() pomija aktualizacje offsetu, gdy rejestr docelowy ma niejednoznaczny zestaw typów. Kolejne sprawdzenia granic używają nieaktualnego offsetu i akceptują dostęp do pamięci poza zakresem, przez co spreparowany program BPF przechodzi weryfikację, mimo że w czasie wykonania uszkodziłby pamięć.

Framework Joro przed wersją 1.1.1 w domyślnym trybie proxy udostępnia lokalne API na 127.0.0.1:9090 bez uwierzytelnienia i z polityką CORS na wildcard. Złośliwa strona internetowa może wysyłać żądania do wrażliwych endpointów, w tym przesyłać natywną wtyczkę i wywołać restart, co prowadzi do zdalnego wykonania kodu jako użytkownik operatora.

DSpace, aplikacja repozytoryjna, w wersjach od 8.0-rc1 do przed 8.4, od 9.0-rc1 do przed 9.3 oraz od 10-rc1 do przed 10.0, zawiera podatność na path traversal w usłudze COAR Notify / LDN. Atakujący musi mieć już uprawnienia administratora DSpace. Podczas odczytu pliku wejściowego wzorca (template) używanego do generowania wiadomości LDN, klasa LDN nie sprawdza path traversal ani nie ogranicza szablonów do znanej ścieżki bazowej. Może to pozwolić na odczyt i interpretację niezaufanego pliku z innego miejsca w systemie plików jako szablon Apache Velocity.

DSpace w wersjach od 8.0-rc1 do przed 8.4, od 9.0-rc1 do przed 9.3 oraz 10-rc1 umożliwia zdalne wykonanie kodu (RCE) poprzez szablony Velocity używane do komunikatów COAR Notify/LDN. Problem naprawiono w wersjach 8.4, 9.3 i 10.0.

DSpace, przed wersjami 7.6.7, 8.4, 9.3 i 10.0, w funkcji Curation Task pozwala na użycie ścieżki wyjściowej przez parametr -r, która nie jest ograniczona do żadnej konkretnej ścieżki bazowej. Oznacza to, że każda ścieżka zapisywalna przez użytkownika DSpace (często 'tomcat') jest dozwolona. Stanowi to podatność na path traversal w skrypcie curate.

DSpace, przed wersjami 7.6.7, 8.4, 9.3 i 10.0, podczas ingestii zagregowanego zasobu ORE przez URI (przy użyciu OAI-ORE Harvester), Crosswalk ORE Ingestion nie waliduje schematu URI. Może to pozwolić na lokalne dołączanie plików poprzez złośliwe ścieżki, takie jak file:///etc/passwd. Atakujący musi mieć już uprawnienia administratora kolekcji w DSpace.

Boruta przed wersją 0.10.0 w kontrolerze UserSettingsController.update/2 atomizuje każdy klucz z ciała żądania przez String.to_atom/1 przed walidacją. Ponieważ String.to_atom trwale internuje atomy w tablicy atomów BEAM (domyślnie 1 048 576 atomów), każdy uwierzytelniony użytkownik może wysłać PUT /users/settings z nowymi kluczami, wyczerpując globalną tablicę atomów. Gdy tablica jest pełna, BEAM przerywa działanie, powodując awarię całego serwera OIDC. Problem naprawiono w wersji 0.10.0.

Skaner agentverus-scanner nie analizuje skompilowanych plików bytecode Pythona w katalogach towarzyszących, co pozwala atakującym ominąć skanowanie bezpieczeństwa poprzez umieszczenie złośliwych wpisów __pycache__ obok nieszkodliwych plików źródłowych. Atakujący mogą wykonać dowolny bytecode Pythona podczas importu, podczas gdy skaner raportuje certyfikowany werdykt z wysokimi wynikami zaufania.

claude-skill-antivirus nie analizuje plików wykonywalnych podczas skanowania lokalnych katalogów umiejętności, czytając tylko SKILL.md i ignorując kod Pythona, bytecode i inne artefakty w katalogu scripts. Atakujący mogą rozpowszechniać umiejętności ze złośliwym kodem w plikach innych niż manifest, które otrzymują ocenę BEZPIECZNY z wynikiem zaufania 100/100, mimo że zawierają nieprzeanalizowane ładunki wykonywalne.

Komponent skill-scan w Tencent AI-Infra-Guard wyklucza skompilowane pliki bytecode Pythona z analizy, twardo kodując katalogi __pycache__ i rozszerzenia .pyc/.pyo/.pyd na listach pomijania w wielu powierzchniach skanowania. Atakujący mogą rozpowszechniać umiejętności z nieszkodliwymi plikami źródłowymi Pythona obok złośliwego skompilowanego bytecode, który wykonuje się przy imporcie, podczas gdy skaner raportuje bezpieczny werdykt, umożliwiając wykonanie kodu po instalacji umiejętności przez operatorów.

Astro to framework webowy dla stron opartych na treści. Przed wersją 7.2.4, Astro usuwał skonfigurowaną ścieżkę bazową (base path) z nazw ścieżek żądań za pomocą sprawdzenia prefiksu bez weryfikacji granicy segmentu ścieżki. Przy bazie "/app", żądanie do "/appX/admin" wewnętrznie rozwiązywało się do chronionej trasy "/admin", podczas gdy middleware obserwował "/appX/admin" w context.url.pathname. W aplikacjach autoryzujących trasy z prefiksem bazowym przez sprawdzanie context.url.pathname, nieuwierzytelniony zdalny atakujący mógł ominąć autoryzację middleware opartą na nazwie ścieżki i dotrzeć do chronionych tras. Problem naprawiono w wersji 7.2.4.

TOON, serializacja JSON dla promptów LLM, przed wersją 2.3.1 ma podatność na zanieczyszczenie prototypu. Dekodowanie danych TOON z kluczami __proto__, constructor lub prototype zapisuje przez łańcuch prototypów zamiast tworzyć własną właściwość, co zanieczyszcza Object.prototype. Może to prowadzić do odmowy usługi lub zdalnego wykonania kodu, jeśli istnieje odpowiedni gadżet.