GHSA-J7QX-P75M-WP7G

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

PraisonAI's Dynamic Context Discovery feature exposes artifact helper tools
through ctx.get_tools():

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:

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:

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:

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:

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:

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:

{
  "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:\\n\\n--- Line 1 ---\\n> PRAI-CAND-026-OUTSIDE-ARTIFACT-SECRET\\n  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.

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.

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.

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

GHSA-J7QX-P75M-WP7G has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.6.59); upgrading removes the vulnerable code path.

Kodem intelligence

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:

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.

1. What is GHSA-J7QX-P75M-WP7G? GHSA-J7QX-P75M-WP7G is a high-severity path traversal vulnerability in praisonai (pip), affecting versions >= 3.8.1, <= 4.6.58. It is fixed in 4.6.59. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
2. How severe is GHSA-J7QX-P75M-WP7G? GHSA-J7QX-P75M-WP7G has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of praisonai are affected by GHSA-J7QX-P75M-WP7G? praisonai (pip) versions >= 3.8.1, <= 4.6.58 is affected.
4. Is there a fix for GHSA-J7QX-P75M-WP7G? Yes. GHSA-J7QX-P75M-WP7G is fixed in 4.6.59. Upgrade to this version or later.
5. Is GHSA-J7QX-P75M-WP7G exploitable, and should I be worried? Whether GHSA-J7QX-P75M-WP7G is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-J7QX-P75M-WP7G is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-J7QX-P75M-WP7G? Upgrade praisonai to 4.6.59 or later.