CVE-2026-85708

W Chartbrew 5.2.2 blocklista AI SQL pomijała pokrewne funkcje systemu plików PostgreSQL i nie dopasowywała form identyfikatorów w podwójnych cudzysłowach dla zablokowanych funkcji. Owner lub Admin zespołu używający połączenia PostgreSQL z włączonym AI może spowodować, że wygenerowany SQL użyje nieujętej funkcji lub funkcji w cudzysłowach, omijając denylistę. Wymaga to włączonych funkcji AI i podwyższonych uprawnień w Chartbrew.

Chartbrew przed wersją 5.2.3 przechowuje hasła publicznych dashboardów w postaci jawnej, przyjmuje je przez parametr zapytania URL i weryfikuje bez skutecznego ograniczania liczby prób. Nieuwierzytelniony atakujący może wielokrotnie zgadywać hasła lub pozyskać je z logów serwera bądź proxy. Podatność dotyczy publicznych dashboardów z włączoną ochroną hasłem.

Chartbrew przed wersją 5.2.3 przy tworzeniu lub aktualizacji połączenia przechowywał wybrane przez atakującego bezwzględne ścieżki plików SSL i SSH, a następnie przy usuwaniu połączenia przekazywał je do fs.unlink bez ograniczenia ścieżki. Użytkownik z uprawnieniami createOwn i deleteOwn na własnym zespole może zapisać docelową ścieżkę w połączeniu i usunąć połączenie, aby wywołać usunięcie dowolnego pliku, np. /code/.env lub kodu źródłowego.

Chartbrew przed wersją 5.2.3 wstawiał zmienną MongoDB typu data umieszczoną w cytowanym miejscu zapytania jako nieescapowany ciąg, w przeciwieństwie do bezpiecznie escapowanych gałęzi tekstowej, liczbowej i logicznej. Nieuwierzytelniony użytkownik może wysłać spreparowany filtr URL do publicznego, udostępnialnego lub osadzonego wykresu MongoDB, przerwać cytowany literał i zmienić logikę zapytania, wykorzystując liczbę zwróconych wierszy jako wyrocznię boolowską do wyodrębnienia dowolnego pola z kolekcji.

Chartbrew przed wersją 5.2.3 w sprawdzaniu uprawnień do współdzielonego projektu ufał kontrolowanemu przez wywołującego team_id i pozwalał gałęzi teamOwner/teamAdmin kontynuować bez potwierdzenia, że docelowy projekt należy do tego zespołu. Uwierzytelniony właściciel lub administrator własnego zespołu może przesłać identyfikator projektu ofiary wraz z własnym team_id, a ścieżka aktualizacji masowo przypisuje pola bez listy dozwolonych, co pozwala przepiąć projekt ofiary do własnego zespołu i uzyskać pełny dostęp.

W Chartbrew przed 5.2.1 mechanizm kontroli wychodzących adresów URL nie rozpoznawał adresów IPv4 osadzonych w prefiksach NAT64. Uwierzytelniony użytkownik z uprawnieniami do zarządzania połączeniami API mógł podać nazwę hosta lub przekierowanie wskazujące adres NAT64 osadzający prywatny lub link-local adres IPv4, co po translacji przez bramę NAT64 pozwalało na dostęp do wewnętrznych zasobów, w tym metadanych chmury 169.254.169.254.

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.