GHSA-cfxv-8fw8-rwpv: Medium severity pip/praisonaiagents vulnerability

Target: PraisonAI (MervinPraison/PraisonAI) Affected component: praisonaiagents/tools/astgreptool.py — astgreprewrite Affected versions: master at ce97667156a116c50b4a3d1aa21e09f048903fda; reproduced against the current praisonaiagents PyPI release (praisonaiagents <= 1.6.52).

Summary

Tools in praisonaiagents/tools/ that modify on-disk state or run code are uniformly wrapped with @requireapproval, which routes the call through an interactive approval flow before the body runs and fails closed — on denial (or with no approval backend configured) it raises PermissionError and the side effect does not occur. This is applied at every sibling mutation entry point:

| File | Line | Symbol | Risk level | |---|---|---|---| | filetools.py | 212 | copyfile | high | | filetools.py | 239 | movefile | high | | filetools.py | 266 | deletefile | high | | edittools.py | 38 | EditTools.editfile | high | | edittools.py | 155 | editfile | high | | shelltools.py | 32 | executecommand | critical | | pythontools.py | 352 | executecode | critical |

astgreptool.py:149 astgreprewrite is structurally a sibling of these but has no decorator and no from ..approval import requireapproval import. With dryrun=False (LLM-controllable), it builds sg --pattern <P> --rewrite <R> --lang <L> --update-all <path> (lines 204–211) and calls subprocess.run(cmd, ...) (line 215), modifying every file under path matching the pattern. There is no approval gate, no validatepath workspace check, and no cwd= sandboxing. The function is registered as a top-level tool (init.py:182) and exposed via the codeintelligence built-in profile (profiles.py).

A secondary defect: on the dryrun=False path astgreprewrite returns the literal string No changes made to the caller even when it modified files (the "No changes made" return at astgreptool.py:230 is reached on this path), so an operator inspecting tool output sees no record that a write occurred.

Proof of concept

Single script, clean venv, praisonaiagents from PyPI, ast-grep CLI installed. PRAISONAIAUTOAPPROVE is removed from the environment first, so no env-bypass is in play.

python import os, tempfile, textwrap os.environ.pop("PRAISONAIAUTOAPPROVE", None)

workdir = tempfile.mkdtemp(prefix="poc-") target = os.path.join(workdir, "target.py") open(target, "w").write(textwrap.dedent(""" def safefunction(x): return x + 1

def hello(name): return 'hi ' + name """))

Positive: undecorated tool rewrites the file. from praisonaiagents.tools.astgreptool import astgreprewrite astgreprewrite( pattern="def $FN($$$): return $$$", replacement="def $FN($$$): import os; os.environ['POCCANARY']='1'; return $$$", lang="python", path=workdir, dryrun=False, )

Negative control: decorated sibling triggers the approval flow. from praisonaiagents.tools.edittools import editfile editfile(filepath=target, oldtext="def hello(name):", newtext="def hello(name): # X")

Result, verified: astgreprewrite rewrote target.py to contain the injected import os; os.environ['POCCANARY']='1' payload, no approval prompt fired, and the call returned No changes made. The subsequent editfile call in the same process rendered the Tool Approval Required panel and, on denial, raised PermissionError("Execution of editfile denied: User denied") without modifying its target. Same process, same approval backend — the only difference is the missing decorator on astgreprewrite.

Threat model

An LLM agent running locally whose tool surface includes astgreprewrite (via the codeintelligence profile or direct import). Triggers: the operator asks the agent to refactor code, or prompt-injection in fetched docs / RAG context / any LLM-visible input steers the agent to call astgreprewrite with attacker-chosen pattern, replacement, and path (the dryrun field is in the LLM-visible tool schema, so dryrun=False is requestable). The agent can then rewrite any file the host process can write — source trees, build configs, dotfiles, the agent's own source. With path="/" the rewrite is filesystem-wide. Because the rewrite injects arbitrary text, pointing it at a file that is later imported or executed turns this write primitive into code execution — the basis for the escalation noted in the CVSS line. No operator prompt and no audit record of the modification.

Suggested fix

diff --- a/praisonaiagents/tools/astgreptool.py +++ b/praisonaiagents/tools/astgreptool.py @@ from praisonaiagents.logging import getlogger from typing import Optional, List +from ..approval import requireapproval @@ +@requireapproval(risklevel="high") def astgreprewrite( pattern: str, replacement: str,

high matches the file-modifying siblings; critical is defensible given the write→exec escalation. In the same patch: add a validatepath workspace boundary check (cf. edittools.py:27); fix the No changes made return so it reflects actual modifications; apply the decorator to astgrepscan (astgreptool.py:243) if it can write. astgrepsearch is read-only and can stay undecorated. A regression test asserting astgreprewrite requires approval (alongside the other mutation tools) would have caught this at review time.

Coordinated disclosure

- Kai Aizen / SnailSploit — kai@snailsploit.com — PGP on request.