Podatności PraisonAI

W systemie multi-agentowym PraisonAI przed wersją 4.6.37 występuje luka, która pozwala na wykorzystanie symlinków do zapisu dowolnych danych w wybranej lokalizacji na systemie ofiary. Problem dotyczy braku walidacji dla member.linkname oraz nieodrzucania członków symlink/hardlink.

W PraisonAI od wersji 4.2.1 do przed 4.6.59 powierzchnia wdrożeniowa AgentOS oparta na FastAPI pozostaje nieuwierzytelniona, mimo wcześniejszej poprawki dla CVE-2026-40151. Trasa czatu bezpośrednio wywołuje agent.chat(request.message), a żądania bez uwierzytelnienia lub z błędnym tokenem bearer również uruchamiają wdrożonego agenta.

W systemie PraisonAI przed wersją praisonaiagents 1.6.59 funkcje AgentTeam.launch oraz alias Agents rejestrują endpointy GET /{path}/list, POST /{path} i POST /{path}/{agent_id} bez kontroli dostępu. Zdalnie wystawiony serwer pozwala nieuwierzytelnionym klientom wyliczać agentów, zużywać zasoby modeli, uzyskiwać dostęp do prywatnego kontekstu oraz wywoływać narzędzia agentów lub efekty uboczne workflow.

PraisonAI przed wersją 4.6.78 ma podatność w module `deploy/api.py`, który generuje kod serwera Python przez bezpośrednie interpolowanie parametru `agents_file` do f-stringa, który jest następnie zapisywany do pliku i wykonywany przez `subprocess.Popen()`. Atakujący kontrolujący wartość `agents_file` może wstrzyknąć dowolny kod Python.

W PraisonAI przed wersją 0.1.6, gdy PLATFORM_JWT_SECRET nie jest ustawione, używany jest publiczny klucz deweloperski dev-secret-change-me do podpisywania HS256, a zabezpieczenia startowe i wydawania tokenów są wyłączone, ponieważ PLATFORM_ENV domyślnie przyjmuje wartość dev. Nieuwierzytelniony atakujący może podpisać JWT z dowolną wartością sub, który zostanie zaakceptowany jako tożsamość, umożliwiając podszycie się pod użytkownika lub właściciela obszaru roboczego.

W PraisonAI przed wersją 0.1.6, gdy PLATFORM_JWT_SECRET nie jest ustawione, JWT_SECRET przyjmuje publiczną wartość dev-secret-change-me, a zabezpieczenie produkcyjne nie działa, gdy PLATFORM_ENV również nie jest ustawione (domyślnie dev). Zdalny nieuwierzytelniony atakujący może wygenerować token HS256 z dowolnym sub i email, który zostanie zaakceptowany przez AuthService._verify_token() i get_current_user dla chronionych tras API.

W PraisonAI przed wersją 1.7.2 narzędzie codeMode w src/praisonai-ts/src/tools/builtins/code-mode.ts wykonuje model-generated JavaScript za pomocą new Function() i with(sandbox), a bloklistę opartą na wyrażeniach regularnych można obejść używając Function('return this')() do odzyskania obiektu globalnego i dynamicznego konstruowania nazwy modułu child_process. Atakujący mogący wpływać na argument code może uzyskać dostęp do możliwości procesu hosta, czytać lub zapisywać pliki, pozyskiwać poświadczenia środowiskowe i wykonywać polecenia systemowe z uprawnieniami procesu PraisonAI.

W PraisonAI od wersji 1.6.0 do 1.7.2, AgentOS w src/praisonai-ts/src/os/agentos.ts używa domyślnego adresu 0.0.0.0 z src/praisonai-ts/src/os/config.ts i rejestruje GET /api/agents oraz POST /api/chat bez oprogramowania pośredniczącego uwierzytelniania. Zdalny wywołujący mogący połączyć się z usługą może uzyskać nazwy agentów, role i prefiksy instrukcji oraz wywołać wybranego agenta, potencjalnie uzyskując dostęp do jego narzędzi, pamięci, zewnętrznych API, poświadczeń i stanu przepływu pracy.

W PraisonAI od wersji 1.5.0 do 1.7.2, MCPServer.startHttp() w src/praisonai-ts/src/mcp/server.ts wiąże się bez ograniczenia hosta i przekazuje każde żądanie HTTP POST do handleRequest() bez uwierzytelniania i autoryzacji. Każdy klient sieciowy mogący połączyć się z portem może wywołać tools/list, tools/call, resources/read lub prompts/get, powodując uruchomienie zarejestrowanych procedur obsługi z poświadczeniami serwera i uprawnieniami procesu lub ujawnienie zarejestrowanych danych.

W PraisonAI od wersji 1.4.0 do 1.7.2, codeMode w src/praisonai-ts/src/tools/builtins/code-mode.ts wykonuje niezaufany JavaScript za pomocą new Function() wewnątrz with(sandbox) i opiera się na małej blokliście kodu źródłowego oraz przesłoniętych właściwościach process i require. Kod może użyć ({}).constructor.constructor do odzyskania prawdziwego konstruktora Function, uzyskać process i process.mainModule.require oraz dotrzeć do API systemu plików i podprocesów hosta mimo reklamowanego sandboxa. Atakujący kontrolujący dane wejściowe codeMode mogą czytać sekrety, modyfikować pliki, wykonywać polecenia lub wyczerpać proces hosta.

W PraisonAI, systemie zespołów wieloagentowych, w wersjach przed 4.6.62 plik src/praisonai/praisonai/tools/multiedit.py przekazuje kontrolowany przez LLM parametr filepath bezpośrednio do funkcji open bez odrzucania przechodzenia ścieżek, rozwiązywania dowiązań symbolicznych, granicy obszaru roboczego ani sprawdzania chronionych ścieżek. Agenci podatni na wpływ promptów mogą odczytywać pliki lub je nadpisywać.

W PraisonAI, systemie zespołów wieloagentowych, w wersjach przed 4.6.58 funkcja praisonai.jobs.server.create_app montuje praisonai.jobs.router.create_router pod /api/v1/runs bez uwierzytelniania i autoryzacji dla poszczególnych zadań. Klienci sieciowi mogą przesyłać kontrolowane przez atakującego prompty i konfigurację agenta, wyświetlać i odczytywać zadania, strumieniować wyniki oraz anulować lub usuwać zadania innych.

W systemie PraisonAI przed wersją 4.6.58 middleware uwierzytelniające (APIKeyAuthMiddleware lub JWTAuthMiddleware) przepuszczają żądania, gdy brakuje klucza PRAISONAI_API_KEY lub PRAISONAI_JWT_SECRET oraz odpowiadającej wartości przepisu. W efekcie nieuwierzytelnieni klienci mogą uzyskać dostęp do wykonywania przepisów oraz powierzchni wejścia i wyjścia, mimo że operator włączył uwierzytelnianie.

W PraisonAI przed wersją 4.6.59 domyślne aplikacje hosta UI udostępniają endpoint POST /api/mcp/connect bez wymaganego uwierzytelnienia i przyjmują kontrolowane przez wywołującego wartości command oraz args przekazywane do StdioMCPClient w celu uruchomienia lokalnego procesu. Ponieważ UI domyślnie nasłuchuje na 0.0.0.0, osiągalny nieuwierzytelniony klient może wykonywać polecenia jako konto usługi UI, nawet jeśli późniejsza faza uzgadniania MCP zakończy się niepowodzeniem.

W systemie PraisonAI (wersje przed praisonai 4.6.59 i praisonaiagents 1.6.59) nieuwierzytelniony endpoint POST /api/v1/runs Jobs API przyjmuje kontrolowane przez atakującego pole agent_yaml. Pole approve pozwala oznaczyć execute_command jako zatwierdzone w YAML zanim mechanizm @require_approval sprawdzi krytyczne narzędzia, co umożliwia zdalne wywołanie dowolnych poleceń systemu operacyjnego przez agenta LLM bez poświadczeń i interakcji operatora.

PraisonAI przed wersją 4.6.58, funkcja _handle_connection() w Browser Server sprawdza pochodzenie rozszerzenia Chrome za pomocą re.match() i niezakotwiczonego wyrażenia chrome-extension://[a-z0-9]{32}. Dodatkowe znaki na końcu przechodzą przed websocket.accept(), co pozwala na komendy start_session i nieautoryzowaną automatyzację przeglądarki. Problem został naprawiony w wersji 4.6.58.

PraisonAI przed wersją 4.6.40 zawiera podatność na wstrzyknięcie poleceń w dołączonym workflow GitHub Actions dla Claude. Nazwa gałęzi pull requesta jest osadzana w bloku Bash bez walidacji, a każdy komentarz @claude może uruchomić zadanie, co pozwala zewnętrznym kontrybutorom na wykonanie dowolnego kodu w runnerze.

PraisonAI przed wersją 4.6.40 udostępnia niezabezpieczone API sterowania agentami przez sieć, gdy zmienna CALL_SERVER_TOKEN nie jest skonfigurowana. Funkcja uwierzytelniająca verify_token() przepuszcza żądania bez tokena. Serwer wywołań domyślnie nasłuchuje na 0.0.0.0, co pozwala każdemu klientowi na listowanie agentów, podgląd metadanych i instrukcji, wywoływanie oraz wyrejestrowywanie agentów.

PraisonAI domyślnie generuje serwer API Flask bez uwierzytelniania, który nasłuchuje na wszystkich interfejsach sieciowych (0.0.0.0) i udostępnia wrażliwe endpointy. Atakujący może wysyłać żądania do endpointów /chat i /agents bez żadnego uwierzytelnienia, co pozwala na wykonanie kodu LLM z kluczami API dostępnymi w środowisku.

W systemie PraisonAI przed wersją 4.6.40 (odpowiadającą wersji 1.6.40 biblioteki praisonaiagents) wykryto podatność w funkcji `execute_code()` w pliku `praisonaiagents/tools/python_tools.py`. Atakujący może ominąć tryb piaskownicy subprocess, używając `print.__self__` do uzyskania dostępu do modułu `builtins`, a następnie poprzez `vars()` i konstrukcję łańcucha znaków wywołać `__import__`, co prowadzi do wykonania dowolnych poleceń systemu operacyjnego na hoście.

PraisonAI przed wersją 4.6.40 zawiera przykładowy serwer A2A, który udostępnia nieuwierzytelniony endpoint A2A JSON-RPC i rejestruje narzędzie calculate(expression) zaimplementowane za pomocą eval() w Pythonie. Serwer wiąże się z 0.0.0.0. Zdalny, nieuwierzytelniony atakujący może wysłać wiadomość message/send do /a2a, co powoduje, że LLM może wywołać narzędzie calculate, prowadząc do wykonania dowolnego kodu Python na serwerze. Podatność dotyczy wdrożeń korzystających z oficjalnego przykładu A2A lub podobnych nieuwierzytelnionych wdrożeń A2A z niebezpiecznymi narzędziami.

PraisonAI przed wersją 1.6.78 zawiera podatność zdalnego wykonania kodu w funkcji CodeAgent._execute_python(), która wykonuje kod Python generowany przez model LLM bez walidacji AST, ograniczeń importów ani izolacji piaskownicy. Atakujący mogą wpływać na wynik LLM poprzez wstrzykiwanie promptów, aby wykraść wszystkie sekrety środowiskowe i wykonać dowolny kod na systemie hosta.

PraisonAI przed wersją 4.6.78 zawiera podatności umożliwiające dowolny zapis plików i wykonanie poleceń w komponencie AICoder. Brak walidacji ścieżek i sanityzacji poleceń w wywołaniach narzędzi LLM pozwala atakującym na wstrzykiwanie złośliwych promptów przez interfejs czatu.

Podatność w PraisonAI przed wersją 4.6.78 pozwala na wstrzyknięcie SQL/CQL poprzez nieprawidłową walidację argumentu wymiaru w backendach PGVector i Cassandra. Atakujący może przekazać złośliwy ciąg znaków, który zostanie bezpośrednio wstawiony do zapytania CREATE TABLE, co może prowadzić do wykonania nieautoryzowanych operacji na bazie danych.

PraisonAI przed wersją 4.6.78 zawiera podatność na wstrzykiwanie kodu w pliku deploy/api.py. Parametr agents_file jest bezpośrednio interpolowany do f-stringa bez sanityzacji, co pozwala atakującym na wstrzyknięcie dowolnego kodu Python, który wykonuje się podczas uruchamiania wygenerowanego kodu serwera przez subprocess.Popen().

PraisonAI to system zespołów wieloagentowych. Przed wersją 1.6.32 logika sprawdzania URL miała błąd logiczny, który mógł być obejściem przez atakujących, prowadząc do ataków SSRF.

PraisonAI przed wersją 4.5.133 zawiera podatność na wstrzyknięcie identyfikatora SQL w SQLiteConversationStore, gdzie wartość table_prefix jest bezpośrednio łączona z zapytaniami SQL bez walidacji. Atakujący kontrolujący table_prefix może wstrzyknąć dowolne fragmenty SQL, modyfikując strukturę zapytań.

Most przeglądarkowy w PraisonAI (wersje poniżej 4.5.139 oraz praisonaiagents poniżej 1.5.140) jest podatny na nieuwierzytelnione przejęcie sesji zdalnej z powodu braku uwierzytelniania i obejścia sprawdzania origin na endpointcie WebSocket /ws. Serwer domyślnie nasłuchuje na 0.0.0.0 i akceptuje klientów bez nagłówka Origin.

Silnik workflow w PraisonAI (wersje poniżej 4.5.139 oraz praisonaiagents poniżej 1.5.140) umożliwia wykonanie dowolnych poleceń i kodu poprzez niezaufane pliki YAML. Kroki typu run:, script: i python: są wykonywane bez walidacji, sandboxingu ani potwierdzenia użytkownika.

PraisonAI przed wersją 4.5.115 zawiera podatność w metodzie AgentService.loadAgentFromFile, która używa biblioteki js-yaml do parsowania plików YAML bez wyłączania niebezpiecznych tagów (takich jak !!js/function i !!js/undefined). Pozwala to atakującemu na stworzenie złośliwego pliku YAML, który po sparsowaniu wykonuje dowolny kod JavaScript.

PraisonAI przed wersją 1.5.115 ma lukę w funkcji execute_code() w trybie sandbox. Lista zablokowanych atrybutów AST w podprocesie jest niekompletna, co pozwala na ominięcie sandboksa i wykonanie dowolnego kodu Python.

PraisonAI przed wersją 4.5.97 zawiera podatność w OAuthManager.validate_token(), która zwraca True dla każdego tokena nieznalezionego w wewnętrznym magazynie (domyślnie pustym). Każde żądanie HTTP do serwera MCP z dowolnym tokenem Bearer jest traktowane jako uwierzytelnione, dając pełny dostęp do wszystkich zarejestrowanych narzędzi i możliwości agentów.

PraisonAI to system wieloagentowy. Przed wersją 4.5.97 serwer bramy PraisonAI akceptuje połączenia WebSocket na /ws i udostępnia topologię agentów na /info bez uwierzytelniania. Każdy klient sieciowy może się połączyć, wyliczyć zarejestrowanych agentów i wysyłać dowolne wiadomości do agentów i ich zestawów narzędzi.

PraisonAI przed wersją 1.5.90 zawiera lukę w funkcji execute_code(), która umożliwia ominięcie trójwarstwowego sandboksa przez przekazanie podklasy str z nadpisaną metodą startswith(), prowadząc do wykonania dowolnych poleceń OS.

PraisonAI w wersjach od 4.5.15 do 4.5.69 zawiera podatność na wykonanie dowolnego kodu systemowego poprzez argument CLI --mcp, który jest przekazywany bez walidacji do shlex.split() i anyio.open_process(). Atakujący może wykorzystać tę lukę do wykonania dowolnych poleceń w kontekście użytkownika procesu.

PraisonAI to system wieloagentowy. Przed wersją 4.5.90 funkcja get_all_user_threads konstruuje zapytania SQL przez f-stringi z nieskapowanymi identyfikatorami wątków pobranymi z bazy danych. Atakujący może przechować złośliwy identyfikator wątku przez update_thread, a przy ładowaniu listy wątków wstrzyknięty kod SQL wykonuje się, dając pełny dostęp do bazy danych.

W PraisonAI od wersji 4.5.115 do przed 4.6.61 udokumentowany punkt wejścia CLI nadal udostępnia trasy subskrypcji i zdarzeń A2U bez uwierzytelniania. Opakowanie CLI nie udostępnia --api-key, nie instaluje oprogramowania pośredniczącego API-key i nie generuje tokenu dla A2U; jeśli zmienna A2U_AUTH_TOKEN nie jest ustawiona, uwierzytelnianie jest wyłączone. Podatność naprawiono w wersji 4.6.61.

W PraisonAI od wersji 4.5.110 do przed 4.6.61 SandlockSandbox, który ma być piaskownicą egzekwowaną przez jądro, w przypadku gdy moduł sandlock importuje się, ale zgłasza niedostępność Landlock, nie zawodzi bezpiecznie. Metody execute() i run_command() po cichu przechodzą do SubprocessSandbox, który nie egzekwuje ograniczeń systemu plików ani sieci. Podatność naprawiono w wersji 4.6.61.

W PraisonAI od wersji 4.5.87 do przed 4.6.61 polityka niebezpiecznych narzędzi sprawdza tylko narzędzia zadeklarowane w TEMPLATE.yaml requires.tools. Dla przepisów opartych na krokach workflow.yaml jest ładowany przez YAMLWorkflowParser, który rozwiązuje narzędzia na poziomie agenta i zachowuje approve: na najwyższym poziomie, co pozwala niezaufanemu przepisowi zadeklarować execute_command i samodzielnie go zatwierdzić bez allow_dangerous_tools=True. Podatność naprawiono w wersji 4.6.61.

W PraisonAI w wersjach od 4.6.10 do przed 4.6.59 mostek LocalManagedAgent / SandboxedAgent konwertuje operacje na plikach (read_file, list_files, write_file) na polecenia powłoki, używając surowych argumentów ścieżek. Napastnik mogący wpłynąć na argument ścieżki może wyłamać się z cytowanej ścieżki i wykonać dowolne polecenia powłoki w środowisku obliczeniowym (host lub kontener Docker).

W PraisonAI w wersjach od 4.5.126 do przed 4.6.59 walidacja webhook_url w Async Jobs API nie jest powiązana z późniejszym żądaniem sieciowym. Nazwa hosta kontrolowana przez napastnika może najpierw rozwiązać się na publiczny adres IP podczas walidacji, a następnie na adres loopback/prywatny/metadanych chmury podczas dostarczania webhooka, omijając zabezpieczenie SSRF. To niepełna poprawka / obejście dla GHSA-8frj-8q3m-xhgm.

W PraisonAI w wersjach od 2.6.0 do przed 4.6.59 loader szablonów akceptuje URI GitHub z refami i zapisuje ścieżkę oraz ref bez normalizacji, łącząc je w ścieżkę cache bez sprawdzenia, czy pozostaje w katalogu cache. Spreparowany ref z sekwencjami ../ pozwala wyjść poza katalog cache, zapisać .cache_meta.json poza nim, a w pewnych warunkach usunąć katalog poza cache przez shutil.rmtree.

W PraisonAI komponent praisonai.bots.HTTPApproval renderuje argumenty oczekującego zatwierdzenia narzędzia bezpośrednio do HTML panelu zatwierdzeń. Argument narzędzia kontrolowany przez atakującego może wstrzyknąć JavaScript do tej strony. Gdy człowiek otworzy URL zatwierdzenia, skrypt wykona się w origin panelu i może wysłać żądanie POST do endpointu /approve/{request_id}/decide, powodując zwrócenie approved=True.

W PraisonAI ścieżka recipe.run() egzekwuje politykę blokowania domyślnie zabronionych niebezpiecznych narzędzi przez _check_tool_policy(), ale ścieżka strumieniowa recipe.run_stream() ładuje tę samą receptę i wywołuje _execute_recipe() bez tej kontroli. W rezultacie recepta deklarująca execute_command w requires.tools jest odrzucana przez recipe.run(), ale osiąga silnik wykonania przez recipe.run_stream() mimo allow_dangerous_tools=False.

W PraisonAI komponent LinearBot uruchamia publiczny nasłuch webhooków na 0.0.0.0 i traktuje LINEAR_WEBHOOK_SECRET jako opcjonalny. Gdy sekret jest nieobecny, _handle_webhook() całkowicie pomija weryfikację Linear-Signature. Nieuwierzytelniony atakujący sieciowy może wysłać sfałszowane żądanie Linear-Event: AgentSession, które zostanie przetworzone i przekazane do BotSessionManager.chat().

W PraisonAI polecenie praisonai recipe serve kieruje do przestarzałego polecenia Typer, które może uruchomić serwer HTTP Recipe na interfejsie innym niż localhost bez uwierzytelniania. Ponieważ config.auth jest nieobecny, create_app() nie dołącza middleware klucza API ani JWT. Nieuwierzytelnione żądania mogą dotrzeć do API recipe oraz, gdy włączone, do /admin/reload.

W PraisonAI bot Slack stosuje skonfigurowane allowed_users, allowed_channels i politykę unknown-user pairing w normalnym handlerze zdarzeń wiadomości, ale nie w sąsiednim handlerze zdarzeń app_mention. Użytkownik workspace Slack, który może wspomnieć bota w kanale, może wywołać agenta PraisonAI nawet gdy nadawca nie jest na liście dozwolonych, kanał nie jest dozwolony, a unknown_user_policy="deny".

W PraisonAI funkcja Dynamic Context Discovery udostępnia narzędzia pomocnicze artefaktów przez ctx.get_tools(), które nie egzekwują, że podany artifact_path jest artefaktem utworzonym przez skonfigurowany store ani że znajduje się w katalogu bazowym artefaktów. Narzędzia artifact_head, artifact_tail, artifact_grep i artifact_chunk opakowują ścieżkę podaną przez wywołującego w ArtifactRef i odczytują ją z systemu plików hosta. Pozwala to na odczyt plików dostępnych dla procesu PraisonAI, takich jak .env, poświadczenia chmurowe czy klucze SSH.

W PraisonAI moduł Dynamic Context udostępnia magazyny historii i logów terminala oparte na systemie plików oraz fabryki narzędzi wywoływalnych przez agenta. Narzędzia przyjmują argumenty run_id i agent_id od wywołującego, a magazyny łączą te wartości w ścieżki bez odrzucania ścieżek absolutnych ani traversal .. . Ponieważ run_id może być ścieżką absolutną, a agent_id może zawierać traversal, wywołujący o niższym zaufaniu może odczytać pliki .jsonl i .log poza katalogiem bazowym Dynamic Context.

W PraisonAI komponent praisonai.bots.DiscordApproval zatwierdza oczekujące wywołanie niebezpiecznego narzędzia, gdy w skonfigurowanym kanale Discord pojawi się dowolna późniejsza wiadomość niebota zaklasyfikowana jako zatwierdzenie, np. yes. W rezultacie każdy użytkownik mogący pisać w kanale zatwierdzeń może zatwierdzić oczekujące wywołanie narzędzia o wysokim ryzyku, wysyłając yes po pojawieniu się wiadomości zatwierdzającej.