Podatności PraisonAI

W PraisonAI przed wersją praisonaiagents 1.6.62 funkcje searxng_search oraz dostawca SearxNG w search_web przekazują kontrolowany przez LLM parametr searxng_url bezpośrednio do requests.get bez walidacji schematu, hosta, portu ani rozwiązanego adresu. Treści z prompt injection mogą kierować wyszukiwanie do wewnętrznych usług JSON, rozróżniać otwarte i zamknięte porty oraz próbować żądań do metadanych chmury.

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 systemie PraisonAI przed wersją 4.6.62 ustawienie zmiennej PRAISONAI_CALL_AUTH na wartość disabled powoduje, że funkcja verify_token akceptuje żądania do /api/v1/agents/{id}/invoke bez uwierzytelniania CALL_SERVER_TOKEN. Wdrożenia korzystające z reklamowanego wyłączenia uwierzytelniania mogą narazić zarejestrowanych agentów oraz ich narzędzia i prywatny kontekst na nieuwierzytelnione wywołania.

W systemie PraisonAI przed wersją 4.6.59 procedury obsługi webhooków botów WhatsApp i Linear weryfikują podpisy HMAC tylko wtedy, gdy skonfigurowano WHATSAPP_APP_SECRET lub LINEAR_WEBHOOK_SECRET; w przeciwnym razie przetwarzają i wysyłają niepodpisane treści żądań. Zdalny nieuwierzytelniony klient mogący dotrzeć do trasy webhooka może fałszować wiadomości, komentarze lub zdarzenia sesji agenta, podszywać się pod użytkowników platformy i zakłócać przetwarzanie bota.

W systemie PraisonAI przed wersją 4.6.59 nieuwierzytelnione API Jobs akceptuje bezwzględną lub podatną na traversację ścieżkę agent_file w POST /api/v1/runs i przekazuje ją do wykonawcy zadania bez listy dozwolonych obszarów roboczych ani sprawdzenia granic. Zdalny wywołujący może spowodować otwarcie przez serwer plików dostępnych dla konta usługi, ujawniając poświadczenia, klucze, zmienne środowiskowe i inne lokalne dane.

W systemie PraisonAI przed wersją 4.6.59 wrappery CODE_TOOLS utrzymują _workspace_root jako None i przekazują workspace=None do funkcji pomocniczych read_file, search_replace i apply_diff, które wymuszają ograniczenie ścieżek tylko dla niepustego workspace. Aplikacja udostępniająca code_read_file, code_search_replace lub code_apply_diff przed set_workspace może pozwolić na odczyt i modyfikację plików poza zamierzonym katalogiem projektu.

W systemie PraisonAI przed wersją praisonaiagents 1.6.59 plik src/praisonai-agents/praisonaiagents/tools/email_tools.py interpoluje kontrolowane przez LLM wartości from_addr, subject i query bezpośrednio do kryteriów IMAP SEARCH w cudzysłowach. Osadzone znaki cudzysłowu, ukośnika wstecznego, nowej linii lub null mogą uciec z zamierzonego kryterium i zmienić operacje IMAP, gdy search_emails, reply_email lub archive_email są udostępnione agentowi z skonfigurowanymi poświadczeniami e-mail, umożliwiając dostęp, modyfikację, usunięcie lub zakłócenie połączenia z danymi skrzynki pocztowej.

PraisonAI przed wersją 4.6.51 udostępnia endpoint /api/v1/runs bez uwierzytelnienia. Każdy, kto ma dostęp do sieci, może przesyłać zadania, odczytywać wyniki, anulować uruchomienia lub usuwać zadania, używając poświadczeń operatora. Poprawka dodaje middleware PRAISONAI_JOBS_API_KEY.

PraisonAI przed wersją 4.6.58 ma lukę w create_auth_middleware(), która pozwala na żądania bez uwierzytelnienia, gdy brakuje PRAISONAI_API_KEY lub PRAISONAI_JWT_SECRET. Zewnętrznie powiązany serwer Recipe może przyjmować nieuwierzytelnione żądania POST /v1/recipes/run, mimo że uwierzytelnianie jest włączone.

PraisonAI przed wersją 4.6.58 ma lukę w MCP HTTP Stream _validate_origin, która używa startswith do sprawdzania pochodzenia, co pozwala atakującemu na użycie origin localhost.attacker.com. Strona internetowa może wysyłać żądania Content-Type: text/plain bez preflight i wywoływać narzędzia bez klucza API, w tym zapisy plików.

PraisonAI to system wieloagentowy. Przed wersją 4.6.58, funkcje _create_agents_app() i _create_unified_app() nie instalują sprawdzania poświadczeń, co pozwala nieuwierzytelnionym wywołaniom na dostęp do POST /agents i POST /api/v1/agents/{id}/invoke. Problem naprawiono w wersji 4.6.58.

PraisonAI to system wieloagentowy. Przed wersją 4.6.51, funkcja is_path_within_directory() używa os.path.abspath() zamiast os.path.realpath() do sprawdzania granic katalogu roboczego. Dowiązanie symboliczne wewnątrz katalogu może wskazywać na zewnątrz i nadal przechodzić kontrolę, umożliwiając narzędziom takim jak read_file dostęp do plików poza skonfigurowanym katalogiem. Problem naprawiono w wersji 4.6.58.

PraisonAI to system wieloagentowy. Przed wersją 4.6.51, funkcja _create_agents_app() nie uwierzytelnia żądań POST /agents ani POST /agents/{agent_name}. Brakujące lub nieprawidłowe wartości bearer i X-API-Key nadal umożliwiają wykonanie agenta. Problem naprawiono w wersji 4.6.58.

PraisonAI to system wieloagentowy. Przed wersją 4.6.58, funkcja JobSubmitRequest.validate_webhook_url() akceptuje webhook_url, gdy rozwiązywanie nazwy zgłasza socket.gaierror, ponieważ ścieżka wyjątku używa 'except socket.gaierror: pass'. Funkcja JobExecutor._send_webhook() później wykonuje świeże wyszukiwanie, co pozwala zmianom DNS na przekierowanie żądania do wewnętrznego serwisu. Problem naprawiono w wersji 4.6.58.

PraisonAI przed wersją 4.6.58 zawiera podatność w API Jobs, gdzie walidacja adresu webhook_url zawodzi w przypadku błędu socket.gaierror i nie wiąże zweryfikowanego adresu z późniejszym żądaniem. Atakujący może podać adres webhook_url, który później rozwiąże się na 127.0.0.1, 169.254.169.254 lub inny wewnętrzny adres.

PraisonAI to system wieloagentowy. Od wersji 4.6.34 do 4.6.58, funkcja _create_agents_app() nie uwierzytelnia żądań POST /agents ani POST /agents/{agent_name}. Osoba wywołująca sieciowo może wywoływać skonfigurowane agenty bez poświadczeń, nawet gdy dostarczono klucz API. Problem naprawiono w wersji 4.6.58.

PraisonAI przed wersją 4.6.58 ma podatność w obsłudze MCP HTTP Stream, gdzie handler mcp_post tworzy nowy wpis _sessions dla każdego żądania initialize, ale nie wywołuje _cleanup_sessions ani nie egzekwuje maksymalnej liczby sesji. Nieuwierzytelniony atakujący może wyczerpać pamięć.

PraisonAI przed wersją 1.6.58 ma podatność w funkcji ast_grep_rewrite, która nie posiada dekoratora @require_approval używanego przez podobne narzędzia mutacji. Przy dry_run=False, wywołanie kontrolowane przez agenta może przekazać --update-all i szeroką ścieżkę do przepisania plików bez wymaganego zatwierdzenia.

PraisonAI przed wersją 4.6.58 ma podatność w metodzie _validate_origin MCP HTTP Stream, która akceptuje request_origin.startswith(allowed), przez co atakujący może użyć origin localhost.evil.example, który pasuje do listy dozwolonych localhost. Bez klucza API, złośliwa strona internetowa może wysyłać żądania tools/call do lokalnego serwera MCP i wykonywać wystawione narzędzia.

PraisonAI to system wieloagentowy. Przed wersją praisonaiagents 1.6.58, AgentServer udostępnia ServerConfig.auth_token, ale AgentServer._create_app nie sprawdza go na żadnej trasie. Zdalny wywołujący może subskrybować, publikować i wykonywać inne działania bez ważnego tokena bearer lub X-Auth-Token, nawet gdy uwierzytelnianie jest skonfigurowane. Problem został naprawiony w wersji 1.6.58.

PraisonAI to system wieloagentowy. Przed wersją praisonaiagents 1.6.58, konstruktor FileMemory łączy nieoczyszczone user_id do self.user_path. Osoba wywołująca z ../ lub separatorami ścieżek może opuścić katalog pamięci i zapisać dane JSON w dowolnych lokalizacjach zapisywalnych przez proces. Poprawka oczyszcza user_id przed skonstruowaniem self.user_path. Problem został naprawiony w wersji 1.6.58.

PraisonAI to system wieloagentowy. Przed wersją praisonaiagents 1.6.58, spider_tools._host_is_blocked() nie rozwiązuje zwykłych nazw hostów przed ich pobraniem przez scrape_page. Nazwa hosta taka jak 127.0.0.1.nip.io przechodzi walidację i rozwiązuje się do loopback, umożliwiając wewnętrzny dostęp HTTP. Poprawka używa socket.getaddrinfo i zamyka się w przypadku błędów DNS. Problem został naprawiony w wersji 1.6.58.

PraisonAI to system wieloagentowy. Przed wersją praisonaiagents 1.6.58, funkcja web_crawl waliduje tylko początkowy URL przed użyciem _crawl_with_httpx z httpx.Client(follow_redirects=True). Cele przekierowań nie są ponownie walidowane, więc atakujący, który wpływa na cel crawl, może przekierować publiczny URL do loopback, prywatnej sieci lub usług metadata chmury, podczas gdy ALLOW_LOCAL_CRAWL pozostaje wyłączone. Pobrana wewnętrzna odpowiedź jest zwracana do kontekstu agenta. Problem został naprawiony w wersji 1.6.58.

PraisonAI Platform API przed wersją 0.1.4 ma dwie luki autoryzacyjne, które razem łamią izolację przestrzeni roboczych. Warstwa usług wykonuje globalne wyszukiwania po kluczu głównym bez sprawdzania własności przestrzeni roboczej, a endpointy zarządzania członkami wymagają tylko roli 'member', co pozwala każdemu członkowi na awans do właściciela i usunięcie oryginalnego właściciela.

PraisonAI przed wersją 1.6.58 zawiera podatność SSRF w narzędziu web_crawl. Ochrona sprawdza tylko początkowy adres URL, ale po przekierowaniu lub zmianie DNS łączy się z wewnętrznymi adresami, takimi jak pętla zwrotna, sieć prywatna lub metadane chmury. Atakujący może wpłynąć na URL przekazywany do web_crawl, aby uzyskać odpowiedzi z tych wewnętrznych zasobów.

PraisonAI w wersjach 1.5.128 do 1.6.57 zawiera podatność SSRF w funkcji web_crawl(). Mimo walidacji początkowego URL, nie sprawdza celów przekierowań, co pozwala atakującemu na dostęp do wewnętrznych zasobów przez publiczny URL przekierowujący do pętli zwrotnej lub sieci prywatnej. Jest to niekompletna poprawka wcześniejszych podatności SSRF.

PraisonAI w wersjach 3.9.26 do 4.6.57 (praisonai) i 0.12.12 do 1.6.57 (praisonaiagents) ma podatność na wykonanie kodu w funkcji include przepływu pracy. Funkcja _execute_include() importuje i uruchamia kod z tools.py bez odpowiednich zabezpieczeń, co pozwala atakującemu na wykonanie dowolnego kodu Python, jeśli może wpłynąć na lokalny katalog przepływu pracy.

Podatność w PraisonAI w wersjach przed 4.6.40 umożliwia wykonanie dowolnego kodu poprzez niechronione wywołania spec.loader.exec_module w pliku agents_generator.py. Funkcje te przyjmują parametr module_path z konfiguracji YAML i wykonują go bez walidacji, co pozwala atakującemu na zdalne wykonanie kodu.

Podatność w PraisonAI (wersje przed 4.6.40), w której ukryte metadane na stronie internetowej powodują, że agenci PraisonAI zapisują treści kontrolowane przez atakującego do dowolnych ścieżek. Funkcja write_file pomija walidację ścieżki, gdy workspace=None (zawsze w produkcji).

Podatność w PraisonAI (wersje przed 4.6.40) pozwala na automatyczne pobieranie treści z adresów URL podanych w promptach CLI. Atakujący może wstrzyknąć złośliwy URL, co skutkuje pobraniem zasobów z localhostu i wstrzyknięciem ich do kontekstu modelu, bez żadnych ograniczeń adresów prywatnych.

Podatność w PraisonAI (wersje przed 4.6.40) – niekompletna poprawka poprzedniej luki (CVE-2026-44336). Nieuwierzytelniony atakujący może odczytać dowolny plik na hoście (np. /etc/passwd, klucze SSH) poprzez wywołanie MCP tools/call do praisonai.workflow.show.

W PraisonAI przed wersją 4.6.40 (oraz praisonaiagents przed 1.6.40) walidacja URL w narzędziu `spider_tools` może zostać ominięta przez użycie alternatywnych kodowań hosta loopback. Walidacja blokuje tylko konkretne ciągi (np. 'localhost', '127.0.0.1'), ale nie normalizuje nazw hostów ani nie sprawdza końcowego adresu IP. Pozwala to na SSRF do usług loopback.

PraisonAI przed wersją 1.6.78 zawiera podatność zdalnego wykonania kodu w menedżerze wtyczek. Ładuje on i wykonuje dowolne pliki Python (.py) z katalogów .praisonai/plugins/ bez weryfikacji podpisu, integralności ani izolacji. Atakujący, który może umieścić złośliwy plik .py w katalogu wtyczek (np. przez path traversal, atak na łańcuch dostaw lub skompromitowaną zależność), uzyskuje zdalne wykonanie kodu podczas inicjalizacji systemu wtyczek.

PraisonAI przed wersją 1.6.78 zawiera podatność zdalnego wykonania kodu w funkcji SkillTools.run_skill_script(), która wykonuje skrypty bez walidacji ścieżki. Atakujący mogą podać absolutne ścieżki plików, aby uruchomić dowolne skrypty z dowolnej lokalizacji systemu plików, w tym spoza zamierzonego katalogu roboczego.

PraisonAI przed wersją 4.6.78 zawiera podatność zdalnego wykonania kodu w funkcji JobWorkflowExecutor._exec_inline_python() z powodu niewystarczającej walidacji AST skryptów przepływu pracy. Atakujący mogą tworzyć złośliwe pliki YAML przepływu pracy z instrukcjami import os, a następnie wywołaniami os.system(), które omijają zabezpieczenia piaskownicy i wykonują dowolne polecenia systemowe z uprawnieniami procesu.

Podatność w PraisonAI przed wersją 4.6.78 w trybie webhook AgentMail nie weryfikuje podpisów webhook Svix, co pozwala nieuwierzytelnionym atakującym na fałszowanie zdarzeń message.received. Atakujący mogą wysyłać spreparowane ładunki JSON do punktu końcowego webhook, aby wywołać skonfigurowanych agentów z dowolnym adresem nadawcy i treścią wiadomości.

Podatność w PraisonAI przed wersją 4.6.78 umożliwia ominięcie uwierzytelniania w endpointach API agentów (agent_invoke.py) gdy opcja PRAISONAI_CALL_AUTH=disabled jest skonfigurowana. Zabezpieczenie ograniczające dostęp tylko do localhosta opiera się na nagłówku Host z żądania HTTP, który może być sfałszowany przez atakującego.

PraisonAI przed wersją 4.6.78 niebezpiecznie koduje wartości konfiguracji wdrożenia podczas generowania kodu źródłowego Python dla serwerów API. Atakujący mogą wstrzykiwać dowolne wyrażenia Python przez parametry konfiguracyjne deploy.api.host i agents_file, które wykonują się podczas uruchamiania serwera lub obsługi żądań.

PraisonAI przed wersją 1.6.78 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w narzędziu web_crawl. Narzędzie to sprawdza nazwy hostów w momencie weryfikacji, ale ponownie je rozwiązuje przy nawiązywaniu połączenia, bez blokowania adresu IP. Atakujący mogą wykorzystać ponowne wiązanie DNS, aby ominąć ochronę SSRF i uzyskać dostęp do odpowiedzi z wewnętrznych usług HTTP, w tym z interfejsów pętli zwrotnej.

PraisonAI przed wersją 4.6.78 domyślnie udostępnia transport MCP HTTP-stream bez uwierzytelniania. Gdy operator uruchomi serwer bez klucza API, nieuwierzytelniony klient może zainicjować sesję, wyświetlić dostępne narzędzia i je wywołać. Dodatkowo serwer nie waliduje argumentów wywołań narzędzi względem zadeklarowanego schematu wejściowego.

Podatność w PraisonAI przed wersją 1.6.78 polega na buforowaniu decyzji o zatwierdzeniu narzędzia wyłącznie na podstawie jego nazwy. Umożliwia to atakującemu ponowne wykorzystanie wcześniejszego zatwierdzenia dla kolejnych wywołań z dowolnymi argumentami.

PraisonAI przed wersją 4.6.78 zawiera podatność polegającą na ignorowaniu zdefiniowanych zasad bezpieczeństwa w domyślnym backendzie Subprocess Sandbox. Blokady komend, ścieżek, importów oraz ograniczenia dotyczące uruchamiania podprocesów i zapisu plików są całkowicie pomijane.

Podatność w PraisonAI przed wersją 4.6.78 wynika z błędnej konfiguracji obrony przed wstrzykiwaniem promptów, gdzie domyślny próg blokowania ustawiony jest na poziom CRITICAL. Pozwala to na przejście ataków o wysokiej dotkliwości (HIGH) bez blokowania, co umożliwia wyodrębnienie promptów systemowych i nieautoryzowane wywołania narzędzi.

Podatność SSRF w backendzie Crawl4AI/Chromium w PraisonAI przed wersją 1.6.78 umożliwia atakującym ominięcie walidacji poprzez DNS rebinding i przekierowania HTTP. Atakujący może skonstruować adres URL, który po wstępnej walidacji rozwiązuje się do wewnętrznych usług, pozwalając przeglądarce headless na odczyt wrażliwych danych.

PraisonAI przed wersją 1.7.3 zawiera niebezpieczną domyślną konfigurację, która wiąże się ze wszystkimi interfejsami sieciowymi, nie wymaga klucza API i zezwala na dowolne źródła CORS. Nieuwierzytelnieni atakujący mogą odczytać instrukcje agentów i podpowiedzi systemowe za pomocą żądania GET /api/agents lub wywołać agentów bez uwierzytelnienia przez POST /api/chat.