PraisonAI is a multi-agent teams system. Prior to 1.5.113, the Action Orchestrator feature contains a Path Traversal vulnerability that allows an attacker (or compromised agent) to write to arbitrary files outside of the configured workspace directory. By supplying relative path segments (../) in the target path, malicious actions can overwrite sensitive system files or drop executable payloads on the host. This vulnerability is fixed in 1.5.113.

PraisonAI is a multi-agent teams system. Prior to 1.5.113, The PraisonAI templates installation feature is vulnerable to a "Zip Slip" Arbitrary File Write attack. When downloading and extracting template archives from external sources (e.g., GitHub), the application uses Python's zipfile.extractall() without verifying if the files within the archive resolve outside of the intended extraction directory. This vulnerability is fixed in 1.5.113.

Summary

PraisonAI's recipe registry pull flow extracts attacker-controlled .praison tar archives with tar.extractall() and does not validate archive member paths before extraction. A malicious publisher can upload a recipe bundle that contains ../ traversal entries and any user who later pulls that recipe will write files outside the output directory they selected.

This is a path traversal / arbitrary file write vulnerability on the client side of the recipe registry workflow. It affects both the local registry pull path and the HTTP registry pull path. The checksum verification does not prevent exploitation because the malicious traversal payload is part of the signed bundle itself.

Details

The issue is caused by unsafe extraction of tar archive contents during recipe pull.

1. A malicious publisher creates a valid .praison bundle whose manifest.json is benign enough to pass publish, but whose tar members include traversal entries such as:

text ../../escape-http.txt

2. LocalRegistry.publish() in src/praisonai/praisonai/recipe/registry.py:214-287 only reads manifest.json, calculates a checksum, and stores the uploaded bundle. It does not inspect or sanitize the rest of the tar members before saving the archive.

3. When a victim later pulls the recipe from a local registry, LocalRegistry.pull() in src/praisonai/praisonai/recipe/registry.py:289-345 extracts the tarball directly:

python recipedir = outputdir / name recipedir.mkdir(parents=True, existok=True)

with tarfile.open(bundlepath, "r:gz") as tar: tar.extractall(recipedir)

4. The HTTP client path is also vulnerable. HttpRegistry.pull() in src/praisonai/praisonai/recipe/registry.py:691-739 downloads the bundle and then performs the same unsafe extraction:

python recipedir = outputdir / name recipedir.mkdir(parents=True, existok=True)

with tarfile.open(bundlepath, "r:gz") as tar: tar.extractall(recipedir)

5. Because no archive member validation is performed, traversal entries escape recipedir and create files elsewhere on disk.

Verified vulnerable behavior:

- Published recipe name: evil-http - Victim-selected output directory: /tmp/praisonai-pull-traversal-poc/victim-output - Artifact created outside that directory: /tmp/praisonai-pull-traversal-poc/escape-http.txt - Artifact contents: owned over http

This demonstrates that a remote publisher can cause filesystem writes outside the pull destination chosen by another user.

PoC

Run the single verification script from the checked-out repository:

bash cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI" python3 tmp/pocs/poc2.py

Expected vulnerable output:

text [+] Publish result: {'ok': True, 'name': 'evil-http', 'version': '1.0.0', ...} [+] Pull result: {'name': 'evil-http', 'version': '1.0.0', ...} [+] Outside artifact exists: True [+] Artifact also inside output dir: False [+] Outside artifact content: 'owned over http\n' [+] RESULT: VULNERABLE - pulling the recipe created a file outside the chosen output directory.

Then verify the created file manually:

bash ls -l /tmp/praisonai-pull-traversal-poc/escape-http.txt cat /tmp/praisonai-pull-traversal-poc/escape-http.txt find /tmp/praisonai-pull-traversal-poc -maxdepth 3 | sort

What the script does internally:

1. Starts a local PraisonAI recipe registry server. 2. Builds a malicious .praison bundle containing the tar entry ../../escape-http.txt. 3. Publishes the malicious bundle to the local HTTP registry. 4. Simulates a victim pulling that recipe into /tmp/praisonai-pull-traversal-poc/victim-output. 5. Confirms that the file is created outside the chosen output directory.

Impact

This is a path traversal / arbitrary file write vulnerability in the recipe pull workflow.

Impacted parties:

- Users who pull recipes from an untrusted or shared PraisonAI registry. - Teams running internal registries where one publisher can influence what other users pull. - Automated systems or CI jobs that fetch recipes into working directories near sensitive project files.

Security impact:

- Integrity impact is high because an attacker can create or overwrite files outside the expected extraction directory. - Availability impact is significant if the overwritten target is a config file, project file, startup script, or another operational artifact. - The issue crosses a real security boundary because the attacker only needs to publish a malicious recipe, while the victim triggers the write by pulling it.

Remediation

1. Replace raw tar.extractall() with a safe extraction routine that validates every TarInfo member before extraction. Reject absolute paths, .. segments, and any resolved path that escapes the intended extraction directory.

2. Apply the same archive member validation in both LocalRegistry.pull() and HttpRegistry.pull() so that local and remote registry clients share the same safety guarantees.

3. Consider validating tar contents during publish as well, so malicious bundles are rejected before they ever enter the registry and cannot be served to downstream users.

Summary

PraisonAI's recipe registry publish endpoint writes uploaded recipe bundles to a filesystem path derived from the bundle's internal manifest.json before it verifies that the manifest name and version match the HTTP route. A malicious publisher can place ../ traversal sequences in the bundle manifest and cause the registry server to create files outside the configured registry root even though the request is ultimately rejected with HTTP 400.

This is an arbitrary file write / path traversal issue on the registry host. It affects deployments that expose the recipe registry publish flow. If the registry is intentionally run without a token, any network client that can reach the service can trigger it. If a token is configured, any user with publish access can still exploit it.

Details

The bug is caused by the order of operations between the HTTP handler and the registry storage layer.

1. RegistryServer.handlepublish() in src/praisonai/praisonai/recipe/server.py:370-426 parses POST /v1/recipes/{name}/{version}, writes the uploaded .praison file to a temporary path, and immediately calls:

python result = self.registry.publish(tmppath, force=force)

2. LocalRegistry.publish() in src/praisonai/praisonai/recipe/registry.py:214-287 opens the uploaded tarball, reads manifest.json, and trusts the attacker-controlled name and version fields:

python name = manifest.get("name") version = manifest.get("version") recipedir = self.recipespath / name / version recipedir.mkdir(parents=True, existok=True) bundlename = f"{name}-{version}.praison" destpath = recipedir / bundlename shutil.copy2(bundlepath, destpath)

3. Validation helpers already exist in the same file:

python def validatename(name: str) -> bool: def validateversion(version: str) -> bool:

but they are not called before the filesystem write.

4. Only after publish() returns does the route compare the manifest values with the URL values:

python if result["name"] != name or result["version"] != version: self.registry.delete(result["name"], result["version"]) return self.errorresponse(...)

At that point the out-of-root artifact has already been created. The request returns an error, but the write outside the registry root remains on disk.

Verified vulnerable behavior:

- Request path: /v1/recipes/safe/1.0.0 - Internal manifest name: ../../outside-dir - Server response: HTTP 400 - Leftover artifact: /tmp/praisonai-publish-traversal-poc/outside-dir-1.0.0.praison

This demonstrates that the write occurs before the consistency check and rollback.

PoC

Run the single verification script from the checked-out repository:

bash cd "/Users/r1zzg0d/Documents/CVE hunting/targets/PraisonAI" python3 tmp/pocs/poc.py

Expected vulnerable output:

text [+] Publish response status: 400 { "ok": false, "error": "Bundle name/version (../../outside-dir@1.0.0) doesn't match URL (safe@1.0.0)", "code": "error" } [+] Leftover artifact exists: True [+] Artifact under registry root: False [+] RESULT: VULNERABLE - upload was rejected, but an out-of-root artifact was still created.

Then verify the artifact manually:

bash ls -l /tmp/praisonai-publish-traversal-poc/outside-dir-1.0.0.praison find /tmp/praisonai-publish-traversal-poc -maxdepth 2 | sort

What the script does internally:

1. Starts a local PraisonAI recipe registry server. 2. Builds a malicious .praison bundle whose internal manifest.json contains name = ../../outside-dir. 3. Uploads that bundle to the apparently safe route /v1/recipes/safe/1.0.0. 4. Receives the expected 400 mismatch error. 5. Confirms that outside-dir-1.0.0.praison was still written outside the configured registry directory.

Impact

This is a path traversal / arbitrary file write vulnerability in the recipe registry publish flow.

Impacted parties:

- Registry operators running the PraisonAI recipe registry service. - Any deployment that allows remote recipe publication. - Any environment where adjacent writable filesystem locations contain sensitive application data, service files, or staged content that could be overwritten or planted.

Security impact:

- Integrity impact is high because an attacker can create or overwrite files outside the registry root. - Availability impact is possible if the attacker targets adjacent runtime or application files. - The issue can be chained with other local loading or deployment behaviors if nearby files are later consumed by another component.

Remediation

1. Validate manifest.json name and version before any path join or filesystem write. Reject path separators, .., absolute paths, and any value that fails the existing validatename() / validateversion() checks.

2. Resolve the final destination path and enforce that it remains under the configured registry root before calling mkdir() or copy2(). For example, compare the resolved destination against self.recipespath.resolve().

3. Move the URL-to-manifest consistency check ahead of self.registry.publish(...), or refactor publish() so it receives already-validated route parameters instead of trusting attacker-controlled manifest values for storage paths.