Vulnerability Database

375,699

Total vulnerabilities in the database

CVE-2026-56833 — praisonai

Exposure of Sensitive Information to an Unauthorized Actor

PraisonAI Dynamic Context history and terminal tools read files outside configured storage via path traversal

Summary

PraisonAI's Dynamic Context module provides filesystem-backed history and terminal-log storage. The SDK reference describes the module as providing:

  • artifact storage for tool outputs, history, and terminal logs;
  • history persistence with search; and
  • terminal session logging.

The module also exports agent-callable tool factories:

  • create_history_tools() returns history_search, history_tail, and history_get.
  • create_terminal_tools() returns terminal_tail, terminal_grep, and terminal_commands.

Those tools accept run_id and agent_id arguments from the tool caller. The underlying stores join those values into filesystem paths without rejecting absolute paths or .. traversal:

history_dir = self.base_dir / run_id / "history" return history_dir / f"{agent_id}.jsonl" terminal_dir = self.base_dir / run_id / "terminal" return terminal_dir / f"{agent_id}.log"

Because run_id can be an absolute path and agent_id can contain traversal, a lower-trust prompt/user that can call these tools can read .jsonl and .log files outside the configured Dynamic Context base directory.

Affected Product

  • Repository: MervinPraison/PraisonAI
  • Ecosystem: pip
  • Package: praisonai
  • Component: Dynamic Context history and terminal tools
  • Current source paths:
    • src/praisonai/praisonai/context/history_store.py
    • src/praisonai/praisonai/context/terminal_logger.py
  • Latest PyPI version validated: 4.6.58
  • Current origin/main validated: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
  • Current origin/main tag validated: v4.6.58

Suggested affected range:

pip:praisonai >= 3.8.1, <= 4.6.58

Representative local sweep:

  • 3.8.1: vulnerable
  • 4.0.0: vulnerable
  • 4.5.113: vulnerable
  • 4.6.33: vulnerable
  • 4.6.34: vulnerable
  • 4.6.40: vulnerable
  • 4.6.50: vulnerable
  • 4.6.58: vulnerable

Root Cause

HistoryStore._get_history_path() and TerminalLogger._get_log_path() treat logical identifiers as path segments, but never validate that the resolved path stays under base_dir.

History path construction:

def _get_history_path(self, run_id: str, agent_id: str) -> Path: history_dir = self.base_dir / run_id / "history" history_dir.mkdir(parents=True, exist_ok=True) return history_dir / f"{agent_id}.jsonl"

Terminal path construction:

def _get_log_path(self, run_id: str, agent_id: str) -> Path: terminal_dir = self.base_dir / run_id / "terminal" terminal_dir.mkdir(parents=True, exist_ok=True) return terminal_dir / f"{agent_id}.log"

The agent tools pass caller-controlled run_id and agent_id directly into these helpers:

def history_tail(agent_id: str = "default", run_id: str = "default", count: int = 10) -> str: messages = history_store.get_last_messages(agent_id=agent_id, run_id=run_id, count=count) def terminal_tail(agent_id: str = "default", run_id: str = "default", lines: int = 50) -> str: return term_logger.tail_session(agent_id=agent_id, run_id=run_id, lines=lines)

There is no check equivalent to:

resolved = candidate.resolve() base = self.base_dir.resolve() resolved.relative_to(base)

There is also no identifier allowlist preventing /, \, or .. in run_id or agent_id.

Local PoV

Run against the latest PyPI package:

uv run --with 'praisonai==4.6.58' \ python poc/pov_prai_cand_027_history_terminal_tools_path_traversal.py --json

The PoV:

  1. Creates a temporary Dynamic Context base directory.
  2. Creates a separate outside directory containing secret.jsonl and secret.log.
  3. Creates legitimate in-base history and terminal log controls.
  4. Calls history_tail() and history_get() with run_id=<outside-dir> and agent_id=../secret.
  5. Calls terminal_tail() and terminal_grep() with the same traversal.
  6. Confirms the traversal paths resolve to files outside the configured base.

Observed output summary from evidence/pov-pypi-4.6.58.json:

{ "package": "praisonai", "package_version": "4.6.58", "controls": { "valid_history_read_works": true, "valid_terminal_read_works": true, "outside_history_file_outside_base_dir": true, "outside_terminal_file_outside_base_dir": true, "traversal_history_path_resolves_to_outside_file": true, "traversal_terminal_path_resolves_to_outside_file": true }, "outside_history_tail": "Last 1 messages:\\n\\n[system]: PRAI-CAND-027-HISTORY-SECRET", "outside_terminal_tail": "PRAI-CAND-027-TERMINAL-SECRET\\nsecond line\\n", "outside_terminal_grep": "Found 1 matches:\\n\\n--- Line 1 ---\\n> PRAI-CAND-027-TERMINAL-SECRET\\n second line", "vulnerable": true }

The PoV is local-only. It does not start a server, contact a third-party target, or use real credentials.

Why This Is Not Intended Behavior

This report does not claim that history and terminal helpers should be unable to read legitimate history or terminal logs. The issue is narrower: logical run_id and agent_id values can escape the configured Dynamic Context base directory.

The controls show the intended boundary:

  • legitimate in-base history remains readable;
  • legitimate in-base terminal logs remain readable;
  • the outside .jsonl and .log files are not under the configured base_dir; and
  • the tools still disclose those outside files through traversal identifiers.

The official context reference describes history persistence and terminal logging as filesystem-backed Dynamic Context features. The context security documentation also treats absolute paths, path traversal, and sensitive files as privacy/security risks. Reading files outside the configured context store conflicts with that documented boundary.

Impact

If a PraisonAI application exposes these Dynamic Context tools to untrusted or lower-trust prompts, the lower-trust caller can read files outside the configured context storage when the target file can be reached with the tool-imposed suffix:

  • history_* tools can disclose reachable .jsonl files;
  • terminal_* tools can disclose reachable .log files; and
  • cross-run or cross-agent context/history/logs can be disclosed if their path is known or guessable.

This can expose conversation history, prompts, terminal output, command logs, tokens, API keys, cloud credentials, operational data, or other secrets stored in JSONL/log files readable by the PraisonAI process.

The impact is confidentiality-only in the tested surface. Integrity and availability are not claimed for this report.

Severity

Suggested severity: High.

Rationale:

  • AV: applies when an application exposes an agent with these tools over a network chat/API surface.
  • AC: the traversal needs only chosen run_id and agent_id values.
  • PR: an unauthenticated or public-facing agent endpoint can be exploited without an account. Deployments that require authenticated chat/API access may score this as PR:L.
  • UI: the attacker directly supplies the prompt/tool argument to the exposed agent surface.
  • C: conversation history and terminal logs can contain secrets and private operational data.
  • I:N/A: this report demonstrates read-only disclosure.

Remediation

Treat run_id and agent_id as logical identifiers, not path components.

Recommended fixes:

  1. Reject absolute paths, path separators, and traversal components in run_id and agent_id.
  2. Build candidate paths, call .resolve(), and reject any path that is not under self.base_dir.resolve().
  3. Apply the same containment helper to history append/read/search/clear/export and terminal log/read/search/clear/export paths.
  4. Prefer opaque server-generated run and agent IDs in tool schemas.
  5. Add regression tests for absolute run_id, ../ in run_id, and ../ in agent_id for history and terminal tool factories.

Minimal containment shape:

def _safe_child(self, *parts: str) -> Path: candidate = self.base_dir.joinpath(*parts).resolve() base = self.base_dir.resolve() try: candidate.relative_to(base) except ValueError as exc: raise PermissionError("Context path is outside configured base_dir") from exc return candidate

Pair this with an identifier allowlist, because run_id and agent_id should not need filesystem syntax.

CVSS v3:

  • Severity: High
  • Score: 7.5
  • AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CWEs:

OWASP TOP 10:

Software From Fixed in
Python icon praisonai 3.8.1 4.6.59

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.