CVE-2026-17594

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.

Konto posiadające uprawnienie nexus:settings:update w Nexus Repository 3 (lub równoważne uprawnienie nexus:settings w starszym Nexus Repository 2) mogło przesyłać dowolne wartości jako identyfikatory realmów przez wewnętrzne API konfiguracji, które nie walidowało ich względem zestawu zarejestrowanych realmów. Ponieważ nierozpoznane wpisy były utrwalane i ponownie oceniane przy każdym ładowaniu realmów przez starszą ścieżkę kodu, mogło to prowadzić do niezamierzonego wykonania kodu wewnątrz procesu Nexus Repository, a w niektórych przypadkach do trwałego zablokowania uwierzytelniania, które nie było widoczne w interfejsie administracyjnym.

Nexus Repository 3 zawierał podatność eskalacji uprawnień w API REST dotyczącym uprawnień. Uwierzytelniony użytkownik z uprawnieniem do zarządzania uprawnieniami mógł, w określonych konfiguracjach ról, eskalować swój własny dostęp do pełnego administratora, wykorzystując wadę polegającą na pomyleniu typów w punkcie końcowym aktualizacji uprawnień.