CVE-2026-77122

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.

Nexus Repository 3 nie wystarczająco ograniczał, które właściwości puli połączeń HikariCP można ustawić przez API konfiguracji DataStore. Użytkownik z uprawnieniem nx-datastores-update mógł ustawić właściwość connectionInitSql, aby wykonać dowolne SQL na skonfigurowanej bazie danych przy każdym nowym połączeniu. Na domyślnym backendzie H2 może to prowadzić do zdalnego wykonania kodu jako użytkownik procesu Nexus.

Użytkownik posiadający uprawnienie do aktualizacji definicji uprawnień mógł zmodyfikować uprawnienie wildcard już przypisane do własnej roli, aby przyznać sobie szersze uprawnienia niż był upoważniony, w tym pełny dostęp administracyjny, bez dodatkowej kontroli autoryzacji lub ponownego przypisania roli.

Sonatype Nexus Repository 3 nie natychmiast kończył aktywnej sesji logowania użytkownika ani nie odwoływał zapisanych uprawnień, gdy konto użytkownika zostało usunięte, dezaktywowane lub zmieniono hasło. Użytkownik, który był już zalogowany w momencie jednej z tych akcji, mógł nadal korzystać z istniejącej sesji do interakcji z repozytorium, jakby konto było nadal aktywne, aż do wygaśnięcia sesji. W zależności od posiadanych uprawnień mogło to pozwolić na dalszy nieautoryzowany dostęp do odczytu, modyfikacji lub usuwania zawartości repozytorium po tym, jak dostęp miał być cofnięty.

Nexus Repository 3 zawiera endpoint używany do zmiany hasła administratora podczas początkowego wdrażania. Endpoint nie weryfikował, czy proces wdrażania nadal trwa, polegając jedynie na obecności lokalnego artefaktu. Konto z uprawnieniem nexus:* mogło wywołać endpoint poza zamierzonym przepływem, aby zmienić hasło administratora, a istniejące sesje nie były unieważniane po zmianie.

Sonatype Nexus Repository 3 nie filtrował odpowiednio wewnętrznych kluczy konfiguracyjnych z właściwości zadań dostarczanych przez użytkownika podczas tworzenia lub aktualizacji zaplanowanego zadania przez interfejs administracyjny. Konto z uprawnieniem do tworzenia co najmniej jednego typu zadania mogło dostarczyć spreparowaną wartość, która spowodowała nadpisanie konfiguracji niezwiązanego, istniejącego zadania zamiast utworzenia nowego.

Nexus Repository 3 zawiera podatność Server-Side Request Forgery (SSRF) w funkcji weryfikacji konfiguracji e-mail. Użytkownik z uprawnieniem nexus:settings:update mógł przesłać dowolne wartości hosta i portu do endpointu testowania/weryfikacji e-mail, powodując próby połączeń wychodzących do wewnętrznych lub ograniczonych adresów sieciowych. Różnice w odpowiedziach serwera mogły być wykorzystane do ustalenia, czy wewnętrzne hosty i porty są osiągalne. Problem dotyczy wersji do 3.94.1 włącznie, naprawiony w 3.95.0.

Nexus Repository 3 jest podatny na przechowywany cross-site scripting (XSS). Użytkownik z uprawnieniem nexus:blobstores:create lub nexus:blobstores:update mógł ustawić nazwę magazynu blob zawierającą złośliwy skrypt, który później wykonywał się w przeglądarce innego użytkownika przeglądającego status kontroli zdrowia systemu. Problem naprawiono w wersji 3.95.0.

Nexus Repository 3 nie w pełni izolował wyrażenia JEXL używane w selektorach treści. Konto z uprawnieniem nexus:selectors:create mogło skonstruować wyrażenie, które odczytywało właściwości obiektów Java nieprzeznaczone do udostępnienia, ujawniając wewnętrzne metadane klasy JVM, takie jak nazwy klas i classloaderów. Problem nie pozwala na wywoływanie metod, tworzenie obiektów ani wykonywanie dowolnego kodu. Naprawiono to przez ograniczenie dostępu do właściwości w sandboxie JEXL do zamierzonych typów danych.

Nexus Repository 3 CE/Pro wersje 3.0.0 do 3.94.x zawierają podatność nieprawidłowej autoryzacji (CWE-863) w interfejsie użytkownika do tworzenia repozytoriów. Konto użytkownika posiadające delegowane uprawnienie administratora repozytorium ograniczone do określonego formatu repozytorium mogło utworzyć repozytorium o innym, nieautoryzowanym formacie, ponieważ autoryzacja była sprawdzana na podstawie jednego pola żądania, podczas gdy osobne pole kontrolowane przez atakującego określało faktycznie tworzony format repozytorium. Nie dotyczy to użytkownika anonimowego, który domyślnie nie może posiadać tego uprawnienia. Poprawione w wersji 3.95.0.