PraisonAI Authentication Bypass
Unauthenticated Agent Workflow Execution via Legacy API Server
Affected versions 2.5.6 through 4.6.34 shipped a legacy Flask API server with authentication hard-coded off. Unauthenticated attackers on a reachable network could enumerate all configured agent metadata and freely invoke workflows — no token, no credentials, no session. The fix is available in 4.6.35; operators running exposed deployments should treat this as an active threat.
Vulnerability Details
PraisonAI Legacy API Server — Disabled Authentication
The legacy Flask API server in src/praisonai/api_server.py hard-codes AUTH_ENABLED = False and AUTH_TOKEN = None. The two affected routes — GET /agents and POST /chat — perform no credential check, allowing any client on the network to enumerate agent configurations and execute arbitrary workflows. Deployment templates compounded the risk by recommending 0.0.0.0 binding with authentication off.
Affected versions: 2.5.6 – 4.6.34 | Fixed in: 4.6.35
Root Cause
Hard-coded constants in the legacy API server set authentication to disabled by default. The variable names suggest authentication was intentionally bypassed during development and the code was never secured before shipping.
Exposure Surface
Deployment guides recommended binding to all interfaces (0.0.0.0), meaning any host reachable on the network — including internet-facing instances — could reach the unauthenticated endpoints.
Affected Endpoints
GET /agents exposes the full list of configured agent names and metadata. POST /chat accepts a message payload and triggers the configured workflow without any identity check.
Business Impact
Unauthorized workflow execution can drain LLM API quota, exfiltrate data processed by agents, plant adversarial inputs into downstream pipelines, or cause repeated invocations that exhaust rate limits and incur cost.
Attack Chain
Reconnaissance
Attacker identifies a PraisonAI legacy API server reachable on the network — via port scan, exposed service banner, or knowledge of deployment conventions. The default port and binding make this straightforward on improperly segmented networks.
No credentials required. The server is reachable by design.
Agent Enumeration
A single unauthenticated GET /agents request returns all configured agent names and metadata. This reveals the tool set, model configuration, and workflow structure — everything an attacker needs to craft effective exploitation payloads.
Agent names and configurations are disclosed in plaintext with no authentication gate.
Workflow Execution
The attacker sends a crafted POST /chat request with a message payload. The server processes this through the configured agent workflow — invoking LLM calls, executing tools, and processing data — without verifying who triggered the request.
Any workflow, including those with file system or external API access, can be triggered.
Impact Realization
Repeated invocations exhaust LLM API quota and rate limits, incurring financial cost. Adversarial inputs can poison agent memory or downstream pipelines. Data returned by the agent may reveal sensitive context. The lack of logging in legacy mode means exploitation may go undetected.
Financial, data integrity, and confidentiality impacts are all achievable from a single unauthenticated connection.
Defensive Tutorial
Upgrade to 4.6.35 or later
ImmediateThe fix ships in version 4.6.35. Run pip install --upgrade praisonai and verify the installed version. If a controlled upgrade is not immediately possible, block network access to the API server port at the firewall as an interim control.
Inventory running PraisonAI services
ImmediateScan your infrastructure for PraisonAI instances running the legacy API server. Check for processes listening on the default API port across development, staging, and production environments. Container orchestration logs and service discovery tools can accelerate this.
Block network access to exposed instances
ImmediateApply firewall rules or security group changes to restrict access to the legacy API server port. Only allow connections from known, trusted IP ranges. Any instance bound to 0.0.0.0 should be treated as potentially compromised until access logs are reviewed.
Review access logs for unauthorized requests
ImmediateSearch web server and application logs for hits against /agents and /chat from unexpected source IPs. Correlate timestamps against unusual LLM API cost spikes or agent invocation counts. If unauthorized access is confirmed, escalate to incident response.
Rotate downstream credentials if compromise is suspected
UrgentAgents that processed external data through the unprotected endpoint may have been manipulated into exfiltrating credentials or API keys. If unauthorized access is confirmed or suspected, rotate all credentials accessible to the affected agent workflows — LLM API keys, database passwords, third-party service tokens.
Bind development and staging to localhost only
ImportantUpdate all deployment configurations and templates to bind the PraisonAI API server to 127.0.0.1 by default. Remove or override any template that recommends 0.0.0.0 binding. Network exposure should be explicitly opt-in, not the default.
Require an authenticated reverse proxy for all agent APIs
ImportantRoute all external or cross-service traffic through a reverse proxy (nginx, Caddy, Traefik) that enforces authentication — API key headers, OAuth tokens, or mutual TLS. The application layer should never be the first and only authentication gate for agent endpoints.
Register all agent endpoints in your asset inventory
ImportantThis vulnerability persisted because agent API servers are often launched informally during development and forgotten. Establish a mandatory registration process for any service exposing an agent endpoint — including development instances. Asset inventory is the prerequisite for patch management and incident response.
References
- GitHub Security Advisory GHSA-6rmh-7xcm-cpxj — PraisonAI Authentication Bypass
- CVE Program CVE-2026-44338 — PraisonAI Legacy API Server Unauthenticated Access
-
CWE References
CWE-306 · Missing Authentication for Critical Function
CWE-668 · Exposure of Resource to Wrong Sphere
CWE-1188 · Insecure Default Initialization of Resource