Metacat CVE-2026-48528: publiczne API CN pozwala przejąć bazę

14 sierpnia 2026 roku opublikowano CVE-2026-48528, krytyczne SQL injection w Metacat. Podatne są wersje od 2.0.0 do 3.4.0, natomiast wersja 3.4.1 zawiera poprawkę. Luka znajduje się w endpointach Coordinating Node API /cn/v1/object oraz /cn/v2/object. Parametr nodeId jest dołączany do zapytania SQL bez prawidłowego bindowania, a wywołanie nie wymaga uwierzytelnienia.

Metacat służy do przechowywania i udostępniania danych oraz metadanych badawczych w ekosystemie DataONE. To zmienia ocenę skutku: atak nie dotyczy jedynie zwykłej tabeli aplikacyjnej, ale repozytorium, którego wiarygodność, kontrola dostępu i ślad pochodzenia mają znaczenie dla nauki i współpracy instytucjonalnej. Advisory NCEAS przypisuje podatności 9,8 w CVSS 3.1 i opisuje możliwość odczytu oraz modyfikacji bazy.

Gdzie powstaje SQL injection

Podatny przepływ zaczyna się od żądania do interfejsu CN. Wartość nodeId powinna identyfikować węzeł, ale aplikacja włącza ją do tekstu zapytania zamiast przekazać jako osobny parametr sterownika. Gdy dane i struktura instrukcji SQL zostają połączone, napastnik może domknąć oczekiwany fragment i dołożyć własną logikę.

Nie trzeba posiadać konta Metacat. Publiczna osiągalność endpointu wystarcza, aby wysyłać kolejne żądania i obserwować odpowiedzi. To obniża koszt ataku i zwiększa znaczenie nawet dla instancji, które są używane przez niewielką grupę badaczy, ale udostępniają API na zewnątrz.

Advisory opisuje błąd ujawniający komunikaty PostgreSQL w odpowiedzi XML. Napastnik może celowo wywołać błąd konwersji, na przykład umieszczając wynik podzapytania w operacji CAST. Treść wybranego rekordu pojawia się wtedy w komunikacie zwracanym przez aplikację. Jest to error-based SQL injection: baza sama staje się kanałem wyprowadzania danych.

Powtarzając zapytania, można wydobywać informacje bez standardowego widoku listy rekordów. Według analizy projektowej możliwe są również instrukcje INSERT, UPDATE i DELETE, więc luka nie kończy się na poufności. Zakres obejmuje integralność i dostępność repozytorium.

Jakie dane mogą być narażone

Katalog Metacat może zawierać opisy zbiorów badawczych, identyfikatory obiektów, informacje o autorach i powiązaniach. W bazie mogą także znajdować się identyfikatory ORCID, adresy IP klientów, logi dostępu i listy kontroli dostępu. Dokładna zawartość zależy od wdrożenia, ale administrator powinien oceniać ryzyko na podstawie realnego schematu i przechowywanych rekordów, nie ogólnej nazwy produktu.

Naruszenie ACL może prowadzić do ujawnienia obiektów, które nie miały być publiczne. Zmiana metadanych może z kolei podważyć powiązanie między zbiorem a autorem, wersją czy warunkami użycia. Jeżeli repozytorium uczestniczy w federacji lub zasila inne narzędzia, błędne dane mogą propagować się dalej.

W środowisku badawczym integralność jest równie ważna jak poufność. Podmieniony identyfikator, opis metodologii albo relacja wersji może wpłynąć na reprodukowalność pracy. Widoczna awaria zostanie zauważona szybko, natomiast subtelna modyfikacja może pozostać w obiegu przez długi czas.

Logi dostępu i adresy IP są dodatkowym problemem prywatności. Jeżeli istnieje możliwość ich odczytu, zespół powinien włączyć właściciela danych lub inspektora ochrony danych do oceny incydentu. CVE opisuje mechanizm techniczny, ale obowiązki notyfikacyjne wynikają z kontekstu organizacji i jurysdykcji.

Aktualizacja jest podstawowym działaniem

Administratorzy powinni zaktualizować Metacat do wersji 3.4.1 lub nowszej. Przed zmianą należy utworzyć spójny backup bazy, konfiguracji i magazynu obiektów, a następnie sprawdzić możliwość odtworzenia. Po wdrożeniu poprawki warto potwierdzić, że publiczne endpointy rzeczywiście korzystają z nowej wersji aplikacji, a stary kontener, artefakt WAR lub węzeł klastra nie pozostał za load balancerem.

Skan wersji jest tylko początkiem. Ponieważ wykorzystanie nie wymaga logowania i może prowadzić do zapisu, po aktualizacji trzeba przeprowadzić analizę historyczną. Porównaj schemat oraz dane z zaufaną kopią, sprawdź ostatnie zmiany ACL, autorów i identyfikatorów, a także masowe usunięcia lub aktualizacje. Rotuj hasło bazy i inne sekrety dostępne dla procesu, jeżeli nie można wykluczyć szerszego dostępu.

Jeśli Metacat działa w kontenerze, nie zakładaj, że wymiana obrazu automatycznie usuwa skutki. Baza i magazyn są zwykle wolumenami trwałymi. Nowy obraz naprawia kod, lecz zachowuje wcześniej zmodyfikowane rekordy.

Bezpieczne obejście, gdy aktualizacja musi poczekać

Advisory wskazuje praktyczne ograniczenie: większość repozytoriów członkowskich DataONE nie potrzebuje endpointów Coordinating Node. Jeżeli dana instancja nie pełni roli CN, można wyłączyć mapowania servletów v1 i v2 odpowiadające za te ścieżki. W dokumentacji poprawki wymieniono klasy edu.ucsb.nceas.metacat.restservice.v1.CNRestServlet oraz odpowiednik v2 w web.xml.

To obejście powinno być wdrożone dopiero po potwierdzeniu roli węzła i przetestowaniu komunikacji. Nie wystarczy ukryć linku w interfejsie. Żądania muszą być odrzucane na serwerze aplikacyjnym lub wcześniej na reverse proxy. Reguła powinna obejmować obie wersje API, różne warianty ścieżki i normalizację adresu.

Jeżeli endpoint jest biznesowo wymagany, ogranicz go do znanych źródeł sieciowych, dołóż uwierzytelnienie na proxy i monitoruj każde wywołanie. Jest to redukcja ekspozycji, nie równoważnik poprawki. Wewnętrzny klient lub przejęty host nadal może dotrzeć do podatnego kodu.

Detekcja i analiza śladów

Przeszukaj logi HTTP pod kątem żądań do /cn/v1/object i /cn/v2/object z parametrem nodeId. Wysoką wartość mają nietypowe apostrofy, komentarze SQL, słowa CAST, SELECT, UNION, sekwencje kodowane procentowo i duża liczba podobnych błędnych żądań. Nie ograniczaj się do dokładnych sygnatur, ponieważ składnię można zmieniać.

Sprawdź odpowiedzi 500 i odpowiedzi XML zawierające komunikaty PostgreSQL. Seria błędów konwersji może wskazywać na error-based extraction. Po stronie bazy przeanalizuj zapytania pochodzące z konta Metacat, szczególnie instrukcje zmieniające tabele, nietypowe podzapytania i aktywność poza zwykłym rytmem instancji.

Dane z reverse proxy, aplikacji i PostgreSQL powinny zostać skorelowane czasowo. Zachowaj surowe logi przed rotacją i wykonaj ich kopię poza analizowanym hostem. Jeżeli wykryjesz podejrzane zapisy, nie przywracaj automatycznie całej bazy bez ustalenia punktu początkowego: możesz odtworzyć już skażoną kopię.

Brak alarmu WAF nie dowodzi bezpieczeństwa. WAF może nie widzieć zdekodowanej wartości tak samo jak aplikacja, a doświadczony napastnik może rozłożyć ekstrakcję na wiele niepozornych żądań. Najsilniejszym dowodem jest połączenie logów z kontrolą integralności rekordów.

Lekcje dla projektantów API danych

Każda wartość przesyłana do bazy musi być traktowana jako dane, nawet jeśli ma reprezentować identyfikator węzła, nazwę kolekcji lub inny obiekt infrastrukturalny. Typowe identyfikatory można dodatkowo walidować do ścisłego formatu, ale podstawą pozostaje prepared statement. Walidacja ogranicza błędy i powierzchnię, a parametryzacja rozdziela dane od składni.

Komunikaty bazy nie powinny trafiać do publicznej odpowiedzi. Szczegóły są potrzebne operatorowi w chronionym logu, natomiast klient powinien otrzymać stabilny kod błędu i identyfikator zdarzenia. Ogranicza to zarówno error-based injection, jak i ujawnianie schematu czy nazw tabel podczas innych awarii.

Konto bazy przypisane do aplikacji powinno mieć najmniejszy potrzebny zakres. Jeżeli konkretny endpoint jest wyłącznie odczytowy, osobna ścieżka lub rola read-only może zmniejszyć skutek podatności. W repozytoriach naukowych warto także wersjonować krytyczne metadane i podpisywać manifesty, aby niezależnie wykrywać zmiany.

Testy bezpieczeństwa powinny objąć nie tylko klasyczne formularze. Parametry protokołów federacyjnych, identyfikatory węzłów i funkcje administracyjne często otrzymują mniej uwagi, ponieważ wyglądają na dane systemowe. Z perspektywy granicy zaufania są jednak zwykłym wejściem kontrolowanym przez klienta.

Co jest faktem, a co oceną Breachroad

Faktem z advisory jest podatność Metacat 2.0.0–3.4.0, brak uwierzytelnienia na dwóch ścieżkach CN, możliwość error-based extraction oraz operacji zmieniających bazę, a także poprawka w 3.4.1. Projekt podaje również możliwość wyłączenia servletów CN jako obejście dla węzłów, które ich nie potrzebują. Samo advisory nie stanowi dowodu masowej eksploatacji w Internecie.

Wnioskiem Breachroad jest wysoki priorytet kontroli integralności po aktualizacji. Repozytorium danych może nadal działać poprawnie technicznie mimo cichej zmiany metadanych lub ACL. Dlatego odpowiedź powinna łączyć patch, przegląd śladów, porównanie z zaufanym stanem oraz ocenę prywatności.

Jeśli utrzymujesz publiczne repozytorium, panel lub API połączone z bazą, testy penetracyjne aplikacji webowych i API pomogą zweryfikować parametryzację, kontrolę dostępu i odporność na wycieki błędów. Zespół może też przełożyć ten przypadek na praktykę podczas szkolenia cyberbezpieczeństwa dla organizacji, gdzie skupiamy się na decyzjach deweloperów i operatorów.