---
id: CVE-2026-56834
aliases:
  - GHSA-j7qx-p75m-wp7g
title: >-
  PraisonAI dynamic-context artifact tools read arbitrary host files outside
  artifact storage
summary: >-
  PraisonAI dynamic-context artifact tools read arbitrary host files outside
  artifact storage
severity: high
cvss: 7.5
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'
vendor: praisonai
product: praisonai
ecosystem: pip
affected:
  - 'praisonai >= 3.8.1, < 4.6.59'
patched:
  - praisonai 4.6.59
published: '2026-06-18'
updated: '2026-07-20'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/GHSA-j7qx-p75m-wp7g'
references:
  - url: >-
      https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-j7qx-p75m-wp7g
  - url: 'https://github.com/MervinPraison/PraisonAI'
tags:
  - osv
  - pip
ingestedAt: '2026-07-21T19:04:57.253Z'
---

## Overview

# 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:\\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.

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

## Affected packages

- `praisonai >= 3.8.1, < 4.6.59`

## Remediation

Upgrade to a patched release:

- `praisonai 4.6.59`