CVE-2026-82879
ŚrednieCVSS 6.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 12 - wyżej niż 12% wszystkich znanych CVE
Streszczenie
DataEase przed wersją 2.10.26 zawiera wiele defektów kontroli dostępu w module linków udostępniania. Bilety nie są powiązane z docelowym UUID udostępnienia, więc ważny bilet wydany dla jednego udostępnienia może być użyty przeciwko innemu. Endpoint POST /de2api/share/validate wydaje LinkToken po weryfikacji hasła bez wymagania biletu, omijając politykę 'ticket mandatory'. Ponadto endpointy tworzenia i usuwania biletów nie sprawdzają własności udostępnienia, co pozwala uwierzytelnionemu użytkownikowi, który zna bilet innego użytkownika, na modyfikację, ponowne powiązanie lub usunięcie go (denial of service), a GET /de2api/share/queryRelationByUserId/{uid} pozwala uwierzytelnionym użytkownikom na enumerację mapowań udostępnień innych użytkowników.
Ocena ryzyka
Podatność umożliwia nieautoryzowany dostęp do udostępnionych zasobów, manipulację biletami i enumerację danych innych użytkowników. Może to prowadzić do naruszenia poufności danych, przerw w działaniu usług i eskalacji uprawnień.
Rekomendacja
Należy natychmiast zaktualizować DataEase do wersji 2.10.26 lub nowszej, która zawiera poprawki. Należy również przejrzeć konfigurację udostępniania i upewnić się, że polityka 'ticket mandatory' jest egzekwowana.
Inne podatności w DataEase
Zobacz wszystkie- CVE-2026-46684Krytyczne
W DataEase przed wersją 2.10.23 stwierdzono podatność w obsłudze tokenów korporacyjnych. Filtr TokenFilter#doFilter() przekazuje wartość nagłówka X-DE-TOKEN do metody TokenUtils.validate(), która sprawdza jedynie obecność i długość tokena, a następnie funkcja userBOByToken() używa JWT.decode() bez weryfikacji podpisu. Umożliwia to akceptację sfałszowanych tokenów z dowolnymi wartościami uid i oid, gdy licenseValid=true.
- CVE-2026-45534Krytyczne
W narzędziu DataEase przed wersją 2.10.23 wykryto podatność umożliwiającą zdalne wykonanie kodu (RCE) poprzez połączenie ze źródłem danych Redshift. Atakujący może wczytać kontrolowany plik konfiguracyjny rsjdbc.ini z katalogu tymczasowego, co prowadzi do wykonania kodu w wyniku refleksji podczas normalnego połączenia JDBC.
- CVE-2025-64428Krytyczne
Dataease, narzędzie do wizualizacji i analizy danych, w wersjach przed 2.10.17 jest podatne na wstrzyknięcie JNDI. Mimo dodania czarnej listy w wersji 2.10.14, atak nadal możliwy jest przez schematy iiop, corbaname oraz iiopname. Podatność została naprawiona w wersji 2.10.17.
- CVE-2025-64164Krytyczne
DataEase w wersjach 2.10.14 i starszych nieprawidłowo filtruje dane przy nawiązywaniu połączeń JDBC do Oracle, co stwarza ryzyko wstrzyknięcia JNDI. Problem został naprawiony w wersji 2.10.15.
- CVE-2025-64163Krytyczne
W DataEase w wersjach 2.10.14 i niższych dostawca dodał czarną listę filtrującą ldap:// i ldaps://, jednak pominięto ochronę protokołu dns://, co skutkuje podatnością SSRF. Luka została naprawiona w wersji 2.10.15.
- CVE-2025-58748Krytyczne
W DataEase w wersjach do 2.10.12 implementacja źródła danych H2 (H2.java) nie weryfikuje, czy podany URL JDBC rozpoczyna się od jdbc:h2. Brak tej walidacji pozwala na spreparowaną konfigurację JDBC, która podstawia sterownik Amazon Redshift i wykorzystuje parametry socketFactory i socketFactoryArg do wywołania org.springframework.context.support.FileSystemXmlApplicationContext lub ClassPathXmlApplicationContext ze zdalnym zasobem XML kontrolowanym przez atakującego, co skutkuje zdalnym wykonaniem kodu. Luka została naprawiona w wersji 2.10.13.
- CVE-2025-58046Krytyczne
W DataEase w wersjach do 2.10.12 włącznie źródło danych Impala jest podatne na zdalne wykonanie kodu z powodu niewystarczającego filtrowania w metodzie getJdbc klasy io.dataease.datasource.type.Impala. Atakujący mogą konstruować złośliwe ciągi połączenia JDBC wykorzystujące wstrzyknięcie JNDI i wywołujące deserializację RMI, co umożliwia zdalne wykonanie poleceń poprzez edycję źródła danych i podanie spreparowanego ciągu JDBC odwołującego się do zdalnego pliku konfiguracyjnego. Luka została naprawiona w wersji 2.10.13.
- CVE-2025-58045Krytyczne
W DataEase w wersjach do 2.10.12 poprawka wprowadzona w celu ograniczenia ataków zdalnego wykonania kodu przez deserializację JDBC DB2 objęła czarną listą tylko parametr rmi. Parametr ldap w ciągu połączenia JDBC DB2 nie został filtrowany, co pozwala atakującym wykorzystać ciąg połączenia JDBC DB2 do wywołania podatności SSRF. W nowszych wersjach Javy deserializacja ldap (autoDeserialize) jest domyślnie wyłączona, co uniemożliwia zdalne wykonanie kodu, ale SSRF pozostaje możliwy do wykorzystania. Luka została naprawiona w wersji 2.10.13.
- CVE-2026-104143Wysokie
DataEase to narzędzie do wizualizacji i analizy danych o otwartym kodzie źródłowym. Przed wersją 2.10.26 uwierzytelnieni użytkownicy mogą zapisać spreparowany niestandardowy dateFormat dla pola zestawu danych. DatasetTableFieldDTO.dateFormat jest wstawiany bez walidacji do szablonów konwersji dat używanych przez Dimension2SQLObj, CustomWhere2Str, Field2SQLObj, WhereTree2Str i ExtWhere2Str. Gdy wykres renderuje pole w zestawie danych między źródłami, parsowanie Calcite jest pomijane, a spreparowany format może bezpośrednio zmienić generowane SQL.
- CVE-2026-104142Wysokie
DataEase to narzędzie do wizualizacji i analizy danych o otwartym kodzie źródłowym. Przed wersją 2.10.26 uwierzytelnieni użytkownicy mogą zapisać spreparowane wartości FieldGroupDTO.min, FieldGroupDTO.max, FieldGroupDTO.startTime lub FieldGroupDTO.endTime w definicjach binowania grup pól zestawu danych. Utils.transGroupFieldToSql wstawia te dowolne wartości do generowanych wyrażeń CASE bez walidacji, a wynikowy SQL może trafić do nieparametryzowanego wykonania zapytania w backendzie, gdy wykres używa tego pola.
Oryginalny opis (angielski, źródło NVD)
DataEase before 2.10.26 contains multiple access control defects in the sharing link module. Tickets are not bound to the target share UUID, so a valid ticket issued for one share can be reused against another (ShareTicketManage.validateTicket / POST /de2api/share/proxyInfo). The POST /de2api/share/validate endpoint issues a LinkToken after password verification without requiring a ticket, bypassing the 'ticket mandatory' policy. Additionally, the ticket create and delete endpoints (POST /de2api/ticket/saveTicket, POST /de2api/ticket/delTicket) lack share-ownership checks, allowing an authenticated user who knows another user's ticket to modify, rebind, or delete it (denial of service), and GET /de2api/share/queryRelationByUserId/{uid} allows authenticated users to enumerate other users' share mappings.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS