PT-2026-61759 · Pypi · Praisonai

CVE-2026-56834

·

Published

2026-06-18

·

Updated

2026-07-23

CVSS v3.1

7.5

High

VectorAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

PraisonAI dynamic-context artifact tools read arbitrary host files outside artifact storage

Summary

PraisonAI's Dynamic Context Discovery feature exposes artifact helper tools through ctx.get tools():
python
ctx = setup dynamic context()

agent = Agent(
  instructions="You are a data analyst.",
  tools=ctx.get tools(),
  hooks=[ctx.get middleware()],
)
The official documentation describes these helpers as a way for the agent to explore large tool-output artifacts that were queued by the middleware:
  • large tool outputs are saved as artifacts;
  • the agent receives compact artifact references; and
  • the agent uses artifact tail and artifact grep to explore that data.
The implemented artifact tools do not enforce that the supplied artifact path is an artifact created by the configured store or that it lives under the configured artifact base directory. Instead, artifact head, artifact tail, artifact grep, and artifact chunk wrap the caller-supplied path directly into an ArtifactRef and then read it from the host filesystem.
As a result, any prompt/user/tool-caller that can influence those tool arguments can read files readable by the PraisonAI process, such as project .env files, cloud credentials, SSH keys, source files, or other local data.

Affected Product

  • Repository: MervinPraison/PraisonAI
  • Ecosystem: pip
  • Package: praisonai
  • Component: Dynamic Context Discovery artifact tools
  • Current source path: src/praisonai/praisonai/context/queue.py
  • Artifact store path: src/praisonai/praisonai/context/artifact store.py
  • Latest PyPI version validated: 4.6.58
  • Current origin/main validated: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
  • Current origin/main tag validated: v4.6.58
Suggested affected range:
text
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

create artifact tools() creates an artifact store bound to base dir, but the read tools do not use base dir for containment.
For example, artifact head() accepts artifact path and immediately creates an ArtifactRef with that path:
python
def artifact head(artifact path: str, lines: int = 50) -> str:
  ref = ArtifactRef(path=artifact path, summary="", size bytes=0)
  try:
    return artifact store.head(ref, lines=lines)
  except FileNotFoundError:
    return f"Error: Artifact not found: {artifact path}"
artifact tail(), artifact grep(), and artifact chunk() have the same pattern. They trust the caller-supplied path rather than resolving it through an artifact identifier, store lookup, manifest, or base-directory containment check.
The store methods then read that path directly:
python
def head(self, ref: ArtifactRef, lines: int = 50) -> str:
  file path = Path(ref.path)
  if not file path.exists():
    raise FileNotFoundError(f"Artifact not found: {ref.path}")

  result lines = []
  with open(file path, "r", encoding="utf-8", errors="replace") as f:
    ...
There is no check equivalent to:
python
resolved = Path(ref.path).resolve()
base = self.base dir.resolve()
resolved.relative to(base)
There is also no check that the file has a valid .meta sidecar or appears in artifact list().

Local PoV

Run against the latest PyPI package:
bash
uv run --with 'praisonai==4.6.58' 
 python poc/pov prai cand 026 artifact tools arbitrary file read.py --json
The PoV:
  1. Creates a temporary artifact base directory.
  2. Creates a separate outside-secret.txt file outside that base directory.
  3. Stores one legitimate artifact through FileSystemArtifactStore.store().
  4. Calls artifact head() on the legitimate artifact as a positive control.
  5. Calls artifact head(), artifact grep(), and artifact chunk() on the outside file path.
  6. Confirms artifact list() does not list the outside file.
Observed output summary from evidence/pov-pypi-4.6.58.json:
json
{
 "package": "praisonai",
 "package version": "4.6.58",
 "controls": {
  "outside file not listed": true,
  "outside file outside base dir": true,
  "valid artifact read works": true
 },
 "outside head": "PRAI-CAND-026-OUTSIDE-ARTIFACT-SECRET",
 "outside grep": "Found 1 matches:

--- Line 1 ---
> PRAI-CAND-026-OUTSIDE-ARTIFACT-SECRET
 second line",
 "outside chunk": "PRAI-CAND-026-OUTSIDE-ARTIFACT-SECRET",
 "outside file listed by artifact list": false,
 "vulnerable": true
}
The PoV was rerun successfully after a fresh origin/main fetch; see evidence/pov-pypi-4.6.58-rerun.json.
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 every file-reading tool is automatically a vulnerability. The issue is narrower: tools documented and named as artifact helpers accept arbitrary host file paths.
The controls show the intended boundary:
  • a valid artifact stored under base dir is readable;
  • an outside file is not returned by artifact list();
  • the outside file is outside base dir; and
  • the read helpers still disclose the outside file when handed its absolute path.
PraisonAI's own context-security documentation recommends relative paths and reviewing ignore rules to avoid sensitive-file exposure. Those controls are bypassed when artifact tools can be pointed directly at any readable host path.

Impact

If a PraisonAI application exposes an agent with ctx.get tools() to untrusted or lower-trust prompts, the lower-trust caller can request artifact tools against arbitrary local paths. This can disclose sensitive host files readable by the PraisonAI process, including:
  • project .env files;
  • cloud or service credentials;
  • SSH keys;
  • local application configuration;
  • source files and private data; and
  • terminal/history artifacts from other runs if the path is known or guessed.
The impact is confidentiality-only in the tested surface. Integrity and availability are not claimed for this report.

Duplicate Posture

I checked visible PraisonAI advisories and local prior PraisonAI submissions. This is distinct from nearby file-read/file-write issues:
  • GHSA-9cr9-25q5-8prj / CVE-2026-47394 covers MCP CLI workflow.show, workflow.validate, and deploy.validate path handling. This report covers Dynamic Context Discovery artifact tools in context/queue.py.
  • GHSA-hvhp-v2gc-268q / CVE-2026-47397 covers write file arbitrary file write when workspace=None. This report is a read-only disclosure issue in artifact helper tools.
  • Public recipe registry path traversal advisories cover recipe publish/pull storage and extraction. This report does not involve the recipe registry.
  • Local prior submissions in this harness do not cover artifact head, artifact tail, artifact grep, artifact chunk, or FileSystemArtifactStore path containment.

Severity

Suggested severity: High.
Suggested CVSS v3.1:
Rationale:
  • AV: applies when an application exposes a PraisonAI agent over a network chat/API surface, which is a documented PraisonAI deployment pattern.
  • AC: no race, special environment, or complex path manipulation is required; an absolute readable path is sufficient.
  • 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: arbitrary readable host files can contain secrets or private data.
  • I/A: this report demonstrates read-only disclosure.

Remediation

Do not let artifact tools open arbitrary paths. Prefer stable artifact IDs over raw filesystem paths in tool arguments.
Recommended fixes:
  1. Change tool schemas to accept artifact id plus optional run id and agent id, then resolve those through the artifact store's metadata/index.
  2. If path arguments must remain for compatibility, resolve the path with Path(path).resolve() and reject it unless it is under artifact store.base dir.resolve().
  3. Require a valid artifact metadata sidecar for read helpers. Files not created by FileSystemArtifactStore.store() should not be readable through artifact tools.
  4. Apply the same containment check to load(), head(), tail(), grep(), chunk(), and delete().
  5. Avoid returning absolute host paths in prompt-visible artifact references when an opaque artifact ID would suffice.
Minimal containment helper:
python
def resolve artifact path(self, path: str) -> Path:
  resolved = Path(path).expanduser().resolve()
  base = self.base dir.resolve()
  try:
    resolved.relative to(base)
  except ValueError as exc:
    raise PermissionError("Artifact path is outside artifact storage") from exc
  return resolved
This helper should be paired with metadata-sidecar validation so arbitrary non-artifact files placed under the base directory are not automatically treated as valid artifacts.

Fix

Path traversal

Information Disclosure

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-22CWE-200

Related Identifiers

CVE-2026-56834
GHSA-J7QX-P75M-WP7G
PYSEC-2026-3514

Affected Products

Praisonai