Katalog podatności CVE

Polyaxon w wersjach do 2.16.4 renderuje pola specyfikacji operacji w niesandboxowanym środowisku Jinja2 podczas przygotowywania uruchomienia po stronie serwera, co pozwala uwierzytelnionym użytkownikom na wykonanie dowolnego kodu. Atakujący mogą przesyłać uruchomienia z ładunkami Jinja2 w polach queue, namespace, conditions, presets lub dependencies, aby wykonać polecenia systemowe w kontekście procesu schedulera.

pgweb w wersjach do 0.17.0 pozostawia endpoint POST /api/connect bez zabezpieczeń, gdy skonfigurowano autoryzację connect-backend, co pozwala atakującym na podanie dowolnych ciągów połączenia do bazy danych. Atakujący mogą obejść mapowanie zasób-baza danych, dostarczając własny identyfikator sesji i URL połączenia, aby uzyskać dostęp do nieautoryzowanych baz danych i usług wewnętrznych.

KubeSphere w wersjach do 4.1.3 zawiera podatność typu server-side request forgery w endpoincie weryfikacji poświadczeń git, który przyjmuje niezwalidowane URL-e dostarczone przez wywołującego bez ograniczeń allowlisty. Uwierzytelnieni atakujący mogą podać dowolne URL-e, aby dotrzeć do usług wewnętrznych i wykraść poświadczenia basic-auth z Sekretów w dowolnym namespace.

PraisonAI to system zespołów wieloagentowych. Od wersji 1.4.0 do 1.7.2 funkcja createAgentLoop() w src/praisonai-ts/src/ai/agent-loop.ts przekazuje wykonywalne narzędzia do generateText() przed wywołaniem callbacku zatwierdzającego onToolCall. Ponieważ opakowany AI SDK wykonuje handlery narzędzi podczas generowania, callback zwracający false zapisuje tool_rejected dopiero po tym, jak odrzucone narzędzie wywołało już skutki uboczne.

PraisonAI to system zespołów wieloagentowych. Od wersji 1.2.3 do 1.7.2 klasa CommandValidator w src/praisonai-ts/src/cli/features/sandbox-executor.ts waliduje tylko pierwszy, oddzielony białym znakiem plik wykonywalny względem allowedCommands, a następnie SandboxExecutor przekazuje pełny ciąg polecenia do sh -c. Polecenie zaczynające się od dozwolonego pliku wykonywalnego może dołączyć niedozwolone polecenie za pomocą metaznaków powłoki.

PraisonAI to system zespołów wieloagentowych. Od wersji 1.2.3 do 1.7.2 tryb izolacji sieciowej SandboxExecutor w src/praisonai-ts/src/cli/features/sandbox-executor.ts używa buildEnv() jedynie do wstrzyknięcia nieprawidłowych zmiennych środowiskowych http_proxy i https_proxy i nie ustanawia granicy sieciowej na poziomie systemu operacyjnego. Programy ignorujące te zmienne proxy mogą otwierać gniazda bezpośrednio.

PraisonAI to system zespołów wieloagentowych. Od wersji 1.5.1 do 1.7.2 funkcja MCPSecurity.evaluatePolicy() w src/praisonai-ts/src/mcp/security.ts wywołuje skonfigurowany walidator poświadczeń tylko wtedy, gdy AuthMethod to api-key lub bearer. Zasady Basic i OAuth akceptują dowolny niepusty nagłówek Authorization bez wywołania auth.validate(), a następnie zwracają wynik uwierzytelnienia.

PraisonAI to system zespołów wieloagentowych. Od wersji 1.5.1 do 1.7.2 pomocnik shell() eksportowany z src/praisonai-ts/src/tools/utility-tools.ts sprawdza tylko pierwszy, oddzielony białym znakiem token względem safeCommands, a następnie przekazuje pełny oryginalny ciąg do child_process.exec(). Ciąg zaczynający się od dozwolonego polecenia tylko do odczytu może dołączyć drugie niedozwolone polecenie za pomocą składni powłoki.

W bibliotece PraisonAI metoda ToolsMCPServer.run_sse() montuje transport SseServerTransport na przestarzałych endpointach /sse i /messages/ bez domyślnego wymuszania nagłówków Host, Origin ani uwierzytelniania. Złośliwa strona internetowa może wykorzystać DNS rebinding przeciwko osiągalnemu lokalnemu lub wewnętrznemu serwerowi SSE, dostarczyć kontrolowane przez atakującego nagłówki Host i Origin, wyliczyć zarejestrowane narzędzia i wywołać je z uprawnieniami użytkownika serwera. Wstępna poprawka została wydana w praisonaiagents 1.6.59 i PraisonAI 4.6.59.

W aplikacji Kimai ciasteczko KIMAI_SESSION wydawane po weryfikacji hasła, ale przed ukończeniem TOTP, jest akceptowane przez każdą trasę /api, ponieważ konfiguracja security.yaml chroni API regułą IS_AUTHENTICATED, a ApiRequestMatcher kieruje istniejącą sesję przez główny firewall. Token Scheb TwoFactorToken spełnia tę regułę dostępu, a ApiVoter przyznaje dostęp API jego użytkownikowi, co pozwala atakującemu z prawidłowym hasłem konta korzystać z uwierzytelnionych operacji REST API bez podania drugiego czynnika. Problem naprawiono w wersji 2.59.0.

W module serwera WWW Secomea GateManager występuje podatność typu Session Fixation, która pozwala na przejęcie sesji użytkownika. Problem dotyczy wersji 11.5;0 oraz 11.4.625515072:0. Został naprawiony w wersji 11.6 lub 11.4.626194074 i nowszych.

W OpenAM domyślna konfiguracja inicjalizuje ciasteczko SSO iPlanetDirectoryPro z wyłączonym HttpOnly i bez ochronnego domyślnego SameSite, a przepływy zgody OAuth i OpenID Connect używają tego ciasteczka przez CsrfProtection jako tokenu CSRF. W połączeniu z XSS w tej samej domenie i kliknięciem przez użytkownika linku kontrolowanego przez atakującego ciasteczko może zostać odczytane i użyte do kradzieży sesji SSO oraz realizacji zgód zainicjowanych przez atakującego. Problem naprawiono w wersji 16.1.1.

W OpenAM ścieżka uwierzytelniania klienta private_key_jwt używa ClientJwksResolverCache bez niezawodnego powiązania buforowanego resolvera jwks_uri i zweryfikowanego asercji z oczekiwanym clientID w ClientCredentialsReader. Atakujący kontrolujący dowolnego zarejestrowanego klienta z opublikowanymi kluczami, w tym uzyskanego przez otwartą rejestrację dynamiczną, może uwierzytelnić się jako inny klient, którego klucze są udostępnione przez jwks_uri, i wystawiać tokeny w jego imieniu w różnych realmach w tym samym procesie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM GroovySandboxValueFilter pozwala uwierzytelnionemu autorowi skryptów po stronie serwera na ucieczkę z sandboxa pomimo domyślnych list dozwolonych i zabronionych klas. Użytkownik taki jak RealmAdmin podrealm, który może tworzyć lub edytować skrypty w kontekście wykonywanym, może wywoływać polecenia systemu operacyjnego jako konto serwera aplikacji OpenAM, przekraczając granicę administracji realmem i kompromitując JVM oraz wszystkie obsługiwane realmy. Problem naprawiono w wersji 16.1.1.

W OpenAM moduł uwierzytelniania OAuth2 aktualizuje istniejące konto lokalne atrybutami profilu, które mogą zawierać userPassword i inetUserStatus, przepisując hasło na nazwę użytkownika i reaktywując wyłączone konta. Brak filtrowania OAuth.removeRestrictedAccountUpdateAttributes pozwala tym polom poświadczeń i statusu dotrzeć do aktualizacji konta. Przy włączonym tworzeniu kont powtarzane logowanie OAuth powoduje, że domyślny łańcuch ldapService akceptuje nazwę użytkownika jako identyfikator i hasło, co pozwala nieuwierzytelnionemu atakującemu przejąć konto lokalne bez interakcji z dostawcą tożsamości. Problem naprawiono w wersji 16.1.1.

W OpenAM OAuthTokenStore odczytuje identyfikatory tokenów dostarczone przez wywołującego ze wspólnego Core Token Store (CTS) bez przestrzeni nazw przeznaczonej tylko dla OAuth, a OAuthAdapter akceptuje wiersz, którego BLOB rzekomo zawiera token OAuth, bez powiązania zaufanego typu CTS i weryfikacji integralności. Atakujący, który może umieścić kontrolowany JSON w CTS pod znanym identyfikatorem tokenu, na przykład przez Push Registration, a następnie anonimowe wywołanie zwrotne SNS w włączonym realmie, może wygenerować tokeny bearer OAuth i tokeny ID OpenID Connect z wybranym podmiotem, klientem, realmem i zakresem. Problem naprawiono w wersji 16.1.1.

W OpenAM anonimowe wywołanie zwrotne SNS Push Notification obsługiwane przez SnsMessageResource po wygaśnięciu messageId z dyspozytora w pamięci sięga do predykatu blob CTS, traktuje klucze najwyższego poziomu blob jako nazwy klas Java dla Class.forName i deserializuje kontrolowany przez atakującego JSON przez Jackson. Użytkownik o niskich uprawnieniach, który rozpocznie Push Registration i uzyska messageId, wspólny sekret i wyzwanie, może poczekać na wygaśnięcie, zastąpić trwały blob przez anonimowe wywołania zwrotne i wywołać ładowanie i konstrukcję klas w JVM OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM SessionRequestHandler w punkcie końcowym zarządzania sesjami nie wymusza kontroli własności ani uprawnień, gdy użytkownik o niskich uprawnieniach odpytuje informacje o sesji w środowiskach z stanowym przechowywaniem sesji. Wnioskujący znający identyfikator tożsamości celu może pobrać aktywne poświadczenia sesji innego użytkownika, w tym konta o wyższych uprawnieniach, i użyć ich do przejęcia tej sesji. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 niektóre punkty końcowe federacji w niedomyślnej konfiguracji klastrowej niekonsekwentnie kodują parametry dostarczane przez użytkownika, renderowane do HTML w ścieżce przekierowania cookie-hash SAML2. Nieuwierzytelniony atakujący może nakłonić użytkownika do otwarcia spreparowanego żądania i wykonania skryptu w domenie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 punkt końcowy autoryzacji OAuth 2.0 i OpenID Connect nie koduje wystarczająco parametrów dostarczanych przez użytkownika, zanim szablony FormPostResponse.ftl i checkSession.ftl wyrenderują je do HTML w trybie odpowiedzi form_post. Nieuwierzytelniony atakujący może nakłonić użytkownika do otwarcia spreparowanego żądania autoryzacji i wykonania skryptu w domenie OpenAM. Problem naprawiono w wersji 16.1.1.