Authentication Bypass in PraisonAI OAuthManager - Empty Token Store Logic Flaw
PraisonAI's token validation function returns True for any unrecognized token when the internal token store is empty (default state), allowing unauthenticated access to all MCP tools including agent execution and file operations. This bypasses intended OAuth authentication entirely.
CVE References
Affected
Vulnerability Description
The vulnerability is a logic error in authentication validation where OAuthManager.validate_token() implements inverted trust logic. The method iterates over stored tokens to validate incoming credentials, but when the internal token store _tokens is empty (the default state), the loop never executes and the function returns True unconditionally. This means any Bearer token—including fabricated or empty values—passes validation. The vulnerability class is broken authentication (CWE-287) combined with insecure defaults (CWE-1104).
PoC Significance
The disclosed PoC demonstrates that an unauthenticated remote attacker with network access to the HTTP-stream MCP server can invoke the /mcp endpoint with an arbitrary token and receive a 200 OK response listing 50+ registered tools. This proves the authentication gate is non-functional in default deployments. The attack requires no credentials, no token pre-sharing, and no configuration—it works immediately post-installation. The precondition is only network reachability to the MCP server (typically listening on 0.0.0.0:8080).
Detection Guidance
Log Indicators: Monitor MCP HTTP server logs for POST requests to /mcp endpoints with Authorization: Bearer headers that do not match any known valid tokens or patterns in your OAuth configuration. Flag requests with obviously fake tokens (e.g., fake_token_*, test_*, or tokens not matching your issuer's format). Network Signatures: Detect repeated MCP tool requests (especially tools/list, praisonai.agent.run, praisonai.workflow.run) from unauthenticated sources. Configuration Audit: Check if _tokens dictionary in running OAuthManager instances is empty; if so, authentication is bypassed.
Mitigation Steps
- Immediate: Restrict MCP HTTP server binding from
0.0.0.0to127.0.0.1or internal network ranges only; block external connectivity via firewall. - Short-term: Upgrade PraisonAI to a patched version (awaiting release) that implements proper token validation logic (e.g., return
Falseby default if no tokens match, require explicit token registration before startup). - Workaround: Implement reverse-proxy authentication (nginx, HAproxy) in front of the MCP server to enforce real token validation before requests reach the application.
- Code Fix: The validation logic should be inverted to return
Falseif the loop completes without finding a matching, non-expired token:def validate_token(self, token: str) -> bool: for stored_token in self._tokens.values(): if stored_token.access_token == token: return not stored_token.is_expired() return False # Default DENY, not ALLOW
Risk Assessment
Likelihood of Exploitation: High in the wild. The vulnerability requires zero technical sophistication—a simple curl command with a fake Bearer token succeeds. Any public-facing PraisonAI instance using the default HTTP server configuration is immediately exploitable. Threat Actor Interest: Severe. Attackers gain unrestricted access to tool execution, potentially including arbitrary file write/read, agent spawning, and workflow initiation—enabling lateral movement, data exfiltration, or supply-chain attacks. Prevalence: Default-insecure configurations tend to see rapid adoption in development/testing environments that may persist to production. Early detection and patching are critical.
Sources