CVE-2026-50530
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 15 - wyżej niż 15% wszystkich znanych CVE
Streszczenie
W narzędziu DataEase przed wersją 2.10.24 interfejs danych wykresu w trybie udostępniania nie sprawdza, czy identyfikatory tabeli i pól w żądaniu należą do udostępnionego zasobu. Osoba atakująca posiadająca ważny token linku udostępniania może podmienić identyfikatory zestawu danych i uzyskać nieautoryzowany dostęp do danych przez endpoint POST /de2api/chartData/getData.
Ocena ryzyka
Organizacja narażona jest na wyciek poufnych danych, ponieważ atakujący z ważnym linkiem udostępniania może odczytać dane z innych, nieudostępnionych zestawów danych.
Rekomendacja
Należy niezwłocznie zaktualizować DataEase do wersji 2.10.24 lub nowszej, która zawiera poprawkę usuwającą tę podatność.
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 is an open source data visualization and analysis tool. Prior to 2.10.24, a share mode chart data interface only validates that sceneId matches the resourceId in the link token and fails to validate whether tableId and field IDs in the request body belong to the shared resource, allowing an attacker with a valid share link token to replace dataset identifiers and retrieve unauthorized data through POST /de2api/chartData/getData. This issue is fixed in version 2.10.24.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

