CVE-2026-48168: PraisonAI GitHub Actions Command Injection
TL;DR - Critical command injection in PraisonAI’s bundled Claude GitHub Actions workflow. - Affects versions before 4.6.40; upgrade immediately and review workflow exposure to forked PRs. - No confirmed in-the-wild exploitation from available sources, but impact is severe and exploitation conditions are practical.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-48168 |
| CVSS score | 10.0 |
| Attack vector | GitHub Actions workflow abuse via attacker-controlled PR branch name and @claude comment trigger |
| Privileges required | Not fully confirmed in published vector; practical requirement is ability to open a PR from a fork and comment to trigger the workflow as described by NVD |
| Patch available | Yes, fixed in 4.6.40 |
This is a supply-chain and CI/CD risk more than a traditional application bug. The vulnerability is in PraisonAI’s bundled Claude GitHub Actions workflow, not in a network-facing daemon or API endpoint. That distinction matters for defenders: exposure depends on whether your repository uses the affected workflow and whether untrusted contributors can reach the vulnerable job path.
The severity is driven by post-exploitation privileges inside the runner. According to the NVD description, successful command injection can execute in a job that has a GitHub App token with write permissions, OIDC access, and gh/git access. In practice, that means an attacker may be able to turn a branch-name injection into repository changes, workflow tampering, PR or issue manipulation, and possible abuse of downstream identity or cloud trust paths.
What Is This Vulnerability?
CVE-2026-48168 is a command injection flaw caused by unsafe handling of untrusted data in a shell context. Specifically, the vulnerable Claude workflow in PraisonAI uses an attacker-controlled pull request branch name inside a Bash run: block without proper quoting or validation. If that branch name contains shell metacharacters, Bash can interpret them as commands rather than inert text.
The issue becomes materially exploitable because the workflow trigger is also too permissive. Per the NVD record, any @claude comment can trigger the workflow regardless of whether the commenter is a trusted collaborator. That means an outside contributor can create a fork, open a pull request with a crafted branch name, add the trigger comment, and reach the vulnerable execution path.
This combination of flaws is what makes the bug critical. Unsafe interpolation alone is dangerous, but the trigger logic removes a key trust boundary. In secure GitHub Actions design, metadata originating from forked PRs, comments, branch names, titles, or commit messages should be treated as hostile input. Here, that input flows into a shell and can then influence later privileged steps, including through $GITHUB_PATH, according to the NVD description.
From a defender’s perspective, this is a textbook workflow-trust failure: untrusted contributor input, shell execution, and elevated job permissions all meet in the same path. Even if your use case for Claude automation seems low risk, the privilege level attached to the workflow makes this a repository security issue, not just a build hygiene issue.
Technical Notes
A simplified unsafe pattern in GitHub Actions often looks like this:
- name: Use PR branch name
run: |
echo Processing branch ${{ github.head_ref }}
./some-script ${{ github.head_ref }}
If untrusted branch names are interpolated into a shell context without strict quoting or validation, characters such as ;, &&, $(), or backticks may alter execution flow. Safer handling typically means avoiding shell interpolation entirely or validating against a strict allowlist.
Who Is Affected?
The affected product is PraisonAI. Based on the source material provided, vulnerable versions are explicitly described as versions prior to 4.6.40, and the issue is fixed in 4.6.40. Put plainly: if you are running or distributing PraisonAI components that include the bundled Claude GitHub Actions workflow from any version < 4.6.40, you should treat that workflow as vulnerable.
The practical exposure set is narrower than “everyone running PraisonAI.” Organizations are affected if they have adopted the bundled workflow in GitHub repositories where untrusted external users can open pull requests or otherwise reach the workflow’s comment-triggered path. Repositories that do not use the bundled Claude workflow, or that have already replaced it with a hardened internal workflow, may not be exposed in the same way. However, if you are unsure whether your repository inherited or copied the workflow logic from a vulnerable version, assume exposure until you verify otherwise.
The fixed version number matters because this is the only source-backed remediation point in the available data. The research note explicitly states:
- Vulnerable:
PraisonAI < 4.6.40 - Fixed:
PraisonAI 4.6.40
If your software bill of materials, pinned dependency references, templates, or starter repos still point to an older release, your remediation work should include checking those artifacts too. CI/CD vulnerabilities often persist after package upgrades because workflow YAML files were copied into repositories and then drifted from upstream.
Technical Notes
To quickly locate likely affected workflow usage in a repository:
grep -RIn "@claude\|head_ref\|pull_request\|issue_comment" .github/workflows/
To identify a referenced PraisonAI version in manifests or lockfiles:
grep -RIn "praisonai\|PraisonAI" .
If you manage multiple repositories, inventory workflow reuse centrally and look for repos that allow forked PRs to run comment-triggered automation.
CVSS Score Breakdown
The NVD-sourced base score is 10.0, which places this issue at the top of the severity scale. However, the exact CVSS vector string was not present in the retrieved NVD tool output provided for this task. That means defenders should avoid claiming precise metric values beyond the base score unless they validate the vector independently from the source record.
Even without the vector string, the score is understandable from the described exploit chain and impact. Exploitation appears feasible for an outside contributor in repositories that accept forked pull requests and expose the vulnerable comment trigger. The vulnerable job then runs with significant permissions, including write-capable repository access and OIDC-related privileges. Those conditions strongly support high impact across integrity and potentially confidentiality within the repository and build environment.
What is less certain from the source data is the formal “Privileges Required” or “User Interaction” encoding in CVSS terms. The workflow requires a series of attacker actions, but the NVD snippet available here does not provide the exact vector. In the absence of that detail, security teams should assume a worst-case operational posture: if untrusted contributors can interact with the repository’s PR workflow, the exploit path is credible enough to justify immediate patching and workflow review.
For internal prioritization, this should be treated alongside other CI/CD trust-boundary bugs: compromise here may not just alter one build, but can give an attacker a path to persist in the repository, modify release automation, or laterally impact dependent workflows.
Exploitation Status
Based on the available source material, there is no authoritative confirmation of active exploitation in the wild at the time of writing. The research note states that CISA KEV does not list this CVE, and no retrieved source confirms real-world exploitation. That means defenders should not claim “exploited in the wild” unless they have independent evidence from telemetry or later authoritative reporting.
Likewise, the available material does not confirm a separate public proof-of-concept repository or exploit script beyond the vendor/advisory description of the attack path. That is an important nuance. “No confirmed public PoC” does not mean the bug is hard to exploit. In fact, the described chain is straightforward enough that an experienced attacker may not need a published PoC at all.
The right operational conclusion is: exploitation is plausible and potentially easy in exposed repositories, but confirmed active exploitation is not established from the sources provided. For incident response and prioritization, that still warrants urgent action because the privilege level of the impacted workflow sharply increases blast radius if exploited.
If your organization uses public GitHub repositories with contributor workflows, assume adversaries can understand and test this class of weakness quickly once advisories become visible. Even before broad scanning appears, targeted abuse by opportunistic contributors is realistic.
How to Detect It
Detection has two parts: identifying vulnerable workflow configuration and looking for signs that the vulnerable path was exercised. Start by reviewing .github/workflows/ for jobs tied to issue_comment, PR events, @claude comment parsing, or shell execution that references PR branch names such as github.head_ref. Any job that combines untrusted PR metadata with shell run: blocks deserves immediate review.
Next, examine GitHub Actions run history for unusual executions initiated by PR comments from external users. Focus on public repositories, forked PR contexts, and jobs where logs show shell errors, unexpected command output, path manipulation, or subsequent write actions. The NVD description specifically calls out chaining through $GITHUB_PATH, so any workflow run that appends attacker-controlled values to that file should be investigated.
You should also review repository audit logs and commit history for suspicious writes originating from GitHub Apps or workflow identities around the same time as externally triggered PR comments. Because the described impact includes repository writes, PR manipulation, and issue manipulation, the attacker’s footprint may extend beyond a single workflow run.
Technical Notes
Look for suspicious branch names in PR metadata, especially names containing shell metacharacters:
gh pr list --state all --json number,headRefName,author,createdAt,url | \
jq -r '.[] | [.number, .headRefName, .author.login, .createdAt, .url] | @tsv' | \
grep -E '[;&|`$()]'
Search workflow logs for comment-triggered executions and shell/path tampering indicators:
grep -RInE '@claude|GITHUB_PATH|head_ref|unexpected token|command not found|syntax error near' /path/to/actions/logs/
A practical log pattern to hunt for is any workflow run that includes both a comment trigger and shell evaluation of branch metadata. For SIEM or centralized log search, a generic query could be:
("issue_comment" OR "@claude") AND ("head_ref" OR "GITHUB_PATH" OR "bash") AND ("pull_request" OR "fork")
If GitHub audit logs are available, also hunt for repository writes by workflow identities shortly after runs triggered from external PR activity.
Mitigation and Patching
The primary remediation is to upgrade to PraisonAI 4.6.40 or later. That is the only source-backed fixed version in the provided material, and it should be your baseline action. Because the issue sits in workflow logic, patch validation should include checking whether your repository still contains copied or customized YAML based on the vulnerable version. Upgrading the package alone may not fully remediate repositories that vendor or template workflow files.
If immediate upgrade is not possible, reduce exposure at the workflow layer. Disable or restrict the comment-triggered Claude workflow for public repositories, especially where forked pull requests are allowed. Require trusted collaborator checks before running any job that can access write-capable tokens, OIDC, gh, or git. Also remove unnecessary permissions from the job: least privilege can significantly limit blast radius even if a shell injection bug exists elsewhere.
Defenders should also harden workflow coding practices. Never pass branch names, PR titles, comments, or other user-controlled metadata directly into Bash run: blocks without strict validation. Prefer passing data as inert arguments to tools that do not invoke a shell, or validate against a conservative character allowlist. Review whether pull_request_target, issue_comment, and OIDC-enabled jobs are reachable from untrusted contexts.
Technical Notes
If you manage PraisonAI through Python packaging, upgrade to the fixed version explicitly:
pip install --upgrade "praisonai>=4.6.40"
If your repository includes workflow files copied from an older release, review and update them manually. As a temporary workaround, you can disable the vulnerable workflow by renaming or removing the file until a fixed version is deployed:
mv .github/workflows/claude.yml .github/workflows/claude.yml.disabled
git add .github/workflows/claude.yml.disabled
git commit -m "Temporarily disable vulnerable Claude workflow pending fix"
To reduce workflow token privileges, tighten permissions in YAML:
permissions:
contents: read
pull-requests: read
And gate comment-triggered execution to trusted actors only:
if: contains(fromJson('["MEMBER","OWNER","COLLABORATOR"]'), github.event.comment.author_association)
In the absence of full upstream patch diff analysis, defenders should assume any repository using the vulnerable trigger and unsafe shell interpolation remains exposed until both the version and the workflow content are verified.
References
The primary reference for this issue is the NVD CVE record describing the flaw as a command injection in PraisonAI’s bundled Claude GitHub Actions workflow. That record states the root cause, the attack path using attacker-controlled branch names and @claude comments, the elevated token and OIDC context, and the fixed version 4.6.40.
The official project and remediation references listed in the research material are the GitHub Security Advisory and the patch commit. Those are the most relevant sources to monitor for any later clarification on exact workflow changes, improved mitigations, or additional hardening guidance.
- NVD entry for CVE-2026-48168
- GitHub Security Advisory: https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-xp85-6wwf-r67c
- Patch commit: https://github.com/MervinPraison/PraisonAI/commit/179cab02dbec0c1e9b601507a659
- Official repository: https://github.com/MervinPraison/PraisonAI
- CISA KEV status checked for CVE-2026-48168: not listed at time of writing
For defenders, the practical takeaway is straightforward: if you use PraisonAI and the bundled Claude workflow, treat all versions before 4.6.40 as vulnerable, patch now, and review GitHub Actions trust boundaries around forked PRs, comment triggers, token scopes, and shell interpolation.
For further information on related vulnerabilities, check out our articles on what is adware and what is a typosquatting attack.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.