CVE-2026-65980

W wersji 4.9.0 aplikacji Chartbrew występuje luka, która pozwala atakującym z niskimi uprawnieniami na dostęp do danych z innych projektów w tym samym zespole. Luka ta umożliwia odczyt, wykonanie, tworzenie, aktualizację oraz usuwanie zestawów danych i żądań danych, do których atakujący nie powinien mieć dostępu.

W wersji 4.9.0 aplikacji Chartbrew występuje luka, która pozwala na dostęp do punktu końcowego POST /api/chart/:chart_id/query bez uwierzytelnienia. Atakujący, znając identyfikator wykresu, może odświeżyć dane i uzyskać dostęp do prywatnych wykresów.

W wersji 4.9.0 aplikacji Chartbrew, uwierzytelnieni użytkownicy mający dostęp do jednego projektu mogą aktualizować lub usuwać rekord SharePolicy należący do innego projektu. Problem wynika z braku weryfikacji, czy policy_id należy do danego projektu.

W wersji 4.9.0 aplikacji Chartbrew występuje luka, która pozwala na publiczny dostęp do danych wykresów, nawet jeśli są one ukryte. Luka ta wynika z niewłaściwej weryfikacji uprawnień dostępu do wykresów w projektach publicznych.

Chartbrew przed wersją 5.2.2 zawiera podatność w implementacji runQuery() w server/modules/ai/orchestrator/tools/runQuery.js, gdzie parametr row_limit narzędzia AI jest interpolowany do klauzuli LIMIT SQL bez walidacji liczby całkowitej w czasie wykonywania. Kontrola słów kluczowych tylko do odczytu jest wykonywana przed dodaniem tej wartości, więc uwierzytelniony użytkownik, który może wpłynąć na niecałkowitą wartość row_limit generowaną przez model, może dodać SQL, który omija wcześniejszą kontrolę. Skuteczne wykorzystanie może wykonać dowolne instrukcje względem podłączonej bazy danych, w tym odczytywać lub zmieniać dane oraz, jeśli uprawnienia bazy danych na to pozwalają, uzyskać dostęp do plików lub wykonać polecenia systemu operacyjnego. Problem został naprawiony w wersji 5.2.2.

Chartbrew przed wersją 5.2.2 zawiera podatność w implementacji runQuery() w server/modules/ai/orchestrator/tools/runQuery.js, która próbuje egzekwować dostęp tylko do odczytu za pomocą listy blokującej zawierającej tylko siedem słów kluczowych SQL. Uwierzytelniony użytkownik z dostępem do funkcji AI może przesłać niebezpieczne instrukcje lub funkcje bazodanowe, których nie ma na liście blokującej, powodując ich wykonanie bez użycia technik SQL injection lub obfuskacji słów kluczowych. W zależności od silnika bazy danych, konfiguracji i uprawnień użytkownika bazy danych, może to ujawnić lub zapisać pliki, uzyskać dostęp do wewnętrznych zasobów sieciowych, zmienić uprawnienia bazy danych, wykonać polecenia lub zmienić dane. Problem został naprawiony w wersji 5.2.2.

Chartbrew przed wersją 5.2.2 zawiera podatność w server/modules/safeRequest.js, gdzie funkcja validateOutboundUrl() rozwiązuje i waliduje docelową nazwę hosta, ale request-promise wykonuje oddzielną rozdzielczość DNS dla rzeczywistego połączenia. Uwierzytelniony użytkownik, który może tworzyć lub testować połączenia API i kontroluje docelową nazwę DNS, może zwrócić publiczny adres podczas walidacji i prywatny adres podczas żądania, omijając zabezpieczenia zaimplementowane w server/modules/outboundTargetPolicy.js. Ten warunek ponownego wiązania DNS może ujawnić wewnętrzne usługi, zasoby localhost lub punkty końcowe metadanych chmury. Problem został naprawiony w wersji 5.2.2.