CVE-2026-55633

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.

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.

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.

W systemie DataEase do wersji 3.0.0 wykryto podatność w funkcji Utils.buildCalcField pliku io/dataease/engine/utils/Utils.java. Manipulacja argumentem calculated field prowadzi do wstrzyknięcia SQL. Atak może być przeprowadzony zdalnie, a exploit został opublikowany.

Podatność typu directory traversal w DataEase przed wersją 1.18.10 pozwala zdalnemu atakującemu na uzyskanie poufnych informacji poprzez spreparowane żądanie do komponentu StaticResourceController.java.

Wykryto podatność w DataEase w wersjach do 2.10.25/2.10.26. Dotyczy ona funkcji buildTooltip w pliku symbolic-map.ts komponentu Symbolic Map i manipulacji argumentem canvasViewInfo[*].customAttr.tooltip.backgroundColor, co prowadzi do cross site scripting (XSS). Atak można przeprowadzić zdalnie, a projekt został wcześniej poinformowany o problemie, ale nie odpowiedział.

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.

DataEase przed wersją 2.10.26 pomija kontrolę autoryzacji na poziomie obiektów w endpointach REST dotyczących informacji geograficznych, powiązań dashboardów i szczegółów wykresów, co pozwala uwierzytelnionym użytkownikom na dostęp do zasobów należących do innych użytkowników. Atakujący mogą nadpisywać lub usuwać geometrię map, modyfikować powiązania dashboardów oraz pobierać metadane i konfigurację wykresów dla zasobów, których nie posiadają, podając dowolne identyfikatory w żądaniach.

DataEase to narzędzie do wizualizacji i analizy danych typu open source. Wersje przed 2.10.23 mają podatność na path traversal. Przyczyną jest to, że na systemie Windows separator plików to '\', a serwer filtruje tylko znak '/' podczas skracania ciągów. Luka została naprawiona w wersji 2.10.23. Brak znanych obejść.

Podatność w narzędziu DataEase przed wersją 2.10.23 umożliwia zdalne wykonanie kodu poprzez przesłanie spreparowanego pliku payload.zip za pomocą API Excel /datasource/upload. Atakujący tworzy źródło danych H2 wykorzystujące protokół zip:, a następnie wykonuje zapytanie SQL, które uruchamia prekompilowane aliasy Java w pliku test.mv.db, prowadząc do wykonania dowolnego kodu.