CVE-2026-123992

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.

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.

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.

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.

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.

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.

W DataEase do wersji 2.10.27 wykryto podatność w funkcji WhitelistUtils.endsWithAny pliku WhitelistUtils.java komponentu Authentication Filter. Manipulacja argumentem File prowadzi do nieograniczonego przesyłania plików. Możliwe jest zdalne zainicjowanie ataku, a exploit jest publicznie dostępny.

W DataEase do wersji 2.10.27/3.1.0 wykryto podatność w funkcji ExtWhere2Str.extWhere2sqlOjb pliku engine/trans/ExtWhere2Str.java komponentu Chart Data Handler. Manipulacja argumentem operator prowadzi do wstrzyknięcia SQL. Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.