Katalog podatności CVE

Podatność w Heym przed wersją 0.0.53, polegająca na ewaluacji wyrażeń warunków przepływu pracy za pomocą eval() w Pythonie z niewystarczającym sandboxingiem w usłudze wykonawczej przepływów pracy.

heym przed wersją 0.0.91 zawiera podatność ucieczki z sandboxa w silniku wyrażeń (DotList map/filter i fallback resolver), która umożliwia uwierzytelnionym użytkownikom wykonanie dowolnego kodu Python. Atakujący mogą tworzyć wyrażenia workflow z dostępem do atrybutów dunder, aby uzyskać dostęp do os.system i wykonać komendy jako proces backendu.

Heym w wersjach 0.0.90 i wcześniejszych zawiera dwie luki w zabezpieczeniach egress SSRF, obie naprawione w app/services/ssrf_guard.py w wersji 0.0.91. Po pierwsze, loader obrazów LLM (_load_image_bytes) pobierał kontrolowane przez wywołującego adresy URL HTTP/HTTPS za pomocą zwykłego httpx.get, stosując tylko sprawdzenie schematu i omijając klienta HTTP z przypiętym egress. Po drugie, _is_public_address odpakowywał tylko adresy IPv6 mapowane na IPv4, więc formy przejściowe IPv6 — prefiks NAT64 64:ff9b::/96, przestarzałe adresy IPv4-compatible ::x.x.x.x oraz 6to4 (2002::/16) — mogły przenosić adresy loopback, RFC1918, link-local lub cloud-metadata IPv4 poza walidację URL i przypięcie IP przy połączeniu.

Platforma automatyzacji przepływów pracy heym przed wersją 0.0.91 przechowuje i zwraca wiele sekretów w postaci zwykłego tekstu, w tym wartości nagłówków webhook, klucze API MCP, tokeny sesji portalu, tokeny JWT wykonań, tokeny interakcji Discord oraz zmienne globalne. Użytkownik z dostępem do odczytu przepływu pracy, członek zespołu lub osoba mająca dostęp do bazy danych, kopii zapasowej lub logów może odzyskać te sekrety i wykorzystać je do wykonywania przepływów pracy lub podszywania się pod właściciela sekretu.

heym przed wersją 0.0.105 nie stosuje zabezpieczeń egress do usług integracyjnych, które używają adresów bazowych dostarczanych z poświadczeniami, co pozwala uwierzytelnionym użytkownikom na obejście ochrony SSRF. Atakujący mogą skonfigurować poświadczenia wskazujące na adresy loopback, prywatne lub metadane chmury i odczytać odpowiedzi wewnętrznych usług zwracane jako wynik węzła przepływu pracy.

heym przed wersją 0.0.105 nie uwzględnia wyniku wyszukiwania autoryzacji poświadczeń w węźle Redis. Gdy _get_accessible_credential zwraca None, węzeł traktuje to jako pustą konfigurację i łączy się z localhost:6379 bez hasła, wykonując żądaną operację. Uwierzytelniony autor przepływu pracy, podając identyfikator poświadczenia, którego nie posiada lub które zostało usunięte, uzyskuje połączenie odczytu/zapisu z Redisem na interfejsie loopback.

Heym przed wersją 0.0.106 zawiera podatność na eksfiltrację poświadczeń w punkcie końcowym POST /api/credentials/test, która pozwala współpracownikom z dostępem do współdzielonych poświadczeń na wyeksfiltrowanie sekretu właściciela poświadczeń. Atakujący mogą nadpisać docelowy URL w parametrze config, aby serwer wysyłał odszyfrowane sekrety uwierzytelniające do kontrolowanych przez atakującego punktów końcowych.

heym przed wersją 0.0.109 zawiera podatność na SSRF w węzłach Slack, Discord i Crawler. Węzły te wysyłają żądania HTTP do adresów URL pochodzących z poświadczeń użytkownika (webhook_url / flaresolverr_url) za pomocą niechronionego klienta HTTP, omijając zabezpieczenia egress. Każdy zarejestrowany użytkownik może utworzyć poświadczenie wskazujące na wewnętrzny adres i wykonać przepływ pracy, powodując dostęp do punktów końcowych loopback, prywatnych, link-local lub metadanych chmury i zwrócenie pełnej treści odpowiedzi w wyniku węzła.

AzuraCast przed wersją 0.23.4 zawiera podatność wstrzykiwania kodu w metodzie ConfigWriter::cleanUpString(), która nie sanitizuje sekwencji interpolacji Liquidsoap. Uwierzytelnieni użytkownicy z uprawnieniami Media lub Profile mogą wstrzyknąć dowolny kod Liquidsoap do konfiguracji stacji, co prowadzi do wykonania poleceń powłoki jako użytkownik azuracast przy restarcie stacji.

AzuraCast przed wersją 0.23.6 zawiera podatność wstrzykiwania kodu w polu hasła zdalnego przekaźnika z powodu niepełnej migracji z podatnej metody cleanUpString do toRawString. Atakujący z uprawnieniami RemoteRelays mogą wstrzyknąć zagnieżdżoną składnię interpolacji Liquidsoap, aby wykonać dowolny kod w procesie Liquidsoap, ujawnić wewnętrzne klucze API lub zakłócić działanie stacji.

AzuraCast przed wersją 0.23.6 zawiera brak sprawdzenia uprawnień w punkcie końcowym GET /api/station/{station_id}/file/{id}/play, co pozwala uwierzytelnionym użytkownikom na pobieranie plików multimedialnych z dowolnej stacji. Atakujący mogą enumerować pliki za pomocą sekwencyjnych identyfikatorów i eksfiltrować całą bibliotekę multimediów stacji, do których nie mają uprawnień.

AzuraCast przed wersją 0.23.6 nie stosuje middleware RequireInternalConnection na punkcie końcowym API Liquidsoap i błędnie wyprowadza flagę AutoDJ z obecności nagłówka, a nie z jego zweryfikowanej wartości. Użytkownicy z uprawnieniem View station mogą wstrzykiwać dowolne metadane now-playing, zakłócać transmisje na żywo i ujawniać ścieżki systemu plików.

W AzuraCast przed wersją 0.23.8 publiczny punkt końcowy pobierania On-Demand nie weryfikuje kontroli dostępu na poziomie playlisty, co pozwala nieuwierzytelnionym użytkownikom na pobieranie plików multimedialnych wykluczonych z playlist z włączonym On-Demand. Atakujący mogą ominąć zamierzone ograniczenia dostępu, bezpośrednio żądając mediów za pomocą prawidłowych identyfikatorów, ujawniając prywatne lub zastrzeżone treści audio.

Podatność na wstrzykiwanie poleceń w AzuraCast przed wersją 0.23.8, występująca w generowaniu konfiguracji Liquidsoap dla nagrań na żywo. Brak odpowiedniego cytowania nazwy użytkownika streamera w wywołaniach process.run.

AzuraCast przed wersją 0.23.8 zawiera podatność uszkodzonej kontroli dostępu w endpointcie GET /api/station/{id}/vue/profile, która umożliwia uwierzytelnionym użytkownikom z uprawnieniem View Station Page odczytanie haseł administratora, źródła i przekaźnika Icecast/Shoutcast. Atakujący z dostępem tylko do podglądu może wywołać ten endpoint i otrzymać jawne poświadczenia frontendu w odpowiedzi JSON, a następnie użyć hasła administratora do uwierzytelnienia w interfejsie administracyjnym Icecast bez uprawnień Broadcasting.

AzuraCast przed wersją 0.23.8 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) i odczyt lokalnych plików w funkcji pobierania zdalnej playlisty AutoDJ (getMediaFromRemoteUrl()). Użytkownik z uprawnieniami Media może utworzyć playlistę z source=remote_url i remote_type=playlist, wskazując na ścieżkę file:// lub wewnętrzny adres HTTP. Gdy AutoDJ buduje kolejkę, backend przekazuje URL bezpośrednio do file_get_contents() bez listy dozwolonych schematów ani polityki IP, co umożliwia odczyt plików hosta (np. /etc/passwd lub .env) i treści wewnętrznych żądań HTTP. Brak dostępnej wersji z poprawką w momencie publikacji.

AzuraCast przed wersją 0.23.8 zawiera podatność SSRF w walidacji URL webhooka. Walidacja odrzuca tylko adresy IP link-local, ale nie blokuje adresów loopback ani prywatnych, a nazwy hostów niebędące adresami IP całkowicie omijają sprawdzenie. Użytkownik z uprawnieniami WebHooks może skonfigurować webhook wskazujący na wewnętrzne zasoby i wywołać żądanie HTTP POST z danymi Now Playing.

AzuraCast przed wersją 0.23.8 zawiera podatność SSRF w walidacji URL Remote Relay. Walidacja sprawdza tylko składnię URL i schemat http/https, bez ograniczeń dotyczących hosta lub adresu IP. Użytkownik z uprawnieniami RemoteRelays może ustawić URL wskazujący na loopback, sieć prywatną lub adresy metadata chmury, a automatyczna synchronizacja Now Playing będzie wysyłać żądania do tych adresów.

AzuraCast przed wersją 0.23.8 zawiera podatność wstrzykiwania DQL w parametrze sortOrder w AbstractSearchableListAction.php. Atakujący może wstrzykiwać dowolne wyrażenia DQL, aby wyodrębnić wrażliwe dane z bazy, w tym dane uwierzytelniające użytkowników i ustawienia stacji.

MONAI przed wersją 1.5.2 zawiera podatność deserializacji niezaufanych danych w funkcji algo_from_pickle w monai/auto3dseg/utils.py. Funkcja wczytuje plik .pkl i przekazuje jego zawartość do pickle.loads bez walidacji źródła lub zawartości. Jeśli aplikacja wywoła algo_from_pickle na pliku dostarczonym przez atakującego, obiekt definiujący __reduce__ zostanie wykonany podczas deserializacji, co prowadzi do wykonania dowolnego kodu.