Podatności PraisonAI

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.

Podatność w PraisonAI przed wersją 4.6.78 pozwala na odczyt plików poza obszarem roboczym poprzez nieprawidłową walidację ścieżek w szablonach poleceń. Atakujący mogą użyć sekwencji typu @../outside_secret.txt lub ścieżek bezwzględnych, aby wstrzyknąć zawartość plików do promptów modelu.

W pakiecie PraisonAI (pip praisonaiagents) przed wersją 1.6.78 wykryto niebezpieczne dynamiczne ładowanie modułów w funkcji AgentFlow._resolve_pydantic_class. Gdy krok przepływu pracy używa referencji output_pydantic, framework importuje plik tools.py z katalogu pliku przepływu bez piaskownicy, ignorując zmienne środowiskowe PRAISONAI_ALLOW_*_TOOLS. Atakujący kontrolujący plik przepływu i towarzyszący mu tools.py może wykonać dowolny kod Python z uprawnieniami uruchamiającego przepływ.

Podatność w PraisonAI przed wersją 4.6.78 pozwala na ominięcie mechanizmu obrony przed wstrzykiwaniem promptów. Obrona blokuje tylko zagrożenia sklasyfikowane jako KRYTYCZNE, wymagając jednoczesnego dopasowania trzech lub więcej rodzin detektorów. Atakujący mogą tworzyć jedno- lub dwuwektorowe wstrzyknięcia promptów o poziomie zagrożenia WYSOKI, które przechodzą niezablokowane do modelu.

PraisonAI przed wersją 0.1.7 nie weryfikuje, czy identyfikator projektu (project_id) w żądaniach tworzenia i aktualizacji zgłoszeń należy do obszaru roboczego (workspace) wskazanego w URL. Atakujący może tworzyć zgłoszenia odnoszące się do projektów z innych obszarów roboczych, powodując zanieczyszczenie danych między dzierżawcami w agregacji statystyk projektów bez ograniczeń obszaru roboczego.

PraisonAI w wersjach przed 1.5.128 zawiera podatność na wykonanie agenta z innego źródła w punkcie końcowym AGUI, co pozwala zdalnym atakującym na wywołanie dowolnego wykonania agenta. Brak uwierzytelnienia w punkcie końcowym POST /agui oraz hardkodowane nagłówki Access-Control-Allow-Origin: * umożliwiają obejście kontroli CORS.

PraisonAI w wersjach przed 4.5.128 zawiera podatność na wykonanie dowolnych poleceń powłoki, ponieważ moduły interfejsu użytkownika mają na stałe ustawiony tryb zatwierdzania na auto, co pomija konfigurację administratora z zmiennej środowiskowej PRAISON_APPROVAL_MODE. Uwierzytelnieni atakujący mogą zlecać agentowi LLM wykonywanie dowolnych poleceń powłoki.

PraisonAI w wersjach przed 1.5.128 przechowuje decyzje o zatwierdzeniu narzędzi tylko na podstawie nazwy narzędzia, a nie argumentów wywołania, co pozwala na ominięcie komunikatów zatwierdzających przy kolejnych wywołaniach execute_command.

PraisonAI przed wersją 4.5.115 zawiera podatność na wstrzykiwanie szablonów w funkcji create_agent_centric_tools(). Dane wejściowe użytkownika przekazywane do agent.start() są przetwarzane bez odpowiedniego escapingu, co pozwala na wykonanie wyrażeń szablonów zamiast traktowania ich jako tekstu.

PraisonAI przed wersją 4.5.115 udostępnia serwer zdarzeń A2U (Agent-to-User) bez uwierzytelniania. Funkcja create_a2u_routes() rejestruje punkty końcowe /a2u/info, /a2u/subscribe, /a2u/events/{stream_name}, /a2u/events/sub/{id} i /a2u/health bez żadnych kontroli dostępu.

PraisonAI przed wersją 4.5.97 zawiera podatność w SubprocessSandbox we wszystkich trybach (BASIC, STRICT, NETWORK_ISOLATED). Funkcja subprocess.run() jest wywoływana z shell=True i polega wyłącznie na dopasowywaniu wzorców stringów do blokowania niebezpiecznych komend. Lista blokowanych nie zawiera sh ani bash jako samodzielnych plików wykonywalnych, co pozwala na łatwą ucieczkę z sandboksa w trybie STRICT poprzez sh -c '<polecenie>'.

W PraisonAI przed wersją 1.5.95 funkcja FileTools.download_file() nie waliduje parametru URL, przekazując go bezpośrednio do httpx.stream() z follow_redirects=True. Atakujący kontrolujący URL może uzyskać dostęp do dowolnego hosta dostępnego z serwera, w tym do metadanych chmury i usług wewnętrznych.

Podatność w PraisonAI przed wersją 4.5.90, gdzie funkcja MCPToolIndex.search_tools() kompiluje dostarczony przez użytkownika ciąg znaków bezpośrednio jako wyrażenie regularne Pythona bez walidacji, sanityzacji lub limitu czasu. Specjalnie spreparowane wyrażenie regularne powoduje katastrofalne cofanie się w silniku re, blokując wątek Pythona na setki sekund i powodując całkowitą przerwę w działaniu usługi.

PraisonAI przed wersją 1.5.90 zawiera podatność na wstrzykiwanie poleceń w funkcji run_python(). Funkcja konstruuje polecenie powłoki z danych wejściowych użytkownika bez odpowiedniego escapowania, co pozwala na wykonanie dowolnych poleceń OS przed uruchomieniem Pythona.

PraisonAI przed wersją 4.5.90 zawiera podatność w funkcjach passthrough() i apassthrough(), które akceptują kontrolowany przez atakującego parametr api_base. Parametr ten jest łączony z endpointem i przekazywany do httpx.Client.request() bez walidacji schematu URL, filtrowania prywatnych adresów IP ani listy dozwolonych domen, co pozwala na wysyłanie żądań do dowolnego hosta osiągalnego z serwera. Problem został naprawiony w wersji 4.5.90.