CVE-2026-44338: PraisonAI ships and generates a legacy API server with authentication disabled by default, allowing unauthenticated workflow execution
Summary PraisonAI ships a legacy Flask API server with authentication disabled by default. When that server is used, any caller that can reach it can access /agents and trigger the configured agents.yaml workflow through /chat without providing a token.
Details The vulnerable server is the shipped src/praisonai/apiserver.py entrypoint.
- AUTHENABLED = False and AUTHTOKEN = None are hard-coded at [src/praisonai/apiserver.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/apiserver.py:15). - checkauth() returns True whenever authentication is disabled, so both protected routes fail open by design at [src/praisonai/apiserver.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/apiserver.py:18). - POST /chat only checks that the request JSON contains a message key and then runs PraisonAI(agentfile="agents.yaml").run() at [src/praisonai/apiserver.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/apiserver.py:31). - GET /agents is guarded by the same no-op authentication check and returns agent metadata at [src/praisonai/apiserver.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/apiserver.py:55). - When launched directly, the same script binds to 0.0.0.0:8080 at src/praisonai/apiserver.py.
The deploy subsystem keeps the same insecure authentication default:
- APIConfig defaults authenabled to False in [src/praisonai/praisonai/deploy/models.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/deploy/models.py:23). - The generated sample API deployment YAML recommends host: 0.0.0.0 together with authenabled: false in [src/praisonai/praisonai/deploy/schema.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/deploy/schema.py:108).
For scope clarity: the newer serve agents command is safer by default, because it binds to 127.0.0.1 and supports --api-key in [src/praisonai/praisonai/cli/commands/serve.py](/Users/shmulc/Stuff/tmp/first-cve/scans/variant-hunt/PraisonAI/src/praisonai/praisonai/cli/commands/serve.py:155). This report is about the shipped legacy API server and the generated/sample API deployment path above.
Version scope:
- v2.5.6 already ships the same src/praisonai/apiserver.py implementation. - The current PyPI release on May 1, 2026 is 4.6.33, and it still ships the same unauthenticated server logic.
PoC The following route-level reproduction was verified locally and proves that the shipped apiserver.py exposes /agents and /chat without authentication.
1. From the repository root, create a throwaway environment with the server's direct Flask dependencies:
bash python3 -m venv /tmp/praisonai-ghsa-venv /tmp/praisonai-ghsa-venv/bin/pip install flask flask-cors
2. Execute the shipped src/praisonai/apiserver.py under a minimal stub for praisonai.PraisonAI so only the server auth logic is exercised:
bash /tmp/praisonai-ghsa-venv/bin/python - <<'PY' import importlib.util import pathlib import sys import types
stub = types.ModuleType("praisonai")
class DummyPraisonAI: def init(self, agentfile="agents.yaml"): self.agentfile = agentfile def run(self): return {"ran": True, "agentfile": self.agentfile}
stub.PraisonAI = DummyPraisonAI sys.modules["praisonai"] = stub
path = pathlib.Path("src/praisonai/apiserver.py").resolve() spec = importlib.util.specfromfilelocation("apiserverlocal", path) mod = importlib.util.modulefromspec(spec) spec.loader.execmodule(mod)
client = mod.app.testclient() print(client.get("/agents").statuscode, client.get("/agents").getdata(astext=True)) print(client.post("/chat", json={"message": "hello"}).statuscode, client.post("/chat", json={"message": "hello"}).getdata(astext=True)) PY
3. Observed result:
text 200 {"agentfile":"agents.yaml","agents":["default"]} 200 {"response":{"agentfile":"agents.yaml","ran":true},"status":"success"}
Both endpoints succeed without any Authorization header.
Impact Any reachable caller can invoke the legacy API server's protected functionality without a token.
At minimum, this allows:
- unauthenticated enumeration of the configured agent file through /agents - unauthenticated triggering of the locally configured agents.yaml workflow through /chat - repeated consumption of model/API quota and any other side effects performed by that workflow - exposure of whatever result PraisonAI.run() returns to the unauthenticated caller
This is not the same as arbitrary prompt injection by itself, because the current /chat handler ignores the submitted message value and simply runs the configured workflow. The impact therefore depends on what the operator's agents.yaml is allowed to do, but the authentication bypass is unconditional in the shipped legacy server.
Other sources
PraisonAI is a multi-agent teams system. From version 2.5.6 to before version 4.6.34, PraisonAI ships a legacy Flask API server with authentication disabled by default. When that server is used, any caller that can reach it can access /agents and trigger the configured agents.yaml workflow through /chat without providing a token. This issue has been patched in version 4.6.34.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/PraisonAIto a version that resolves this vulnerability.Fixed in 4.6.34 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.6.34 - Configuration
Ensure the legacy Flask API server in src/praisonai/api_server.py is configured to not run with authentication disabled; the shipped code has AUTH_ENABLED = False and AUTH_TOKEN = None hard-coded, so you must replace/upgrade to the fixed release where this behavior is patched.
PraisonAI legacy Flask API server (src/praisonai/api_server.py) AUTH_ENABLED = False
Event History
Frequently Asked Questions
What is the severity of CVE-2026-44338?
CVE-2026-44338 is considered a critical vulnerability due to the lack of authentication, which allows unauthorized users to execute workflows.
How do I fix CVE-2026-44338?
To fix CVE-2026-44338, update your PraisonAI installation to version 4.6.34 or later where the authentication issue is resolved.
What versions of PraisonAI are affected by CVE-2026-44338?
PraisonAI versions from 2.5.6 to before 4.6.34 are affected by CVE-2026-44338.
What are the risks associated with CVE-2026-44338?
The risks include unauthorized access to workflow execution, potential data leaks, and possible system compromise.
Is there a workaround for CVE-2026-44338?
Currently, the recommended solution is to update to a secure version, as workarounds may not fully mitigate the risks.